.NET MVC与三层架构

2018-06-17 19:06:25来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

虽然接触了两者有一段时间了,但是有时还是会混淆概念,在此处不打算说明二者的区别,因为二者都是架构模式,并且也有一定的共存度,在实际开发中,严格区分意义不大。基于最近涉及到这部分知识就在复习下,编程过程中,基础概念更重要,而不是技术。

  先看看,三层架构吧,即UI(表示层),BLL(业务逻辑层),DAL(数据访问层):

    UI(表现层):主要是指用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

    BLL:(业务逻辑层):UI层和DAL层之间的桥梁实现业务逻辑。业务逻辑具体包含:验证、计算、业务规则等等。

    DAL:(数据访问层):与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。(当然这些操作都是基于UI层的。用户的需求反映给界面(UI),UI反映给BLLBLL反映给DALDAL进行数据的操作,操作后再一一返回,直到将用户所需数据反馈给用户)

                                        

  其实,真正使用过三层架构的都知道,三者之间是通过Entity传递数据的,Entity贯穿三层,将三者连接起来,同时也实现了对数据实体的封装,取代了个层之间多变量的数据传递(数据交流),大大的简化了数据交流,也降低了数据发生错误的概率。(Entity其实就是对数据库表实体的封装),Entity与三层之间的依赖关系:

    

 

  再看MVC架构,即M(model 模型·),V(view 视图),C(controller 控制器)三个部分。在MVC架构中这三部分是必须的,但我们也可以根据项目的实际需求与实际情况还能再增加,比如实现Service层或Repository层等,我们可以自行扩展,大幅提高了开发时的灵活性。

    Model(数据模型):用于封装与应用程序在商业逻辑上相关的数据,以及对其数据操作的处理方法(数据库的访问操作,即增删改查;数据结构的定义;数据格式的验证)。Model并不依赖于View和Controller,也就是说Model并不需要知道它会如何被显示出来或如何被应用,只需要专注于自己该有的责任即可。Model中常见的技术有Entity Framework(即EF)、NHibernate、LINQ to SQL、Typed DataSet和ADO.NET等。

    View(视图): 页面显示或获取用户输入,View需要负责将Controller传过来的数据配合“显示逻辑”呈现给用户,此处虽然View需要Contorller传递数据,但是View并没有依赖某个Controller,任何Controller只要能提供View所需要的数据,View就可以根据显示逻辑将其显示出来,是一种松散的关联关系。

    Controller(控制器):属于一种结果协调者的角色,因为M-V-C三个部分没有直接的联系,View无法直接与Model沟通,即Model可以操作数据,View可以显示数据,因此,VIew显示的数据需由Controller从Model获取后提供给View。即Controller的角色位于用户接口层和商业逻辑层中间。

 

  其中,MVC中最重要的特性是关注点分离和约定优于配置。关注点分离,简单地说就是“只注意需要注意的”,这样可以很好的解耦模块,各个单元的复杂度就相对降低,更容易开发,同时,也增强了程序的可维护性。约定优于配置,简单地说,就是开发过程中应该遵守的约定,如:Controller的文件名后面一定要以Controller结尾;View文件一定要放在VIews文件夹下;View的名称就是对应的Controller的Action名称;Web API的Action名称前面应该加上HTTP动词等等,这样有利于项目的后期开发与维护,以防止因人员流动而使项目无其他人愿意接手。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:微软 改变 开源【几个站点】

下一篇:MVC中学到的小知识(MVC中的跳转,传参)