所谓三层体系结构，是在客户端与数据库之间加入了一个"中间层"，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
用ASP.NET部署三层架构
ASP.NET 可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#, VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在 ASP页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。
下面分别就各层的实现举个制作留言簿的小例子。
我们首先在sqlserver数据库中建一个数据库GestDB,在GestDB中建表：Guestbook
第一步：打开VS.NET，点击文件－》新建－》空白解决方案，在弹出的新建项目中选择Visal C#项目，模板选择ASP.NET Web应用程序.在位置处给本方案命名为geustbook.如下图所示。
第二步：建数据库访问控件。单击上图的"确定"。在窗口右边的 "解决方案资源管理器"中右击"解决方案"guestbook""选择"添加"->"新建项目"，弹出如下窗口，如图模板选择类库，填写名称，位置。注意该类库理论上与留言簿的工程是没有关系的，所以存储位置可以任意。
第三步：建立逻辑处理层。同第二步，建立另一个控件BusinessLayer。此控件用来调用数据库控件，封装留言簿所有的逻辑处理。如下图所示。
第四步：关于引用。因为BUSINESSLAYER要用到系统的WEB控件和刚才建的DBLayer，所以必须把二者添加引用。右键点击BUSINESSLAYER的"引用"，选择.NET的"System.web.dll"双击选中
然后再点项目的"DBLayer"双击选中。
第五步：把GUESTBOOK ASP.NET项目跟逻辑层联系起来，同样使用添加引用。注意：在BUSINESSLAYER已经引用过DBLAYER，在GUESTBOOK处只需引用BUSINESSLAYER就可以了。
现在你的GUESTBOOK解决方案资源管理器应该是如下图所示：
如果不是的话，请检查一下上面的步骤哪里是否出错。
通过上述步骤，就已经成功部署了ASP.NET的三层架构。在guestbook这一层我们放置应用显示的ASP页面，在 BusinessLayer层，我们把所有的业务逻辑代码在该层实现。DataLayer层主要处理数据库的操作，供BusinessLayer层调用。
只要在各个层中实现具体的类就可以成功实施三层结构的应用程序了。
近来三层结构好像很火，我也看了一些介绍、资料、代码。感觉只是一个理论上的东西，和实际应用还是差了很远，尤其是执行效率和开发速度上更是需要注意。
三层结构一般的说法是：表示层（UI层）、业务逻辑层、数据层，那么这三层里都放些什么呢？或者说哪些代码应该放在哪一层里？
表示层没有甚么争议了，就是放html代码，加上一些绑定了什么的。
业务层，从字面上看是放业务逻辑，先放在这里暂且不谈。
数据层就有所分歧，一个是“死”的数据层，针对某一个项目而写的，无法直接用到其他的项目里；一个是通用数据层（或是叫数据层基类）。他提供一套通用的方法，比如SQLHelper类。
说到这里，提出第一个问题：存储过程属于哪一层？存储过程嘛，放在数据库里的，应该是属于数据层，但是在存储过程里面写什么，是由业务逻辑来决定的，那就应该算作业务层。？？到底该属于哪一层呢？
我的结构是通道模式，当然也有分层的思想。
简略地说就是 表现层 通道 存储过程 数据库 。 其中通道 就是一些通用的方法，比如通用的数据层、翻页控件等。
具体地说就是
1. .aspx 页面 html代码，web控件，页面排版等
2. .aspx.cs 提取数据，绑定到控件
3. .cs 业务逻辑，只在逻辑很复杂，或是会在两处或多处使用的函数，比如用户登录、判断用户是否登录、是否有权限。
4 .dll 通用数据层、常用函数、服务器控件（现在已经实现的是翻页控件、无刷新级联列表） 、提供连接字符串。
5. 存储过程
6. 数据库 保存数据、提供数据
看着是不是有点乱？其实是很方便的。1、2相当于表示层，3相当于业务逻辑层，4.是我说的“通道”，5、6即产上算作是数据层吧:)
5、6 不管你用什么结构都是要写的； 4 调试好了之后就不用修改的；3 里面的东东是不多的，目前还没有遇到需要很多代码来实现的逻辑；1、2 就是页面了，也是必须一写的。
首先要注意一点：asp.net（.net2.0还不是太熟，暂且不考虑）采用了代码后置的方法，这实际上也就是分了一层出来，大多数情况下没有必要再单独出一个.cs文件出来。如果有在多处使用的代码——比如身份验证——就要提取出来放在一个.cs文件里面，便于修改。
/// <summary>
/// 取得最新的贴子
/// </summary>
/// <returns></returns>
public DataSet GetNewrestThreads()
{
OleDbConnection OleCon=new OleDbConnection(Globals.ConnectString);
OleDbCommand OleCmd=new OleDbCommand();
OleCmd.CommandText="Forum_GetNewrestThreads";
OleCmd.CommandType=System.Data.CommandType.StoredProcedure;
OleCmd.Connection=OleCon;
return Common.Data.DataProvider.GetDataSetOle(OleCmd);
}
//Common.Data.DataProvider 是它的数据层
看到一些事例，在业务层里写这样的代码，出一看我还以为是数据层呢。业务层里的每一个函数都要定义Connection Command 这样的对象，是不是很浪费代码呀？
用我的数据层的话只需要两行就可以了。
Jyk.Dal add = new Jyk.Dal();
DataSet ds = add.runSPDataSet("Forum_GetNewrestThreads");
而代码很短直接写在.aspx.cs文件里面就可以了，没有必要写在.cs文件里。
我一直没有弄明白业务层里写什么，通过今天的思考，总算是弄清楚了。
业务逻辑呢实际上是两部分组成的，一个是实现业务逻辑；一个是决定在什么地方调用什么逻辑。
逻辑实现呢，大多是在存储过程里面实现了，简单得呢也可以用直接用查询语句实现。
下一个问题呢，从规范的角度来讲呢，应该是放在一个.cs文件里的，但是呢由于我的数据层已经很强大了，大大的简化了代码量，可以直接写在表示层里面。.cs文件只放一些在多处使用的业务逻辑。
用ASP.NET部署三层架构
ASP.NET 可以使用.NET平台快速方便的部署三层架构。ASP.NET革命性的变化是在网页中也使用基于事件的处理，可以指定处理的后台代码文件，可以使用C#, VB,J#作为后台代码的语言。.NET中可以方便的实现组件的装配，后台代码通过命名控件可以方便的使用自己定义的组件。显示层放在 ASP页面中，数据库操作和逻辑层用组件来实现，这样就很方便的实现了三层架构。
下面分别就各层的实现举个制作留言簿的小例子。
我们首先在sqlserver数据库中建一个数据库GestDB,在GestDB中建表：Guestbook
第一步：打开VS.NET，点击文件－》新建－》空白解决方案，在弹出的新建项目中选择Visal C#项目，模板选择ASP.NET Web应用程序.在位置处给本方案命名为geustbook.如下图所示。
第二步：建数据库访问控件。单击上图的"确定"。在窗口右边的 "解决方案资源管理器"中右击"解决方案"guestbook""选择"添加"->"新建项目"，弹出如下窗口，如图模板选择类库，填写名称，位置。注意该类库理论上与留言簿的工程是没有关系的，所以存储位置可以任意。
第三步：建立逻辑处理层。同第二步，建立另一个控件BusinessLayer。此控件用来调用数据库控件，封装留言簿所有的逻辑处理。如下图所示。
第四步：关于引用。因为BUSINESSLAYER要用到系统的WEB控件和刚才建的DBLayer，所以必须把二者添加引用。右键点击BUSINESSLAYER的"引用"，选择.NET的"System.web.dll"双击选中
然后再点项目的"DBLayer"双击选中。
第五步：把GUESTBOOK ASP.NET项目跟逻辑层联系起来，同样使用添加引用。注意：在BUSINESSLAYER已经引用过DBLAYER，在GUESTBOOK处只需引用BUSINESSLAYER就可以了。
现在你的GUESTBOOK解决方案资源管理器应该是如下图所示：
如果不是的话，请检查一下上面的步骤哪里是否出错。
通过上述步骤，就已经成功部署了ASP.NET的三层架构。在guestbook这一层我们放置应用显示的ASP页面，在 BusinessLayer层，我们把所有的业务逻辑代码在该层实现。DataLayer层主要处理数据库的操作，供BusinessLayer层调用。
只要在各个层中实现具体的类就可以成功实施三层结构的应用程序了。
近来三层结构好像很火，我也看了一些介绍、资料、代码。感觉只是一个理论上的东西，和实际应用还是差了很远，尤其是执行效率和开发速度上更是需要注意。
三层结构一般的说法是：表示层（UI层）、业务逻辑层、数据层，那么这三层里都放些什么呢？或者说哪些代码应该放在哪一层里？
表示层没有甚么争议了，就是放html代码，加上一些绑定了什么的。
业务层，从字面上看是放业务逻辑，先放在这里暂且不谈。
数据层就有所分歧，一个是“死”的数据层，针对某一个项目而写的，无法直接用到其他的项目里；一个是通用数据层（或是叫数据层基类）。他提供一套通用的方法，比如SQLHelper类。
说到这里，提出第一个问题：存储过程属于哪一层？存储过程嘛，放在数据库里的，应该是属于数据层，但是在存储过程里面写什么，是由业务逻辑来决定的，那就应该算作业务层。？？到底该属于哪一层呢？
我的结构是通道模式，当然也有分层的思想。
简略地说就是 表现层 通道 存储过程 数据库 。 其中通道 就是一些通用的方法，比如通用的数据层、翻页控件等。
具体地说就是
1. .aspx 页面 html代码，web控件，页面排版等
2. .aspx.cs 提取数据，绑定到控件
3. .cs 业务逻辑，只在逻辑很复杂，或是会在两处或多处使用的函数，比如用户登录、判断用户是否登录、是否有权限。
4 .dll 通用数据层、常用函数、服务器控件（现在已经实现的是翻页控件、无刷新级联列表） 、提供连接字符串。
5. 存储过程
6. 数据库 保存数据、提供数据
看着是不是有点乱？其实是很方便的。1、2相当于表示层，3相当于业务逻辑层，4.是我说的“通道”，5、6即产上算作是数据层吧:)
5、6 不管你用什么结构都是要写的； 4 调试好了之后就不用修改的；3 里面的东东是不多的，目前还没有遇到需要很多代码来实现的逻辑；1、2 就是页面了，也是必须一写的。
首先要注意一点：asp.net（.net2.0还不是太熟，暂且不考虑）采用了代码后置的方法，这实际上也就是分了一层出来，大多数情况下没有必要再单独出一个.cs文件出来。如果有在多处使用的代码——比如身份验证——就要提取出来放在一个.cs文件里面，便于修改。
/// <summary>
/// 取得最新的贴子
/// </summary>
/// <returns></returns>
public DataSet GetNewrestThreads()
{
OleDbConnection OleCon=new OleDbConnection(Globals.ConnectString);
OleDbCommand OleCmd=new OleDbCommand();
OleCmd.CommandText="Forum_GetNewrestThreads";
OleCmd.CommandType=System.Data.CommandType.StoredProcedure;
OleCmd.Connection=OleCon;
return Common.Data.DataProvider.GetDataSetOle(OleCmd);
}
//Common.Data.DataProvider 是它的数据层
看到一些事例，在业务层里写这样的代码，出一看我还以为是数据层呢。业务层里的每一个函数都要定义Connection Command 这样的对象，是不是很浪费代码呀？
用我的数据层的话只需要两行就可以了。
Jyk.Dal add = new Jyk.Dal();
DataSet ds = add.runSPDataSet("Forum_GetNewrestThreads");
而代码很短直接写在.aspx.cs文件里面就可以了，没有必要写在.cs文件里。
我一直没有弄明白业务层里写什么，通过今天的思考，总算是弄清楚了。
业务逻辑呢实际上是两部分组成的，一个是实现业务逻辑；一个是决定在什么地方调用什么逻辑。
逻辑实现呢，大多是在存储过程里面实现了，简单得呢也可以用直接用查询语句实现。
下一个问题呢，从规范的角度来讲呢，应该是放在一个.cs文件里的，但是呢由于我的数据层已经很强大了，大大的简化了代码量，可以直接写在表示层里面。.cs文件只放一些在多处使用的业务逻辑。
