步步为营 .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个问题无法解决的话，说句不好听的，个人认为，这文章在首页不是教人很多，倒是会害人不浅 

 

 

感谢你们提出很好的建议。