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

时间：2011-03-30 来源：spring yang

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

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

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

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

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

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