通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。用于接收用户输入的数据和显示处理后用户需要的数据。
UI层和DAL层之间的桥梁。：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。业务逻辑具体包含：验证、计算、业务规则等等。
与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。
用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）
主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。
主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务．
1、分层就意味着组建的逻辑分组。例如，对用户界面，业务逻辑和数据访问组建应该使用不同的不同的层。
2、在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作，而不是提供其他操作。
3、在设计的每一个层接口时要考虑好物理边界。如果通信跨越了物理边界，使用基于消息操作；否则使用基于对象操作。
4、考虑使用接口类型（interface）来定义每层的接口。这将允许你创建该接口的不同实现，提高可测性。
5、对于Web应用程序，在表示层和业务逻辑层之间实现基于消息的接口是一个好主意，即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。
6最主要的就是不能跨层调用。各层之间通过参数来传递，也就是实体类。
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、结构清晰，耦合度低；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
1、降低了系统的性能。
这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
3、增加了开发成本。
（当任何一个地方发生变化时，都需要重新开发整个系统。“多层”放在一层，分工不明确耦合度高——难以适应需求变化，可维护性低、可扩展性低）
（发生在哪一层的变化，只需更改该层，不需要更改整个系统。层次清晰，分工明确，每层之间耦合度低——提高了效率，适应需求变化，可维护性高，可扩展性高）
三层架构是一个分层式的软件体系架构设计，它可适用于任何一个项目。
MVC是一个设计模式，它是根据项目的具体需求来决定是否适用于该项目。
三层架构的目的着重点是“高内聚，低耦合”，即解耦。
MVC的目的则是实现Web系统的职能分工，即职责划分。
MVC是Model-View-Controller，严格说这三个加起来以后才是三层架构中的WEB层，也就是说，MVC把三层架构中的WEB层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。
原文：http://blog.csdn.net/u010168160/article/details/27352729
