先上图看下数据分层实际应用：
下面来按从下往上的顺序介绍：
1. Example.AutoModel：代码生成器自动生成的Model/VO/Entity(数据模型/数据实体)，无论重复生成多少次，都可以全部替换掉，因为该项目不会体现任何的业务逻辑，这个项目永远都是自动生成。
2. Example.IBatis：很明显，这个是IBatis特有的，因此，把IBatis的SqlMap都放在这里，这里为了防止自动生成的文件，把应用的业务逻辑相关的代码覆盖掉，使用文件夹的方式分开管理，代码自动生成后，只替换掉AutoMap部分的文件。这里没有把AutoMap和Map还有DAL独立出各自的项目，也是经过思索的，如果把这些都独立出来，那会把整个应用变得越来越庞大，也没这个必要性，如果另外一个应用与当前应用在业务逻辑上有不同的地方，可以在该应用的其它项目中继承该项目中的类，再使用该继承后的类。况且，该Map与DAL，涉及到的业务逻辑比较少。这里是经过了慎重的考虑，才最终觉得这样处理的。
3. Example：每一个应用都有其数据层，数据层独立出一个项目，以供WinForm/WebForm或者是其它应用使用，与各自的应用独立出来。该数据层项目涉及到每一个应用的业务逻辑，基本上，所有非代码生成器自动生成的代码，都放在该项目中，该项目由于代码生成器生成一次后，基本上都作手工更改（切记），如果是新增表，则代码生成后，增量添加到该项目中，切勿把其它覆盖掉原来的，否则，如果没做源码管理的，那就是恶梦了。
4. Example.WinForm：使用Example项目的WinForm应用。这就真真正正地每一个应用都有其特殊业务逻辑，同样的，所有模块自动生成一次，然后手工修改代码，新增的使用增量添加到项目中。
总结：
1. 原来是把DAL放在Example项目中的，但今天修改时发现该DAL中全部是继承了IBatisDAO<Myperson>类的，与IBatis紧密联系在一齐，因此，把它放到了Example.IBatis中去了，当如果使用了别的ORM工具时，该项目基本上是要被替换掉的了。
2. 如何实现上面说到的使用别的ORM工具时的替换？我这里使用的是spring.net的IOC功能，在Example项目的config中放的是spring.net的配置信息，如：Dao.config和Service.config，其中Dao.config中配置的代码：
<object id="MypersonDAO" type="Example.DAL.MypersonDAO, Example.IBatis" parent="IBatisDAO">
</object>
<object id="TesttableDAO" type="Example.DAL.TesttableDAO, Example.IBatis" parent="IBatisDAO">
</object>
因此，如果这里是别的ORM工具的话，就会出现另外一个Example. NHibernate 或者是Example.Linq这样的DAO层项目，只需要把这里的object的类型改 一下就可以了。下面顺便看下（BLL层）Service.config的配置：
<import resource="Dao.config"/>
<object id="MypersonBLL" type="Example.BLL.MypersonBLL, Example">
<property name="baseDao" ref="MypersonDAO"/>
</object>
<object id="TesttableBLL" type="Example.BLL.TesttableBLL, Example">
<property name="baseDao" ref="TesttableDAO"/>
</object>
如果Dao.config不改的话，可以在这里的import中改成另外一个文件名的 Dao配置就行了。如“<import resource="Dao_Linq.config"/>”或者是“<import resource="Dao_NHibernate.config"/>”来实现，有人会问，那原来的“Dao.config”不 就多余了？确实是多余了，你可以直接删除掉。
同样的道理，我们来看看Example.WinForm中的app.config的配置，也涉及到不同应用中，使用不同的Example项目的处理方式，我们先来看相关配置：<resource uri="assembly://Example/Example/SpringObjects.xml"/>你好这里的配置告诉应用程序，使用哪个项目中的数据层的对象。如果在Example的基础上去做另外一个项目的话，你可以新建一个Example_B项目，那里面你的BLL和DAO可以自己去派生也好，自己重写各自的BLL或者是DAO的也好，你直接把这个配置改成“<resource uri="assembly://Example_b/Example_b/SpringObjects.xml"/>”。想利用这种便利性，你得在你的应用中使用接口编程，使用IOC工具来实现。
最后，简略说明下：
1. Example：封装了BLL与Modal层业务逻辑。
2. Example.IBatis：封装了DAL层业务逻辑，及非Auto部分的IBatis的SqlMap配置文件业务逻辑。这里不推荐把IBatis的业务逻辑部分的SqlMap放在这里，但允许放除了增删改查以外的，所有应用都通用的业务逻辑的SqlMap配置，如设计领域模型时，在某个领域里面，某些业务逻辑是统一的，可以考虑放在该项目中，如果是某些公司，某些应用，很特殊的sql，可以考虑新建一个项目来存放。
由于我使用从Example派生类的方式，来实现不同应用所使用不同的特殊业务逻辑的方案，因此，我决定把AUTO部分代码也放在Example项目中，不再另外独立出一个项目，使用不同的文件夹分开管理其AUTO生成的文件与允许手动更新的文件。同时使用代码管理软件，对源码进行管理，从而降低手工代码被覆盖或被修改的风险。下面是最终实际应用的图：
其中，可能有的读者会问，前文中提及的BLL_Auto、DAO_Auto、Service_Auto、Config_Auto等，怎么这里没说的，只说了Model_Auto呢？这是因为，我这个设计确实只有Model_Auto，其实Model_Auto与Model基本上都是一样的，派生类Model中没有任何代码的，为的是日后，真的有需要而派生出这样一个类的，而其它的如BLL和DAO等的Auto类没有，是因为我这里使用了泛型，Auto类都是同一个基类，如BLL的基类：BaseManager<T>，DAO的基类：IBatisDAO<T>。至于Example.WinForm的应用层，目前我也只能考虑使用拷贝的方法来实现不同的应用部署在不同的企业中，只有尽量把通用的代码，写在基类里面，把业务特殊代码封装在这一层，这一层是变化最多的层了。控件摆放的位置都有可能因使用的人，而有各自的要求。
原创作品出自努力偷懒，转载请说明文章出处：http://www.cnblogs.com/kfarvid/