步步为营 .NET三层架构解析系列总结

   这个系列我一共写了八篇,从什么是三层架构到一个简单的三层架构从数据库设计、SQLHelper设计、Modle设计、DAL设计、BLL设计到UI的设计作了简单的说明,在这其中有很多读者提出了很好的意见,我很高兴,我只是把我的理解粗略的写出来分享,以此来回顾以前做过的一些项目的总结,希望自己在这其中有些启发,同时也接受读者给我的批评,来使自己有所提高。

步步为营 .NET三层架构解析系列

步步为营 .NET三层架构解析 一、什么是三层架构

步步为营 .NET三层架构解析 二、数据库设计

步步为营 .NET三层架构解析 三、SQLHelper设计

步步为营 .NET三层架构解析 四、Model设计(四种设计方式)

步步为营 .NET三层架构解析 五、DAL与IDAL的设计

步步为营 .NET三层架构解析 六、BLL的设计

步步为营 .NET三层架构解析 七、UI的设计(登陆页面、注册页页和添加部门页面)

步步为营 .NET三层架构解析 八、UI的设计(GridView的设计及其分页)

       感谢读者对我博客的支持和提出的宝贵的建议。源码下载

      其间有些比较好的评论(个人认为),我列举下:

1、土豆烤肉
呵呵,对于复杂的项目的话,可以考虑用领域模型设计呀,这方面的开源项目也挺多的,MVC MusicStore也采用了类似的设计思想吧

采用领域模型设计思想去做的话,可以将主要焦点放在领域模型及模型相关的业务逻辑上,至于数据持久化,网元交互同步,UI展示,都可以分离出来。
主要有以下几个分层:
DOMAIN层 --- 领域模型层(我使用的是充血型的模型)
Infrastructure层 --- 基础层(包括模型的数据持久化,与网元交互的代理,与文件系统交互的基础类等)
TASK层 --- 服务提供层 (提供给UI或其他网元的服务,如查询与CMD)

这样子的话:
写领域模型的兄弟可以专业于领域模型及业务
写数据持久化的兄弟,只要写数据持久化,一般用ORM来Mapping,如果有兴趣的话可以使用NH3或者EF 4.1,这2个对DDD的支持比较好,模型相对比较纯洁

至于UI或其他网元与系统的数据交互一般情况下分为2种:
即:查询,与 数据变更

因此:
建立对应的DTO对象,从服务提供层得到DTO的数据,展现UI
建立对应的COMMAND对象,从UI或网元传入CMD对象给服务提供层,服务提供层调用相关的基础层或领域模型服务来实现数据变更

这样子的话,使领域模型对象与UI及其他网元彻底分离,使业务逻辑高聚合在领域模型中

每个层之间可以使用IOC达到层与层之间的散耦合

至于数据缓存,日志记录,异常处理,这些常用的方法,可以使用AOP的方式来实现,有兴趣的兄弟可以看看PostSharp

大概就是这个样子
2、 rhs

得博主举的例子过于简单,不能够很好地体现BLL层的意义。
第一、验证过于简单,在BLL中添加Department除了判断是否Null值,如果再加上一个在同一层次的部门名称、部门编号不能够相同的验证。
第二、例子中基本上没有体现的业务逻辑,难怪上面有人反对。
我建议部门最好用树结构形式,这样才能更好地表达业务逻辑。
3、 Gray Zhang
1、你前面一篇文章已经有人提了,你没分清什么叫数据,什么叫业务,楼主是怎么区分一个方法应该是数据还是业务的,有什么样的准则什么样的约定
2、就像楼上说的,有接口但在BLL层调用时直接用了实现,接口的意义何在?
如果这2个问题无法解决的话,说句不好听的,个人认为,这文章在首页不是教人很多,倒是会害人不浅
 
 
 
感谢你们提出很好的建议。

转载于:https://www.cnblogs.com/springyangwc/archive/2011/03/30/2000388.html

已标记关键词 清除标记
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符 “速评一下”
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页