三层架构(转载:http://www.cnblogs.com/s021368/articles/1271159.html)

什么是3层架构？

3层架构是一种“客户端－服务器”架构，在此架构中用户接口，商业逻辑，数据保存以及数据访问被设计为独立的模块。主要有3个层面，第一层（表现层，GUI层），第二层（商业对象，商业逻辑层），第三层（数据访问层）。这些层可以单独开发，单独测试。

为什么要把程序代码分为3层。把用户接口层，商业逻辑层，数据访问层分离有许多的优点。

在快速开发中重用商业逻辑组件，我们已经在系统中实现添加，更新，删除，查找客户数据的组件。这个组件已经开发并且测试通过，我们可以在其他要保存客户数据的项目中使用这个组件。

系统比较容易迁移，商业逻辑层与数据访问层是分离的，修改数据访问层不会影响到商业逻辑层。系统如果从用SQL Server存储数据迁移到用Oracle存储数据，并不需要修改商业逻辑层组件和GUI组件

系统容易修改，假如在商业层有一个小小的修改，我们不需要在用户的机器上重装整个系统。我们只需要更新商业逻辑组件就可以了。

应用程序开发人员可以并行，独立的开发单独的层。

1.   UI   Tier（User   Interface,   用户接口层）
                  表示层完成向用户展示界面，提供进一步操作的“驱动接口”，例如按钮，并显示结果。
          2.   Business   Tier（商业层）
                  完成数据加工，提供加工后的数据给表示层，或者数据层。又可以分为   BLL(Business   Logic   Layer,   商业逻辑)和DAL(Data   Access   Layer,   数据访问)。DAL负责存取数据，BLL负责对DAL层操作，对数据进行运算和操作。BLL也负责响应表示层的事件。

          3.   Data   Tier（数据层）
                  完成数据存储技术,   不管部署的时候是不是真的分别部署到不同的服务器上,   最起码在设计的时候要做这样的考虑,   更远的,   还得考虑多台服务器通过负载均衡作集群

所以考虑一个项目是不是应该应用三层/多层设计时,   先得考虑下是不是真的需要?   实际上大部分程序就开个WebApplication就足够了,   完全没必要作的这么复杂.   而多层结构,   是用于解决真正复杂的项目需求的.”

而且三层之间有时候也不用那么严格，得根据实际业务逻辑来判断使用。这也是软件开发所以没有一个固定流程的原因。

还有个俺收藏得
UI层：
浏览器   ——   要考虑一下不同的浏览器、和插件若干
js脚本   ——   ajax这一类的，数据验证了什么的。
显示数据   ——   放在.aspx   页面
提供数据   ——   放在.aspx.cs   页面
逻辑层：
业务逻辑   ——   承上启下，但是大多数情况只用一行代码就可以实现了。
数据逻辑   ——   组合SQL语句，存储过程的话就是给参数赋值了
数据层：
SQLHelp   ——   具有类似功能的东东
数据库里的存储过程   ——   不用存储过程的话就略掉
数据库里的视图   ——   同上，我比较喜欢用
数据库里的表   ——   基础的东东了，对于客户来说，里面的数据是最最重要的了。

  三层架构的困惑：为什么要分出数据访问层
http://community.csdn.net/Expert/TopicView.asp?id=4946236
三层架构之我见   ——   不同于一般的三层架构。也许对您会有所启发！
http://community.csdn.net/Expert/TopicView.asp?id=4949724
关于分层和架构的思考－－请重视业务逻辑!
http://community.csdn.net/Expert/TopicView.asp?id=4947750
小调查，大家现有项目系统构架都是怎么样的？
http://community.csdn.net/Expert/TopicView.asp?id=4937348
请教一个架构上的问题，在某些情况下，我是不是应该抛弃ORM的思想
http://community.csdn.net/Expert/TopicView.asp?id=4947610
。NET构架之我见
http://community.csdn.net/Expert/topic/4950/4950034.xml?temp=.4981195