系统结构如图（以Web为例）：
1， 数据层：没什么好说的，数据库的选用应该和业务逻辑没有关系，总的来说，只是把数据库当作一个容器。数据库的特性一概不用（或许用人说这对性能不好，但是总比你迁移的成本要小得多，更何况你也不想M$或者IBM捏着你的命根吧？）。
2， DLL中间层：这个是重点了。
a) 数据访问（DataAccess）：提供数据库的访问功能，我一般使用现成的，以前自己写了个YDClassLibrary，现在是用SPL。至于用什么好，还要看项目的规模。还要看项目的大小，像SPLEB这样的小东西（Access库，不到5个表，没有并发……）用NHibernate有必要吗？
b) 数据定义（DataDefine）：数据定义也可以成为数据实体（DataEntity），这个部分就给出了基于DataAccess层ORM的OO类。不过换一套DataAccess的时候，就要换一套DataDefine了。一般这一层使用代码生成器生成，也和具体的业务逻辑关系不大。至于代码生成的工具就要根据你的DataAccess来定了。以前用YDCLassLibrary的时候用YDCodeMaker，现在用SPL所以在写个SPLEB。或者，更直接一些，用CodeSmith。呵呵。
c) 系统支持（SystemFramework）：提供系统的框架支持，典型的，如异常、日志等。也有现成的，比如log4net。
d) 业务逻辑（BusinessRule）：对于需求中逻辑的抽象，一帮是提供某些功能。比如一个用户的信息转换、加密等。
e) 业务外观（BusinessFacade）：对业务层的封装，提供业务实体（BusinessEntity），及相关的业务的Façade类。对上一层提供接口。也可以将BusindessEntity单独抽出作为一部分。这要看具体情况。如果是大型的，则Business完全封装DataDefine部分，即对外只需了解BusinessFacade就可以了。
3， 表现层（WebForm or WinForm）没什么好说的了，看你怎么写了，Web或者WinForm，随意了，什么AJAX呀，WebServices呀，都可以。
说明：
1， 我的三层式结构和微软给出的例子差不多，也有不同之处，主要是着眼于实际的快速开发。兼顾稳定性和性能。最大限度的利用已有的资源，特别是免费和开源的，重用就是减少成本！
2， 对于表现层，需要了解业务层的BusinessFacade类。对于小系统，有的时候DataEntity和BusinessEntity也差不多，所以表现层也可以直接使用DataEntity。我认为封装是一个相对的问题，仅仅为了封装而封装没有任何意义，先实现功能，我们有TDD，所以我们可以不断重构，当然，设计模式也很重要，但我们的目的是实现最后的系统，时刻记住，我们是在作产品，不是艺术品。
3， 开发模式。首先当然是设计，业务对象、业务逻辑什么的，然后再设计到一定阶段的时候，我推荐先做原型或者先把所有的UI（Web是页面设计，WinForm是窗体）做出来，和客户交流，这样比较能把握需求，设计的也更准确，可以极大的避免返工。然后差不多开始数据库设计，可以参考我的另一篇文章（http://yuandong.cnblogs.com/archive/2006/02/04/325303.html）。只要数据库设计完毕，DataAccess和DataDefine就全部是自动化的了。
4， 业务逻辑，这是作最难写的，我一般采用OOA/D和TDD相结合的模式，循环进行，这个过程中一般少不了对数据库的更改，幸好我们的数据访问全部是自动的，很容易适应需求变化。
5， 进入表现层了，这时候业务逻辑应该已经全部通过单元测试了，我们有了足够的类来搭建我们的外观了。如果你前面已经作好了界面设计，那就太容易了，装备，调试，一切OK。
具体的实现，我会用SPLEB为例，请关注我的下一篇文章
SPLEB开发日志——三层结构（2）实现
