⼗、EnterpriseFrameWork框架的分层架构及意义（控制器、业
务对象、实体、D。。。
本章内容主要包括两个⽅⾯，⼀、是框架分层（控制器、业务对象、实体、Dao）的详细说明，⼆、是对⽐常⽤三层结构的区别和优势；
本⽂要点：
1.框架中的各个分层详细说明
2.对⽐常⽤三层结构的区别和优势
3.分享两个项⽬中的⼩经验
4.⽹络资料
我们先看⼀下前⾯实例中的解决⽅案⽬录：
我们再看各层之间的调⽤关系：
上图描叙的控制器有四种⽅式来操作数据库，
1）控制器调⽤实体，通过框架中的ORM来实现单表的操作
2）控制器直接操作数据库对象（oleDB），通过编写SQL语句访问数据库
3）控制器通过调⽤Dao操作数据库
4）控制器调⽤业务对象，业务对象再调⽤Dao操作数据库
还有就是每⼀层在程序结构中承担的⾓⾊；
⼀、Dao
数据访问对象，新建⼀个Dao必须继承继承框架中的AbstractDao对象，AbstractDao对象中封装了数据库操作对象oleDb，所以Dao中的⽅法都是直接编写SQL语句操作数据库；
public class BookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao
{
public DataTable GetBooks(string searchChar, int flag)
{
string strsql = @"SELECT * FROM dbo.Books WHERE BookName LIKE '%{0}%' AND Flag={1}";
strsql = string.Format(strsql, searchChar, flag);
return oleDb.GetDataTable(strsql);
}
      }
上⾯代码是实现对Sqlserver数据库的操作，如果要实现不同数据库的操作，如：Oracle、DB2等，要如何实现？很简单，先创建IBookDao接⼝，再分别实现SqlBookDao和OracleBookDao，控制器访问Dao只需调⽤IBookDao接⼝就⾏了，⽽最后操作哪个数据库的Dao在fig配置⽂件中配置好。
IBookDao接⼝
  public interface IBookDao
{
System.Data.DataTable GetBooks(string searchChar, int flag);
      }
SqlBookDao对象
public class SqlBookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao, Books.Dao.IBookDao
{
public DataTable GetBooks(string searchChar, int flag)
{
string strsql = @"SELECT * FROM dbo.Books WHERE BookName LIKE '%{0}%' AND Flag={1}";
strsql = string.Format(strsql, searchChar, flag);
return oleDb.GetDataTable(strsql);
}
      }
OracleBookDao对象
public class OracleBookDao : EFWCoreLib.CoreFrame.BusinessArchitecture.AbstractDao, Books.Dao.IBookDao
{
public DataTable GetBooks(string searchChar, int flag)jquery框架原理
{
string strsql = @"SELECT * FROM Books WHERE BookName LIKE '%{0}%' AND Flag={1}";
strsql = string.Format(strsql, searchChar, flag);
return oleDb.GetDataTable(strsql);
}
      }
控制器中通过NewDao<>操作⽅法，创建配置的SqlBookDao对象
综合上述，不同数据库Dao结构设计如下：
⼆、Entity实体
实体代码都是⽤⼯具，根据数据库表结构信息⽣成的；所有实体都必须继承框架中的AbstractEntity对象，⽽实体与数据库表之间的映射不需要另外xml配置⽂件，⽽是利⽤⾃定义标签实现ORM映射；TableAttribute标签映射实体类名与数据库表，ColumnAttribute标签映射实体属性与数据库表字段。⼀个实体映射到多个表也可以，直接类名上配置多个TableAttribute标签和属性上配置多个ColumnAttribute标签，不过要⽤标签的Alias参数区分。
三、ObjectModel业务对象
业务对象在书籍管理实例并没有建此对象，因为业务太简单了，只有当业务流程很复杂或范围涉及⼴的情况，就可以考虑建⼀些业务对象来解决这些问题；所有业务对象必须继承框架中的AbstractBusines对象，业务对象中不能直接操作数据库，必须通过Dao来访问。另外就是如果多个业务对象是⽤来解决同⼀个问题，⼀般我们使⽤⼯⼚模式来设计，在框架中可以使⽤fig配
置⽂件进⾏业务对象映射；
四、Controller控制器，包括WebController、WinController、WcfController、WcfClientController
控制器分为3种模式，不同模式分别建控制器。控制器在程序结构中的作⽤就是承上启下，⽐如WebController控制器，就是把调⽤逻辑层返回的数据结构转换为统⼀Json字符串传递给界⾯JqueryEasyUI。⽽不同的界⾯框架则需要对框架中的Webcontroller进⾏扩展，以后我们会详细讲解各种控制器的实现；
还有就是Controller中提供了数据库的操作对象OleDB，允许控制器直接编写SQL语句操作数据库，为什么要放开此功能，这也是在项⽬中遇到的实际情况⽽不得不妥协的⼀种设计；
同样所有控制器也都必须框架中的基类控制器，基于JqueryEasyUI的Webcontroller继承AbstractJqueryController对象，WinController继承BaseController对象，wcfController继承JsonWCFController对象；wcfClientController继承BaseWCFClientController对象；
再就是控制器暴露给界⾯UI，还必须加上控制器的⾃定义标签，WebController的WebController和WebMethod，WinController的
Menu，wcfClientController的WCFController和WCFMethod；
通过上⾯的介绍，应该对EnterpriseFrameWork框架的分层结构有⼀定得了解，下⾯我们讨论⼀下，与常⽤三层结构的区别与优势？
软件分层意义主要就包括解耦和复⽤，也许还能让代码维护与扩展更⽅便；三层结构分别包括界⾯层、逻辑层和数据层。EnterpriseFrameWork 框架中的分层也可以说是三层，只是叫法与承担的职责不⼀样，并且EnterpriseFrameWork框架中的分层可以随时变化的，不同情况有4种⽅式对分层进⾏调整，所以EnterpriseFrameWork框架分层的兼容性强。有哪些不同情况，可以总结为两种，⼀是根据具体功能的难易程度，⼆是根据开发⼈员的代码⽔平；
我们对⽐⼀下PetShop项⽬的程序结构：
PetShop项⽬名称及描述：(实现步骤为：4-3-6-5-2-1)
1、WEB＝表⽰层
2、BLL＝业务逻辑层
3、IDAL＝数据访问层接⼝定义
4、Model＝业务实体
5、DALFactory＝数据层的抽象⼯⼚(创建反射)
6、SQLServerDAL＝SQLServer数据访问层 / OracleDAL＝Oracle数据访问层 DBUtility 数据库访问组件基础类
其中3中的IDAL对应EnterpriseFrameWork框架中的Dao接⼝，Model对应框架中的实体，SQLServerDAL和OracleDAL对应不同数据库Dao；⽽不同的有5中的DALFactory在框架中是不需要的，只需配置⽂件中配置即可；2中的BLL也职责不⼀样，框架中更趋向领域模型的设计；1中的WEB表⽰层，框架中单独把Controller控制器分出来独⽴⼀层；所以对⽐两者发现其思想还是差别⽐较⼤的，个⼈觉得EnterpriseFrameWork框架除了在程序代码的解耦，更在业务、项⽬等实际情况⽅⾯更加合适；
接着再讨论⼀下：贫⾎模型与充⾎模型？
贫⾎模型：是指领域对象⾥只有get和set⽅法，或者包含少量的CRUD⽅法，所有的业务逻辑都不包含在内⽽是放在Business Logic层。
充⾎模型：层次结构和上⾯的差不多，不过⼤多业务逻辑和持久化放在Domain Object⾥⾯，Business Logic（业务逻辑层）只是简单封装部分业务逻辑以及控制事务、权限等。
对这两种模型的使⽤个⼈感觉⽐较深刻，以前还不知道这种写法是贫⾎模型，表⽣成所有实体，再就是调⽤实体的N个逻辑对象，这样的代码就越写越过程化，基本上⼀个系统分成⼏个逻辑对象就完成了，没有了对象的概念；后来就觉得这样不对，就把实体扩展成⼀个完整的业务对象，实现对这个实体的所有业务操作⽅法；这样刚开始还蛮有感觉，但后来越做越别扭，⼀是很多实体根本没有业务操作，还有就是⼀个业务操作会跨多个实体；在实体上来补充业务操作⽅法本来就不太合理，因为表结构的设计本来就不是基于⾯向对象的；所以后来就演变为现在EnterpriseFrameWork框架中ObjectModel这种模型，我叫做领域对象模型；简单的业务⾛第⼀种模式，复杂的业务就必须分析出领域模型并设计业务对象；
最后分享两个项⽬中的⼩经验，⼀个是与⼤学⾼校合作开发项⽬、另⼀个是⼩公司⽼板的见解；
与⼤学⾼校合作开发⼀个不算太复杂的项⽬，公司⽅负责需求的收集与分析，⾼校针对需求进⾏设计与开发；⾼校由⼀个研究⽣导师带队，也没⽤什么技术框架，就是常⽤的三层结构，合作的过程就不讲了，反正就是最后到我接⼿维护代码的时候就感觉到这个系统的坑⼈之处；⾸先不算复杂的系统项⽬建了⼗多个，代码⽂件很难，再就是每改⼀个⼩地⽅要改多个⽂件从界⾯层改到数据层；最受不了的就是代码的阅读与调试相当⿇烦，每层之间⼜通过⼀个⼯⼚反射类名⽅法名调⽤；最后我们得出的结论就是在实际项⽬千万不能交给⾼校开发，他们可以搞⼀些研究项⽬，做的时候⼜没有考虑到⼀些实际情况；
⼩公司⽼板的见解。⼀朋友⾃⼰做⽼板创业，懂点php⽹页开发，在学校招了⼏个刚毕业⽣准备研发⼀个新产品，要我帮忙他们搭建系统框架，我推荐最早框架给他们使⽤，那时候在Controller中并没有OleDB操作数据库；我先把系统的核⼼业务开发完成，招的⼏个毕业⽣就在此基础上继续完善系统，刚开始我在的时候还好，有什么不明⽩的我帮忙解决，后来我抽出来后，他们做着做着问题就暴露出来了，⼀个简单的功能很久都搞不出来，新产品讲究的就是速度嘛，马上要给客户看的；所以朋友急了开始原因，虽然朋友就会个php⽹页制作，但通过与⼏个毕业⽣深⼊沟通，他发现程序分层太复杂了，做⼀个功能要画界⾯，写控制器、写业务对象、写Dao才能完成，更难的他们根本对逻辑层的控制器、业务对象、Dao理解不了，所以⼀定要他们这样⽤就经常搞出⼀些莫名其妙的问题；朋友就说为什么不能直接在控制器中写sql语句，这样开发起来多简单？我就说这样放开不⾏，会破坏整个程序的分层结构，以后代码的维护、扩展都会有问题，但我的这些以后说服不了他，他觉得这些以后版本可以优化，现在就是要马上出来；最后只要在控制器也开放了Oledb操作数据库；
⽹络上对于三层结构的解释：
数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加⼊ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。在PetShop的数据访问层中，并没有使⽤ORM，从⽽导致了代码量的增加，可以看作是整个设计实现中的⼀⼤败笔。
业务逻辑层：是整个系统的核⼼，它与这个系统的业务（领域）有关。以PetShop为例，业务逻辑层的相关设计，均和⽹上宠物店特有的逻辑相关，例如查询宠物，下订单，添加宠物到购物车等等。如果涉及到数据库的访问，则调⽤数据访问层。
表⽰层：是系统的UI部分，负责使⽤者与整个系统的交互。在这⼀层中，理想的状态是不应包括系统的业务逻辑。表⽰层中的逻辑代码，仅与界⾯元素有关。在PetShop中，是利⽤ASP.Net来设计的，因此包含了许多Web控件和相关逻辑。
分层的好处
1、开发⼈员可以只关注整个结构中的其中某⼀层；
2、可以很容易的⽤新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复⽤。
概括来说，分层式设计可以达⾄如下⽬的：分散关注、松散耦合、逻辑复⽤、标准定义。
分层的坏处：
1、降低了系统的性能。这是不⾔⽽喻的。如果不采⽤分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。这种修改尤其体现在⾃上⽽下的⽅向。如果在表⽰层中需要增加⼀个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。