三层架构/业务逻辑层

Question

三层用了几个月 但一直都不明白业务逻辑的实用, 好像业务逻辑层只是传递一用数据 就没用了  那位大虾能帮解释下 最好用代码

Answer 1

即数据层、业务逻辑层和UI层分离。基本上这三层的逻辑分得很清晰，上层对于下层来讲基本是不可视的，即数据层不会管业务层是什么，只需提供服务；业务层也仅仅向UI层提供服务。   
  但是在实现的时候，项目组就有不同意见，我作为这个系统的架构设计的主持者，以前我使用的办法是，为每一层创建一个或几个项目，上层引用下层的DLL服务，即上层对下层是依赖关系。但今天我收到一个同事的设计建议，他把层与层之间的关系变成继承关系了，即针对一个业务实体（以下简称实体,例始订单），他会先从最底层的数据层，通过继承数据访问类，得到数据访问能力（我原来是用引用，即依赖来实现），而企业层又继承了实体来得到实体的数据。这样对于每个实体，如订单，他可以从订单的实体开始，继承一个可以直接访问数据库的Base类来得到数据库访问能力；订单的业务规则又继承订单实体来得到订单的数据，如此下去，直到最顶层。   
  就是说我使用横向的方法把系统划分，权限系统的层次来组织；而他的方法是根据系统中出现的实体，把系统纵向划分。开始我还是反对这种方法，但后来想了想，觉得也有一点道理。我是把一个系统划成三层，他是把一个实体划分成三屋，这样把一堆三堆的实体组织起来，也算是三层架构了。真的有点困惑，但老是觉得这种方法有些不妥，请大家讨论一下这两种方法的优缺点。也希望大家能发表一下对于层次划分的看法。谢谢。