领域驱动设计(DDD)技术分享
2012-12-07 13:00
561 查看
注:本文为技术讨论会上的内容要点摘录整理的,相关内容仅作参考。
Module---模块,通常按照功能来划分,比如按照业务功能来划分
Model --模型,它通常出现在下面几个概念中:
l MVVM --Model+View+ViewModel
l MVP --Model+View+Presenter
l MVC --Model+View+Controller
所以常说的Model实际上包含了View Model,Domain Model(简称DM),Entity Model。
PS:上面说的MVVM,MVP,MVC都属于“表现层架构模式”。
1, 概念模型设计---E-R,抽象层次最高
2, 实体模型设计---Entity
3, 物理模型设计----具体数据库系统上面的表、视图、存储过程设计
l 表,
l 视图,
l 存储过程,
l 甚至数据库函数。
MS EF 将自定义SQL语句映射成实体类?
2, 相当于是存储过程和视图的结合体。
原因?
如果直接映射全表的字段到Entity,相当于是执行
Select * form Table
查询,这种方式有损效率。
1, 从表反向生成实体类,导致不愿意根据业务需求灵活定义实体类。
2, 没有自定义的实体类,所以每次都使用“全表映射”的实体类。
因此导致我们用ORM框架做的项目查询效率没有手写SQL的项目高。
要解决这个问题,就得看ORM框架是否支持“按需查询”
PS:---Linq2Sql,MS EF,PDF.NET 就是这样的框架。
2,Entity--〉数据从DM到数据库一个“持久化”过程。
ViewModel《--DM--》Entity
PS:有同学说这3个Model相互转换很麻烦,其实可以使用第三方工具来做,比如开源的AutoMapper。
传统三层:
UI--〉BLL--〉DAL
UI《-BLL〈--DAL
该模式的特点,是高度依赖于数据库设计,没有数据库无法开工。
PS:以我们这次项目为原型做好的领域模型介绍。
UML强调的主要功能是“沟通”,把UML工具作为沟通的重要工具。
l Presentation Layer--表现层,
l Domain Layer--领域层,
l Repository Layer--仓储层
PS:Repository Layer不同于三层架构的DAL,其中最关键的就是“驱动方向”不同,在DDD中,是Domain Layer需要什麽,Repository Layer提供什麽;而在DAL中相反,不管BLL是否需要,先提供一堆DAL方法再说,没有“领域”的需求。
2、设计领域对象模型
3、测试领域对象模型
4、设计业务处理类
5、设计Entity和ViewModel
6、测试业务处理类
7、设计表架构
8、开发用户界面
l 连表查询;
l 不合理的使用索引。
优化方式:
1, 避免全表查询;
2, 将常见的表数据缓存,化解连表查询为单表查询。
很多项目都是CRUD(增,删,改,查)。
/article/4857030.html
“领域驱动开发”实例之旅(1)--不一样的开发模式
/article/4805146.html
使用View Model从表现层分离领域模型
/article/4588080.html
深蓝医生
http://www.pwmis.com/sqlmap
整理:2012年12月7日星期五
1 “模型”的几个概念
下面这2个名词容易混淆:Module---模块,通常按照功能来划分,比如按照业务功能来划分
Model --模型,它通常出现在下面几个概念中:
l MVVM --Model+View+ViewModel
l MVP --Model+View+Presenter
l MVC --Model+View+Controller
所以常说的Model实际上包含了View Model,Domain Model(简称DM),Entity Model。
PS:上面说的MVVM,MVP,MVC都属于“表现层架构模式”。
2 Entity--实体模型
2.1 概念来源
Entity--实体,其实它是来自于数据库设计中的概念,通常完善的数据库设计过程包含下面3个阶段:1, 概念模型设计---E-R,抽象层次最高
2, 实体模型设计---Entity
3, 物理模型设计----具体数据库系统上面的表、视图、存储过程设计
2.2 Entity和表架构的关系
2.2.1 映射的种类
Entity映射的种类,可以有l 表,
l 视图,
l 存储过程,
l 甚至数据库函数。
MS EF 将自定义SQL语句映射成实体类?
2.2.2 自定义SQL语句
1, 不同于视图,不能在视图中设定查询参数,2, 相当于是存储过程和视图的结合体。
2.2.3 多对多关系
Entity和表等是一个“多对多关系”。原因?
如果直接映射全表的字段到Entity,相当于是执行
Select * form Table
查询,这种方式有损效率。
2.3 懒人效应
所有的ORM工具都只能作为“工具”,会促使“懒人效应”。1, 从表反向生成实体类,导致不愿意根据业务需求灵活定义实体类。
2, 没有自定义的实体类,所以每次都使用“全表映射”的实体类。
因此导致我们用ORM框架做的项目查询效率没有手写SQL的项目高。
要解决这个问题,就得看ORM框架是否支持“按需查询”
PS:---Linq2Sql,MS EF,PDF.NET 就是这样的框架。
3 “数据”的变化
3.1 “持久化”概念:
数据的存储媒介:内存,磁盘等。由于内存的数据容易丢失,所以要写入磁盘等长久存储媒介,数据的这个处理过程就是持久化。3.2 在各个模型层面的变化过程:
1,ViewModel--〉数据从DM到视图界面的过程;2,Entity--〉数据从DM到数据库一个“持久化”过程。
ViewModel《--DM--》Entity
PS:有同学说这3个Model相互转换很麻烦,其实可以使用第三方工具来做,比如开源的AutoMapper。
传统三层:
UI--〉BLL--〉DAL
UI《-BLL〈--DAL
该模式的特点,是高度依赖于数据库设计,没有数据库无法开工。
4 DDD--领域驱动设计:
4.1 领域模型
DDD,着重强调:-领域模型PS:以我们这次项目为原型做好的领域模型介绍。
4.2 DDD实践的关键步骤:
4.2.1 领域建模
UML是一种建模工具,画草图,文档,讨论组等。。。。UML强调的主要功能是“沟通”,把UML工具作为沟通的重要工具。
4.2.2 聚合根
--领域下的所有的对象都从这个根对象衍生出来,那这个对象就是这个领域下面的聚合根4.3 DDD分层
常见的方式按照约定,分为:l Presentation Layer--表现层,
l Domain Layer--领域层,
l Repository Layer--仓储层
PS:Repository Layer不同于三层架构的DAL,其中最关键的就是“驱动方向”不同,在DDD中,是Domain Layer需要什麽,Repository Layer提供什麽;而在DAL中相反,不管BLL是否需要,先提供一堆DAL方法再说,没有“领域”的需求。
4.4 领域驱动开发模式的开发过程
1、分析业务需求。2、设计领域对象模型
3、测试领域对象模型
4、设计业务处理类
5、设计Entity和ViewModel
6、测试业务处理类
7、设计表架构
8、开发用户界面
5 数据库查询最有损效率的地方
l 全表查询;l 连表查询;
l 不合理的使用索引。
优化方式:
1, 避免全表查询;
2, 将常见的表数据缓存,化解连表查询为单表查询。
很多项目都是CRUD(增,删,改,查)。
6 附录
6.1 参考资源:
UML类图关系大全/article/4857030.html
“领域驱动开发”实例之旅(1)--不一样的开发模式
/article/4805146.html
使用View Model从表现层分离领域模型
/article/4588080.html
深蓝医生
http://www.pwmis.com/sqlmap
整理:2012年12月7日星期五
相关文章推荐
- 领域驱动设计(DDD)的实践经验分享之持久化透明
- [转]分享我对领域驱动设计(DDD)的学习成果
- 分享我对领域驱动设计(DDD)的学习成果
- 分享我对领域驱动设计(DDD)的学习成果
- (转)领域驱动设计(DDD)的实践经验分享之ORM的思考
- 分享我对领域驱动设计(DDD)的学习成果
- [转] DDD领域驱动设计框架分享
- 分享我对领域驱动设计(DDD)的学习成果
- 基于事件驱动的DDD领域驱动设计框架分享(附源代码)
- 基于事件驱动的DDD领域驱动设计框架分享(附源代码)
- DDD领域驱动设计基本理论知识总结
- 领域模型驱动设计(DDD)之模型提炼
- 浅谈我对DDD领域驱动设计的理解
- DDD领域驱动设计之聚合、实体、值对象
- DDD领域驱动设计基本理论知识总结
- [0] DDD领域驱动设计(二) 之 值对象
- .NET领域驱动设计―看DDD是如何运用设计模式颠覆传统架构
- 我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践
- DDD(领域驱动设计)理论结合实践
- DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践(1)