分层分类

    分类

1.表现层（UI）展现给用户的界面，即用户在使用一个系统的时候所见所得。

作用：向用户展示特定业务数据

      采集用户的数据信息和操作

设计原则：

用户至上，兼顾简洁

 

2.业务逻辑层（BLL）针对具体问题的操作，也可以所示对数据层的操作，对数据业务逻辑处理。

作用：

从DAL中获取数据，已提供UI显示用

从UI中获取用户指令和数据，执行业务逻辑

从UI中获取用户指令和数据，通过DAL写入数据源

职责机制

UI--->BLL--->UI

UI--->BLL--->DAL--->BLL--->UI

 

3.数据访问层（DAL）：直接操作数据库针对数九的增删改查。

      DAL的作用：

从数据源加载数据（Select）

向数据源写入数据(Insert/Update)

从数据源删除数据(Delete)

4.实体层

       实体层会贯穿于三层中，参与数据的判断，所以有人把他会单独的分开，而我更倾向于把它判定到业务逻辑层。

三层结构的程序不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了，下面几个问题在你的项目里面：

1. UILayer里面只有少量（或者没有）SQL语句或者存储过程调用，并且这些语句保证不会修改数据?

2. 如果把UILayer拿掉，你的项目还能在Interface/API的层次上提供所有功能吗?

3.你的DAL可以移植到其他类似环境的项目吗?

4. 三个模块，可以分别运行于不同的服务器吗?

如果不是所有答案都为YES，那么你的项目还不能算是严格意义上的三层程序. 三层程序有一些需要约定遵守的规则：

1. 最关键的，UI层只能作为一个外壳，不能包含任何业务逻辑(BizLogic)的处理过程

2. 设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，以面向对象的方式

3. 不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关

4.不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群