docs: Improve module and dependency documentation clarity
This commit is contained in:
@@ -1,5 +1,5 @@
|
|||||||
## 模块与项目
|
## 模块与项目
|
||||||
意框架是一个基于Abp.VNext的框架,完美使用模块化理念进行开发。既然是模块化开发,就有`项目`与`项目`的概念。
|
意框架是一个基于Abp.VNext的框架,完美使用模块化理念进行开发。既然是模块化开发,就有`模块`与`项目`的概念。
|
||||||
|
|
||||||
很多人问到了我,我的代码应该放到哪里,其实是没有分清楚模块与项目,弄清楚这个,再下手撸码,才更有方向。
|
很多人问到了我,我的代码应该放到哪里,其实是没有分清楚模块与项目,弄清楚这个,再下手撸码,才更有方向。
|
||||||
|
|
||||||
@@ -7,15 +7,15 @@
|
|||||||
|
|
||||||
> 我接下来要开发的业务是否有必要被其他项目依赖使用?
|
> 我接下来要开发的业务是否有必要被其他项目依赖使用?
|
||||||
|
|
||||||
例如:内置的Rbac模块、Bbs模块,单独具备权限管理和社区论坛的功能,公开给大家复用引用,这就可以当成一个模块
|
例如:内置的Rbac模块、Bbs模块,单独具备权限管理和社区论坛的功能,公开给大家复用引用,这就可以当成一个`模块`
|
||||||
|
|
||||||
`但是`,有时候如果我不认为他有必要复用,就是公司的一个内部系统,想要快速开发并交付,要同时具备权限管理、商城、审批等各种功能,那就直接当一个项目开发即可,不一定需要将各个模块拆的太散
|
`但是`,有时候如果我不认为他有必要复用,就是公司的一个内部系统,想要快速开发并交付,要同时具备权限管理、商城、审批等各种功能,那就直接当一个`项目`开发即可,不一定需要将各个模块拆的太散
|
||||||
|
|
||||||
> 这个划分的界限,是由项目来决定
|
> 这个划分的界限,是由项目来决定
|
||||||
|
|
||||||
注意:模块的代码与项目的代码结构几乎没有区别
|
注意:`模块`的代码与`项目`的代码结构几乎没有区别
|
||||||
|
|
||||||
这意味,有一个最好的方式,先将业务全部写在项目中,等稳定之后,在复制抽象到模块中,完全没有问题。
|
这意味,有一个最好的方式,先将业务全部写在`项目`中,等稳定之后,在复制抽象到`模块`中,完全没有问题。
|
||||||
|
|
||||||
### 模块的优缺点
|
### 模块的优缺点
|
||||||
- 优点:高度抽象复用
|
- 优点:高度抽象复用
|
||||||
@@ -24,17 +24,17 @@
|
|||||||
### 模块
|
### 模块
|
||||||

|

|
||||||
|
|
||||||
代码位置放在`module`目录下,单独建立一个自己的模块名称,可使用`脚手架使用`将默认代码生成在这里。
|
代码位置放在`module`目录下,单独建立一个自己的模块名称,可使用[**脚手架使用**](../05.脚手架使用.md)将默认代码生成在这里。
|
||||||
|
|
||||||
### 项目
|
### 项目
|
||||||

|

|
||||||
|
|
||||||
框架内置一个host项目,代码位置存放在`src`中,直接使用即可,如果想更换命名,可以使用上一节的`脚手架使用`。
|
框架内置一个host项目,代码位置存放在`src`中,直接使用即可,如果想更换命名,可以使用上一节的[**脚手架使用**](../05.脚手架使用.md)。
|
||||||
|
|
||||||
## 总结
|
## 总结
|
||||||
> 由于很多人询问我这个问题,所以单独写一篇,方便大家理解。
|
> 由于很多人询问我这个问题,所以单独写一篇,方便大家理解。
|
||||||
|
|
||||||
先区分模块还是项目,然后代码写到对应的位置即可
|
先区分`模块`还是`项目`,然后代码写到对应的位置即可
|
||||||
|
|
||||||
理论上,按这套规则意味着,只有在自己的`module`、`src`下才需要写代码,其他地方都是内置好了的,通过继承、实现等方式扩展即可
|
理论上,按这套规则意味着,只有在自己的`module`、`src`下才需要写代码,其他地方都是内置好了的,通过继承、实现等方式扩展即可
|
||||||
|
|
||||||
|
|||||||
@@ -10,7 +10,7 @@
|
|||||||
|
|
||||||
> 题外话,很是有缘,在完全没有接触过DDD的分层的时候,还是停留在三层架构的时期,对于大型复杂的依赖关系,Service满天飞,根本难以下手,写出的代码交错复杂,稍微隔一段时间没去回顾,再去看,就会被自己的代码给绕死,所以我就一直想换一种分层模式,想让各个服务结构更加清晰,不再是直肠子式的三层架构,那我做的第一件事情,就是把关系比较紧密的给装在一起当成一个整体,各个整体之间不轻易去依赖,而是通过事件去抛出去。这就在早期形成了一套依赖关系比较清晰的框架,经过不断的项目历练,慢慢的就变成了业务聚合、应用组装等等概念,等到机会接触到了DDD分层一看,`哇塞,怎么那么像?这怕不是他抄我的分层嘛`,当然开个玩笑,从此对这块的了解更加加深,确实值得很多大家应该学习的地方,提升一下自己。
|
> 题外话,很是有缘,在完全没有接触过DDD的分层的时候,还是停留在三层架构的时期,对于大型复杂的依赖关系,Service满天飞,根本难以下手,写出的代码交错复杂,稍微隔一段时间没去回顾,再去看,就会被自己的代码给绕死,所以我就一直想换一种分层模式,想让各个服务结构更加清晰,不再是直肠子式的三层架构,那我做的第一件事情,就是把关系比较紧密的给装在一起当成一个整体,各个整体之间不轻易去依赖,而是通过事件去抛出去。这就在早期形成了一套依赖关系比较清晰的框架,经过不断的项目历练,慢慢的就变成了业务聚合、应用组装等等概念,等到机会接触到了DDD分层一看,`哇塞,怎么那么像?这怕不是他抄我的分层嘛`,当然开个玩笑,从此对这块的了解更加加深,确实值得很多大家应该学习的地方,提升一下自己。
|
||||||
|
|
||||||
> 一千个码农,就有一千个DDD。DDD不一定完全是对的,但一定是值得学习使用的
|
> 一千个码农,就有一千个DDD。DDD不一定完全是适合的,并且DDD也从不是银弹,但一定是值得学习使用的
|
||||||
|
|
||||||
> 在此,老橙子很乐意以我的血淋淋的教训的角度给大家讲清楚,框架的分层依赖关系,同时也是标准的`DDD分层架构`依赖关系,希望能给大家带来一些帮助~
|
> 在此,老橙子很乐意以我的血淋淋的教训的角度给大家讲清楚,框架的分层依赖关系,同时也是标准的`DDD分层架构`依赖关系,希望能给大家带来一些帮助~
|
||||||
|
|
||||||
@@ -33,7 +33,7 @@
|
|||||||
|
|
||||||
可以从上图很直观的看出:
|
可以从上图很直观的看出:
|
||||||
|
|
||||||
最顶层的`host主机与下面的应用`没有关系,意味着host主机可以是web、可以是cs、可以等等,所以我们的host主机只充当一个web启动的作用,不包含业务逻辑
|
最顶层的`host主机与下面的应用`没有关系,意味着host主机可以是web、可以是cs等等。所以我们的host主机只充当一个web启动的作用,不包含业务逻辑
|
||||||
|
|
||||||
另外,发现目录中只包含ORM,好像没有基础设施层,其实是一个包含关系,是ORM属于基础设施中的一种,但是为了将orm抽象,特意把ORM独立了一层
|
另外,发现目录中只包含ORM,好像没有基础设施层,其实是一个包含关系,是ORM属于基础设施中的一种,但是为了将orm抽象,特意把ORM独立了一层
|
||||||
|
|
||||||
|
|||||||
@@ -2,7 +2,8 @@
|
|||||||
通常,在Asp.NetCore中,**容器组装**过程 与 **管道模型组装** 过程 会将启动类文件变的非常长,同时也需要明确各个模块的依赖关系
|
通常,在Asp.NetCore中,**容器组装**过程 与 **管道模型组装** 过程 会将启动类文件变的非常长,同时也需要明确各个模块的依赖关系
|
||||||
例如:
|
例如:
|
||||||
我们需要仓储的功能,但是仓储的实现需要依赖Sqlsugar
|
我们需要仓储的功能,但是仓储的实现需要依赖Sqlsugar
|
||||||
老的引入写法:
|
|
||||||
|
***老的引入写法***:
|
||||||
``` cs
|
``` cs
|
||||||
service.AddUow();
|
service.AddUow();
|
||||||
service.AddSqlsugar();
|
service.AddSqlsugar();
|
||||||
|
|||||||
Reference in New Issue
Block a user