ASP.NET架构

一. 二层架构

二层架构，就是将程序分为用户界面层和数据访问层。其本质是将访问数据库的代码放入数据访问层中，而用户界面层通过数据访问层对数据库进行操作。 相互作用关系如下：(“<—>”表示双向箭头)

用户界面 <—> 数据访问 <—> 数据库

二. 三层架构

三层架构，即将二层架构中的业务逻辑从数据访问层中分离出来，成为一个单独的业务逻辑层。将程序分为三层后，数据访问层就只管对数据库进行操作，而业务逻辑层负责对数据进行各种处理。 
从下至上分为三层，分别为：DAL（数据处理层）、BLL（业务逻辑层）、UI（用户接口层） 
1）数据访问层（database access layer，DAL）：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select，Insert，Update， Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化； 
2）业务逻辑层（business logic layer， BLL）：是整个系统的核心，它与这个系统的业务（领域）有关； 
3）表示层（user interface layer， UIA）：是系统的UI部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关； 
4）实体模型层（Model）：包含了所有的数据信息，这些数据信息以各种Entity实例的形式存在。是整个系统基础层次；

分层式结构究竟其优势何在：

1)、开发人员可以只关注整个结构中的其中某一层；

2)、可以很容易的用新的实现来替换原有层次的实现；

3)、可以降低层与层之间的依赖；

4)、有利于标准化；

5)、利于各层逻辑的复用。

概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：

1)、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2)、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计

需要注意的是，虽然三层架构有很多的好处，但如果你的程序很简单，或者将来肯定不会重用，或不一定要采用两层架构，也许采用两层或普通的程序开发速度会更快。要根据实际情况具体处理。

三. MVC

M 即Model(模型层)，主要负责出来业务逻辑以及数据库的交互； 
V 即View(视图层)，主要用于显示数据和提交数据； 
C 即Controller(控制器)，主要是用作捕获请求并控制请求转发；

MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块，主要是为了解决应用程序用户界面的样式替换问题，把展示数据的 HTML 页面尽可能的和业务代码分离。

四. 三层结构与MVC的区别

三层架构是界面层（UI）业务逻辑层（BLL）和数据访问层（DAL）构成的，而MVC是模型层（M）界面层（View）和控制层（Controller）构成的，而且他们之间也不对应。如果硬要给他们对应的话，那么三层架构中的UI对应MVC中的view都是用于显示以及获取界面的数据；三层架构中的BLL层和DAL层对应MVC中的Model层都是用于处理上层传递来的数据以及从数据库获取的数据的；MVC中的Controller最多算是三层架构中的UI的一部分。