开篇一言
任何东西都不是一蹴而就，它往往有一个衍变的过程，把握事情的规律，会让我们更加深刻地理解它。而本文也是是顺着这个思路过来的。
第4代架构代码结构简图
如果你没有看过该系列的第一篇文章，那么你可能会对这篇文章有些困惑，所以建议读者先查看第一篇文章（【大型网站开发系列第一篇】——网站结构层次）。
从上面图片看来，一切都是那么的熟悉，跟大家在开发项目的过程中项目的设定基本一致。你可以把它说成是三层架构、多层架构，随便你怎么给它取名。但是第4代架构代码不仅仅是这样，这里只是一个最最基本的代码结构，实际开发中，我们还有Windows Serivces服务、Remoting Services服务，以及很多在Microsoft给我们提供的模板之上开发的各种服务。
详细代码结构图（最重要、也是最容易扩展的一个项目代码）
Jiangzhichao.Demo.DAC
做过数据库操作代码底层封装的人，应该差不多都知道这些类的含义，以及它们之间的一些关系。
抽象类DataHelper，是对各种数据库操作代码的一个抽象，提取出公共的代码逻辑，定义一些公共的代码接口让子类去实现，基本上做到了数据库和应用之间的解耦。
使用介绍
使用Jiangzhichao.Demo.DAC还是比较简单的，只要实例化一个DataHelper子类出来，然后使用该子类的实例进行数据库操作。这一步的操作我封装在了Jiangzhichao.Demo.DataAccess项目的BaseDataAccess类里面，只需要传入一个连接字符串和数据库类型（这个可以放在配置文件中），然后进行业务开发就OK了。
第5代架构的衍变成型
从上面代码结构简图可以看出，业务开发人员，只需要操作除Jiangzhichao.Demo.DAC项目以外的项目，业务开发人员不需要去了解Jiangzhichao.Demo.DAC里面对数据库操作的封装，唯一需要去了解的就是怎么去跟DBA沟通，让DBA提供符合业务需要的数据接口（sql语句、存储过程、方法）。
那么这就给底层开发人员一个很好的机会，专心研究底层架构，Jiangzhichao.Demo.DAC项目把数据和业务做了分离，底层开发人员在DAC这个项目中，只要保证对外的接口不变，内部的封装就可以随意改动，对业务开发人员一点影响都没有，这做到了两不误，业务开发人员专心业务，底层开发人员专心底层封装，并行开发，对整个项目的推进是个很大的帮助。
所以出现了第5代架构。第5代架构中，数据访问层就可以在目前DAC的基础上进行扩展，引入面向服务开发的概念，所有的数据都是以服务的方式提供给业务开发人员。那这个服务会是用什么方式提供呢？也许是WebServices，也许是Remoting，也许是WCF，还有可能是我们自己封装的XX框架，你还可以把目前热炒的分布式、海量存储等XX东西给弄进来。
本篇结语
下一篇是想写第5代架构原理的，处于自己对该架构的理解还不是很深，不敢轻易写出来，半个月后，等我对该架构思路理清楚后再写吧。所以下一篇，将是对该篇中提到的9个项目进行仔细讲解。
