浅谈三层架构（1）

举例了解：

最近在学习三层架构，先举个生活中常见的例子描述一下什么叫三层？为什么使用三层？



服务员只管接待客人；厨师只管烹炒客人要的美食；采购员只管看客人需求采购食品；分工为客人全放全面的服务。



这样即使某个服务员请假，那么只需要让其他的服务员来代替就可，而不可能说让厨师来代替吧！生活中如此，大家各自执行各自的职责，同步到软件系统中来：



这就是所谓的三层架构，分层说明白点其实就是还是实现“高内聚，低耦合”的思想。

具体分析：

1）介绍：

UI:主要是对用户的请求接受（假如顾客甲想要鱼香肉丝，顾客乙想来个红烧排骨……），以及数据的返回，为客户端提供应用程序的访问
BLL:针对具体问题的操作（针对顾客甲和乙的要求而进行操作），也可以说是对数据层的操作，对数据业务逻辑处理
DAL:该层所做事务直接操作数据库，针对数据的增添，删除，修改，查找进行操作（有无胡萝卜，排骨等等这些都需要添加，或者某些菜不新鲜了，也要去除才可）等

2）需要遵循的规则：

最关键的，UI层只能作为一个外壳，不能包含任何业务逻辑的处理过程，就如你是服务员的角色，服务好顾客就好，其他的和自己根本就无任何关系。
设计时应从BLL出发，而不是从UI出发，BLL层在API上，应该以面向对象的形式实现所有的业务逻辑；就如顾客去哪个饭店吃饭，虽然服务员的服务态度是必要的，但是最主要的还是看这个饭店的饿菜做的好不好吃，也就是说厨师的技术如何了，所以饭店在招聘的时候，还是以招聘高技术的厨师为主要。
不管数据层是一个简单的COM+,还是Remoting，还是WebService子类的远程对象技术，不管部署的时候是否真的部署到不同的服务器上，最起码在设计的时候要有这样的考虑.

3)从OOP思想考虑：

它是完全受控制的对象；
它具有面向对象的基本特征；
它可以自定义行为；
它消除了关系数据和对象之间的差异；

它为我们在关系数据库和对象之间架起一座桥梁。

对于三层，自己个人的理解则是不管职责简不简单，既然分工了，那就各自把各自的任务完成就好。不是因为某个层特别简单，就认为他不重要。只要分了层，每一层都要有明确的目的和功能实现，对于三层的理解，待下一篇博客继续学习。