三层架构概述

我们通常所实现的应用程序是基于二层架构的，表示层去直接访问数据访问层，所以开发人员必须具备美工、代码编写、数据库基础连接方法的背景知识，同时开发出的程序的难以维护和修改，而企业级应用程序的业务规则比较丰富，要求高灵活性和高可维护性，所以N层架构随之产生。我们这里只讨论N=3的架构，N>3的架构从本质上来说是对3层的扩展，这里不作讨论。如果个人开发小型网站，业务规则很少的话，二层的还是比较适合的。

下午显示的是一个典型的三层架构的结构图。
 

三层指的是：表示层、业务逻辑层和数据访问层。

表示层：用户界面、用户交互。（将有意义的数据转化成对用户有意义的数据）

业务逻辑层：包括业务实体组件和业务逻辑组件。业务实体组件一般是根据数据库中的表来构建的，业务逻辑组件主要是自定义一些业务规则，完成一些功能。（将原始数据转化成有意义的数据）

数据访问层：数据访问和存储。（取得原始数据）

三层架构主要体现出对程序分而治之的思想，数据访问层只负责提供原始数据，并不需要业务逻辑是什么；业务逻辑层调用数据访问层提供的方法，自定义一些业务逻辑，对数据进行加工，本身不需要了解数据访问层的实现；表示层直接调用业务逻辑提供的方法，把数据呈现给用户，同样，它也不需要了解业务逻辑层和数据访问层是怎么实现的。这样的好处就是降低耦合，易于程序的维护和扩展，每一层都可以由不同的Team来开发，开发出的程序比较有层次感。

 

ObjectDataSource控件

说到三层架构就不能不提到ObjectDataSource控件，它是表示层与业务逻辑层、表示层与数据访问层之间的桥梁。ObjectDataSource通过接口对象或者业务实体对象，将数据传递给表示层中的数据绑定控件。下面来说一下具体的细节：一、当应用程序中不存在业务逻辑层的时候，ObjectDatasource直接从数据访问层获取数据（一般都是DataView、DataSet对象）；二、当应用程序中实现业务逻辑层的时候，ObjectDataSource从业务逻辑层获取数据，数据被封装在业务实体的对象中，采用字段的形式存储。

最常用的属性：

TypeName：指定业务逻辑类的名称。

DataObjectTpyeName：指定业务实体类的名称。

SelectMethod：指定业务类中用于检索数据的方法名称。特别要注意后面不能加括号。

SelectParameters：指定SelectMethod用到的参数集合。可视化的编辑，我就不多说了。SelectMethod还有3个同胞兄弟，意思差不多，也不说了。
例子是开发指南上的，偷懒了~
https://files.cnblogs.com/hide0511/使用ObjectDataSource控件绑定数据访问层.rar
https://files.cnblogs.com/hide0511/使用ObjectDataSource控件绑定业务逻辑层.rar
https://files.cnblogs.com/hide0511/使用ObjectDataSource控件绑定类型化DataSet.rar