《mvc与 三层 模型摸索》由会员分享，可在线阅读，更多相关《mvc与 三层 模型摸索（4页珍藏版）》请在金锄头文库上搜索。
1、MVC与三层模型摸索最近在学习mvc设计形式，拿它和三层架构做了一些比拟:我感受mvc设计形式，关键在于发生model，model即便mvc形式的灵魂，他包括了三层架构里面的实体规范层、行动法定层、数据拜会层;扼制器(Controller)用来采集view供给的用户数据，递交给model，同时归来model处理后的数据给view。model的设计能够参看三层架构的设计措施，将实体、行动法定(业务逻辑)和数据拜会离别，在数据拜会上能够利用orm框架。三层架构同样能够利用orm框架。个人感受三层架构和mvc都是很好的设计措施，目标都是减退系统的耦合性，长进重用率，长进系统的可维护性，能够依据迷恋举
2、行抉择。如何在三层架构和mvc之间举行取舍呢?可能说它们就和我所会意的一样，依据迷恋抉择，未曾性质的优劣。三层架构是最大约的项目分层收获，而MVC则是三层架构的一个变体，MVC是一种好的开发形式。率先你要打听MVC离别代表的是什么含义.M即Model(模型层)，重要负责出来业务逻辑以及数据库的交互V即View(视图层)，重要用于揭示数据和提交数据C即Controller(扼制器)，重要是用作捉拿哀求并扼制哀求转发三层:UI界面层BLL业务逻辑层，DAL数据拜会层，Model实体层MVC中的的M不是三层中的Model(实体层)，他其实包括三层中的BLL，DAL,Model,这是极其要当心的，这也
3、是他们之间的差异的关键所在其有点有如下:低耦合性高重用性和可实用性较低的生命周期成本迅速的安排可维护性利于于软件工程化管教当然优点也有缺点，那即便内部构造混杂，不草带会意，文件数量大，管教难度慷慨也就大概述在软件系统架构设计中，分层式构造是最常见，也是最重要的一种构造。微软评比的分层式构造等闲分为三层，从下至上离别为:数据拜会层、业务逻辑层(又或成为领土层)、表示层。三层构造原理:3个层次中，系统重要功能和业务逻辑都在业务逻辑层举行处理。所谓三层系统构造，是在客户端与数据库之间加入了一个其中层，也叫组件层。这里所说的三层系统，不是指物理上的三层，不是容易地放置三台机器即便三层系统构造，也不但仅
4、有B/S利用才是三层系统构造，三层是指逻辑上的三层，即便这三个层放置到一台机器上。三层系统的利用过程将业务法定、数据拜会、合法性校验等工作放到了其中层举行处理。通常情形下，客户端不直接与数据库举行交互，而是穿越COM/DCOM通信与其中层发生连接，再经由其中层与数据库举行交互。表示层位于最外层(最上层)，离用户最近。用于揭示数据和接收用户输入的数据，为用户供给一种交互式垄断的界面。业务逻辑层业务逻辑层(BusinessLogicLayer)无疑是系统架构中揭示中心价值的局部。它的关怀点重要凑近在业务法定的制订、业务流程的告终等与业务需求有关的系统设计，也即是说它是与系统所应付的领土(Domai
5、n)逻辑有关，许多时候，也将业务逻辑层称为领土层。例如MartinFowler在PatternsofEnterpriseApplicationArchitecture一书中，将全副架构分为三个重要的层:表示层、领土层和数据源层。作为领土驱动设计的前锋EricEvans，对业务逻辑层作了更精细地划分，细分为利用层与领土层，穿越度层进一步将领土逻辑与领土逻辑的处理计划离别。业务逻辑层在系统架构中的位置很关键，它处于数据拜会层与表示层其中，起到了数据沟通中继往开来的作用。由于层是一种弱耦合构造，层与层之间的依靠是向下的，基层对于上层而言是无知的，改换上层的设计对于其调用的基层而言未曾任何波及。万一在
6、分层设计时，顺从了面向接口设计的信念，那么这种向下的依靠也该当是一种弱依靠联系。因而在不改换接口定义的前提下，志愿的分层式架构，该当是一个扶持可抽取、可轮换的抽屉式架构。正因为如此，业务逻辑层的设计对于一个扶持可伸展的架构尤为关键，因为它扮演了两个不同的角色。对于数据拜会层而言，它是调用者;对于表示层而言，它却是被调用者。依靠与被依靠的联系都纠合在业务逻辑层上，如何告终依靠联系的解耦，则是除非告终业务逻辑之外留给设计师的任务。数据层数据拜会层:有时候也称为是永远层，其功能重要是负责数据库的拜会，能够拜会数据库系统、二进制文件、文本文档或是XML文档。容易的说法即便告终对数据表的Select，I
7、nsert，Update，Delete的垄断。万一要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的永远化。优点:1、开发人员能够只关怀全副构造中的其中某一层;2、能够很轻率的用新的告终来轮换原有层次的告终;3、能够减退层与层之间的依靠;4、利于于规范化;5、利于各层逻辑的复用。缺点:1、减退了系统的功能。这是显而易见的。万一不批准分层式构造，许多业务能够直接造访数据库，以此获得相应的数据，现今却定然穿越其中层来告终。2、有时会导致级联的修正。这种修正尤其展目前自上而下的方向。万一在表示层中必需添置一秉功能，为保证其设计相称分层式构造，可能必需在相应的业务逻辑层和
8、数据拜会层中都添置相应的代码。法定:三层构造的过程不是说把项目分成DAL,BLL,WebUI三个模块就叫三层了,下面几个问题在你的项目里面:1.UILayer里面只有少量(可能)的SQL语句可能存储过程调用,并且这些语句保证不会修正数据?2.万一把UILayer拿掉,你的项目还能在Inte*ce/API的层次上供给所有功能吗?3.你的DAL能够移植到其他相仿环境的项目吗?4.三个模块,能够离别运行于不同的服务器吗?万一不是所有答案都为YES,那么你的项目还不能算是严厉含义上的三层过程.三层过程有一些必需约定顺从的法定:1.最关键的,UI层只能作为一个外壳,不能包括任何BizLogic的处理过程
9、2.设计时该当从BLL动身,而不是UI动身.BLL层在API上该当告终所有BizLogic,以面向对象的措施3.不管数据层是一个容易的SqlHelper也好,还是带有Mapping过的Classes也好,该当在定然的笼统程度上做到系统无关4.不管利用COM+(EnterpriseService),还是Remoting,还是WebService之类的长途对象技巧,不管安排的时候是不是真的离别安排到不同的服务器上,最起码在设计的时候要做这么的琢磨,更远的,还得琢磨多台服务器穿越负载平衡作集群因而琢磨一个项目是不是该当利用三层/多层设计时,先得琢磨下是不是真的必需?切实上大局部过程就开个WebApp
10、lication就足够了,全面没必需作的这么混杂.而多层构造,是用于处理恳挚混杂的项目需求的。与MVC的差异MVC(模型Model-视图View-扼制器Controller)是一种设计形式，我们能够用它来创立在域对象和UI表示层对象之间的判别。同样是架构级别的，雷同的地方在于他们都有一个体现层，然而他们不同的地方在于其他的两个层。在三层架构中未曾定义Controller的观念。这是我感受最不同的地方。而MVC也未曾把业务的逻辑拜会当做两个层，这是批准三层架构或MVC搭建过程最重要的差异。当然了。在三层中也提到了Model，然而三层架构中Model的观念与MVC中Model的观念是不一样的，&;三层中标兵的Model层是已实体类构成的，而MVC里，则是由业务逻辑与拜会数据构成的。Strings=newString(Texthere);专利代办条例.
