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

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

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

      其间有些比较好的评论（个人认为），我列举下：

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、 

得博主举的例子过于简单，不能够很好地体现BLL层的意义。

第一、验证过于简单，在BLL中添加Department除了判断是否Null值，如果再加上一个在同一层次的部门名称、部门编号不能够相同的验证。

第二、例子中基本上没有体现的业务逻辑，难怪上面有人反对。

我建议部门最好用树结构形式，这样才能更好地表达业务逻辑。

3、

1、你前面一篇文章已经有人提了，你没分清什么叫数据，什么叫业务，楼主是怎么区分一个方法应该是数据还是业务的，有什么样的准则什么样的约定

2、就像楼上说的，有接口但在BLL层调用时直接用了实现，接口的意义何在？

如果这2个问题无法解决的话，说句不好听的，个人认为，这文章在首页不是教人很多，倒是会害人不浅

 

 

 

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