• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    公众号

.NET逻辑分层架构总结

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

一.基础知识准备:

  1.层的原则:

  (1)每一层以接口方式供上层调用。
  (2)上层只能调用下层。
  (3)依赖分为松散交互和严格交互两种。

  2.业务逻辑分类:

  (1)应用逻辑。
  (2)领域逻辑。

  3.采用的层:

  (1)表示层(用户接口层):领域无关。
  (2)服务层(应用层):应用逻辑。
  (3)业务逻辑层(领域层):领域逻辑。
  (4)共享层:提供通用代码。
  (5)实现层:提供接口实现。

  4.约定:

  (1)领域层默认采用领域模型
  (2)数据访问层默认需要引用领域模型

二.分层架构

  分层架构的三个基本层次为:表示层、业务逻辑层和数据访问层。如果按照业务逻辑的分类将业务逻辑层分解为服务层和领域层,则三层扩展为四个层次:表示层、服务层、领域层和数据访问层。数据访问层一般必须了解领域模型,这将在层之间产生双向依赖,通常我们有如下两种解决方案:

  1.将领域模型放置在共享层:

  评价:PetShop采用此种模型,但缺点众多:业务逻辑层名不副实,领域模型实为数据模型,保持了层间依赖,引入了更多依赖,明显的数据驱动思想,没有以领域为核心。

  2.将数据访问接口定义在业务逻辑层:

  评价:NopCommerce采用此种模型,即使采用分离出了服务层和采用了资源库命名方式,但NopCommerce不是DDD分层架构,只是采用了领域模型和接口分离原则的普通三层架构。缺点:除了数据房产,没有将其他具体的技术依赖从业务逻辑层中分离。

三.DDD分层:

  DDD分层明确的将业务逻辑层分成了应用层(服务层)和领域层两部分。同时将数据访问和其他接口的具体技术实现部分统一到了基础设施层。

  1.原始的DDD分层:

  评价:优点是将具体技术实现从领域分离,基础设施层复用价值增加。缺点是没有使用共享和实现的概念细分基础设施层,导致在基础设施层中实现仓储会产生反向依赖,虽然在单项目解决方案中没有影响(仅命名空间层次的形式上的依赖),但在.NET多项目解决方案中,只能通过接口分离方式将仓储实现独立成类似数据访问层的方式。

  2.改善的DDD分层:

  评价:基础设施层同时具有共享层和实现层的特征。优点是终于做到了形式上领域为核心且同时解决了在基础设施层中实现仓储不能引用领域模型的尴尬,缺点是同样没有区分共享和实现的概念。

  3.最新的DDD分层:

  评价:优点是这是真正的以领域为核心,再也不用为基础设施层无法引用领域层而再服务层中再次适配了。使用依赖倒置原则彻底各层对具体技术的依赖倒置。缺点,依赖倒置应用过了头,同样是在单项目解决方案中没有问题,但在.NET多项目解决方案中会导致命名空间形式上的双向依赖。基础设施层作为实现层基本上没有了复用的价值。更好的方式是调换图中用户接口层和基础设施层的位置。

  可以根据需要考虑在上图添加适当的共享层。

四.架构的趋势:

  (1)以业务逻辑为核心,更加重视业务逻辑。
  (2)将业务逻辑层的具体依赖划分到一个层次统一管理。
  (3)更加重视降低解决方案内的依赖性而不是解决方案间的代码复用。
  (4)共享层和实现层的分离将会越来越多的体现。例如洋葱型架构。

以上所述就是本文的全部内容了,希望大家能够喜欢。


鲜花

握手

雷人

路过

鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
上一篇:
asp.net模板引擎Razor调用外部方法用法实例发布时间:2022-02-05
下一篇:
浅谈ASP.NET中MVC 4 的JS/CSS打包压缩功能发布时间:2022-02-05
热门推荐
热门话题
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap