在经典三层架构的基础上，通过开发实践，总结的四层架构设计，以后慢慢深化吧……
UI层
制作图形用户界面。
操作型的函数都应检测返回值，只有返回值为1，才可以继续运行。
查询型函数一般不必检测。
BLL层
只组织业务逻辑，不考虑合法性，目的在于展现清晰的函数结构。
有时也可以根据功能组装函数，起到桥梁的作用。
ECL层
对于UI层传下来的参数来说，检查合法性。共有的合法性检验放在全局检验函数里，私有的合法性检验放在函数体内，不合法直接显示不合法的原因，并停止下传DAL层，直接返回非1值。保证交给DAL层的都是合法数据。（不保证逻辑合法）
对于DAL层返回的值来说，如果一切正常，返回1，直接上传BLL层。如果出现逻辑错误，返回0。如果出现数据库错误，返回－1。
DAL层
专门操作数据库，数据库错误返回－1，逻辑错误返回0，并告知错误原因，成功返回1。不考虑数据合法性。
这样，在开发时：
1、分析业务逻辑，充分与用户交流；【BLL层开发人员】
2a、根据业务逻辑分析，制作UI层，并作为原型交由用户审核（可以适当运用原型设计工具，对于VS来说，图形化设计工具基本可以直接用来制作原型）；【UI层设计人员】
2b、根据业务逻辑分析，决定BLL层主要操作函数；【BLL层开发人员】
3a、由BLL层主要操作函数，确定共有合法性验证的内容，开始编写全局检验函数，并对于私有合法性检验，编写私有检验函数，基本完成ECL层；【ECL层开发人员】
3b、由BLL层主要操作函数，确定DAL层具体函数，基本完成DAL层；【DAL层开发人员】
4a、根据UI层的用户反馈信息，改进UI层；【UI层设计人员】
4b、对于用户提出的新需求，确定新的业务逻辑；【BLL层开发人员】
5a、继续UI层的原型审核；【UI层设计人员】
5b、根据新的业务逻辑，增加BLL层操作函数；【BLL层开发人员】
6a、根据BLL层新增操作函数，完成ECL层检验；【ECL层开发人员】
6b、根据BLL层新增操作函数，完成DAL层操作数据库；【DAL层开发人员】
7、重复4a到6b的步骤，直到用户对UI层的新需求不严重影响后台编码；
8、处理UI层接收的用户输入，全部传递字符串，完成UI层与BLL层的连接，完成项目。
这样设计的好处：
1、用户可以很快看到项目原型，并且用户的需求一旦不再变动，项目可以几乎立刻交付，避免因为拖延带来的用户需求变动；
2、分层处理，各司其职，充分提高开发效率，避免无效等待的大量发生；
3、开发的时间由用户的反馈速度决定，如果用户不积极，我们的员工也可以避免大量的加班；
4、迭代化的开发方式，可以使项目逐步进行，降低一次成型带来的较大风险；
5、ECL层的提出，既可以及时处理用户输入的不合法信息，又可以及时处理数据库错误，增大了BLL层的结构清晰度，让业务逻辑人员专心致志做逻辑。
6、不同层的人员先后参与开发，不仅可以交替休息，提高员工工作积极性，还重要的是，这样使得BLL层的分析人员可以专心致志分析业务逻辑，在一定程度上避免因时间仓促，导致分析错误并带来的后续连带错误；
设计初衷基本是这几条，其他的好处再慢慢体会吧……
事物总具有两面性……
这样设计的不足：
1、如果用户反馈的速度很快，这样的交替开发会显得工期较长（但是交替开发的机制，可以降低开发强度，避免大量加班的出现，对于员工开发积极性的提高，个人认为比工期长短重要）；
其他的不足目前还没有发现，随着个人阅历的增加慢慢发掘吧，如果您觉着存在某些大的问题，欢迎批评指正。
相比经典三层架构的好处：
1、引入ECL层，使得BLL层开发人员不必纠结于合法性检验，专心致志做逻辑分析；
2、交付之前完成UI和BLL层的连接，由于四层架构使得BLL层十分清晰，代码量降低，使得拼接很容易实现，进一步减少用户反馈与交付项目之间的时延，并且降低交付前的工作量，从而避免交付前的高强度加班。
其他的好处，再慢慢体会吧……
http://www.cnblogs.com/llacc2010/archive/2012/03/16/2399731.html
