三层架构初步了解
三层架构(3--tier-application)
什么是三层架构？
三层架构通常是将整个业务应用划分为: UI 界面层 BLL 业务逻辑层，DAL数据访问层，Model 实体层 。区分层次的目的即为"高内聚,低耦合"的思想.
1 表现层(UI) ;通俗是展现给用户的界面,及用户在使用一个系统的时候他的所见所得.
2 业务逻辑层(BLL):针对具体问题操作,也可以说是对数据层的操作,对数据业务逻辑处理
3 数据访问层(DAL) : 该层所做事物直接访问数据库,针对数据库的增,删,改,查等.
为什么要分层？
三层结构主要是使项目结构更清楚，分工明确。有利于后期的为维护和升级。 他未必会提升性能，因为当子程序模块未执行结束时，主程序模块只能处于等待状态。这说明将应用程序划分层次，会带来期执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大小不同的效果。
注意：三层不是．ＮＥＴ的专利，也不是专门用在数据库上的技术，提示一种更加普适的架构设计理念。
各层作用？
为什么要应用 业务逻辑层呢
我们假设没有一段登录代码， 则可以这样处理WEB程序，外观层负责数据前台页面的数据， 然后传给中间层，中间层对数据进行处理，比如格式化 ，防止SQL注入等。这样的数据在传给访问层然后与数据进行操作，比如与数据库的用户名和密码匹配等等一些代码。
中间层的用途很多， 比如： 验证用户输入数据，缓存从数据库汇总读取的数据等等，但是， 终结业务层的实际目的是将“数据访问”的最基础的存储逻辑组合起来，形成一种业务规则。 例如： 在一个购物网站中有这样的一个规则： 在该网站第一次购物的用户，系统为其自动注册，这样的业务规则房子啊中间层最合适。
在“数据访问层”中，最好不要出现任何的“业务逻辑”。也就是所，要保证"数据访问"中的函数功能原子性。 即最小性和不可再分。”数据访问层“只管负责存储或读取数据就可以了。
实例
对“三层结构”的深入理解——从一家小餐馆说起
一个“三层结构”的Web应用程序，就好象是一家小餐馆。
n 表 现 层，所有的.aspx页面就好像是这家餐馆的菜谱。
n 中间业务层，就像是餐馆的服务生。
n 数据访问层，就像是餐馆的大厨师傅。
n 而我们这些网站浏览者，就是去餐馆吃饭的吃客了……
我们去一家餐馆吃饭，首先得看他们的菜谱，然后唤来服务生，告诉他我们想要吃的菜肴。服务生记下来以后，便会马上去通知大厨师傅要烹制这些菜。大厨师傅收到通知后，马上起火烧菜。过了不久，服务生便把一道一道香喷喷的、热气腾腾的美味端到我们的桌位上——
而我们访问一个基于asp.net技术的网站的时候，首先打开的是一个aspx页面。这个aspx页面的后台程序会去调用中间业务层的相应函数来获取结果。中间业务层又会去调用数据访问层的相应函数来获取结果。
对比一下示意图：
从示意图看，这两个过程是否非常相似呢？
不同的地方只是在于，去餐馆吃饭，需要吃客自己唤来服务生。而访问一个asp.net网站，菜单可以代替吃客唤来服务生。在最后的返回结果上，把结果返回给aspx页面，也就是等于把结果返回给浏览者了。
面向对象与实际的结合
我们知道建立桥需要砖块，应该是先准备好砖再来建造桥，不过为了讲解上的连贯。我们先建立桥，建造的过程中需要用到砖块在做。
Ｕ层其实就是桥，Ｃ层就是砖块，Ｄ层是原料（石头，沙子），这里说为什么Ｕ层要引用，依赖Ｄ层（而不是Ｕ层对Ｃ，Ｃ对Ｄ的层次），因为桥除了需要砖头，其实也需要石头和沙子。
实体图为下图
规则
三层结构的设计不是说把项目分层DAL,BLL,WebUI 三个模块就叫做三层了,下面几个问题是项目里面存在的问题
1 Uilayer 里面只有少量(或者没有) SQL语句或者存储过程调用,并且这些语句保证不会修改数据?
2 如果把UILayer 拿掉,你的项目还能在Interface/API的层次上提供所有功能么?
3 你的DAL 可以一直到其他类似的项目么?
4 三个模块,可以分别运行于不同的服务器码?
如果不是所有的答案都是YES,那么项目还不能算是严格意义的三层程序,三层程序有一些需要约定的规则:
1 最关键的.UI层只能最为严格外壳,不能包含任何的BizLogic的处理过程
2 设计时应该从BLLc出发,BLL层在API上应该事先所有BIzLogic,一面向对象的方式
3 不管数据是一个简单的SQLHerper 也好,还是带有Mapping 过的Classes也好,应该在一定抽象程度上做到与系统无关.
4 不管使用COM+(Enterprise Server),还是remoting,还是WEBService之类的远程对象技术,不管部署时候是不是真的分别部署到不同的服务器上,最起码在设计时候要这样的考虑.更好的.还得考虑多台服务器通过负载均衡作集群.