微软分层代码架构——简述

  用几句通俗的话,也就是比较官方的话给大家做一个简单的解释:

       框架(Framework)的一种定义认为是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法。另一种定义认为,框架是可被应用开发者定制的应用骨架。前者是从应用方面,而后者是从目的方面给出的定义。

  可以说,一个框架是一个可复用的设计构件,它规定了应用的体系结构,阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程,表现为一组抽象类以及其实例之间协作的方法,它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。

  框架,其实就是某种应用的半成品,就是一组组件,供你选用完成你自己的系统。简单说就是使用别人搭好的舞台,你来做表演。而且,框架一般是成熟的,不断升级的软件。

  软件系统随着业务的发展,变得越来越复杂,不同领域的业务所涉及到的知识、内容、问题非常非常多。如果每次都从头开发,那都是一个很漫长的事情,且并不一定能做好。团队协作开发时,没有了统一标准,大家各写各的,同样的重复的功能到处都是。由于没有统一调用规范,很难看懂别人写的代码,出现Bug或二次开发维护时,根本无从下手。

  而一个成熟的框架,它是模板化的代码,它会帮我们实现很多基础性的功能,我们只需要专心的实现所需要的业务逻辑就可以了。而很多底层功能操作,就可以完完全全不用做太多的考虑,框架已帮我们实现了。这样的话,整个团队的开发效率可想而知。另外对于团队成员的变动,也不用太过担心,框架的代码规范让我们能轻松的看懂其他开发人员所写的代码。

  一般来说,一个中小型项目,1到5人左右的开发团队,使用一般的三层结构就可以了,不用去细想框架要分三层还是五层,每个层之间要怎么实现解耦,要用什么设计模式。因为当今飞速发展的互联网时代,快才是王道。人工与时间成本才是重点中的重点,唯有快才能更好的生存下来并壮大。至于扩展功能、接口、分布式、并发、大数据等等问题,实际上过早考虑太多并不是好事情,还不如先做出来积累一定经验后再慢慢学习,慢慢升级框架。

  这里为什么说可以暂时理解为每个数据表对应一个实体?大家都知道,我们做系统的目的,是为用户提供服务,用户可不关心你的系统后台是怎么工作的,用户只关心软件是不是好用,界面是不是符合自己心意。用户在界面上轻松的增、删、改、查,那么数据库中也要有相应的增、删、改、查,而增删改查的具体操作对象就是数据库中的数据,说白了就是表中的字段。所以,将每个数据表作为一个实体类,实体类封装的属性对应到表中的字段,这样的话,实体在贯穿于三层之间时,就可以实现增删改查数据了。

                              

  三层及实体层之间的依赖关系 如图详述:

                      

  最后向大家做一个小结:

    框架(Framework)的一种是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法。

    软件架构(Software Architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计,是一个系统的草图,描述的对象是直接构成系统的抽象组件、各个组件之间的连接,明确细致的描述组件之间的通讯。

    框架具有代码模板化、可重用、高内聚(封装)、规范性、可扩展、可维护、协作开发和通用性的特点。

      三层是指表现层、业务逻辑层和数据访问层。

      表现层(UI):主要是指与用户交互的界面;

      业务逻辑层(BLL):该层主要负责处理系统的业务逻辑,以及充当表现层与数据访问层之间的桥梁,负责数据的传递和处理;

      数据访问层(DAL):主要实对数据的增、删、改、查。将存储在数据库中的数据提交给业务层,同时将业务层处理的数据保存到数据库。

posted on 2018-11-06 21:15 TM分寸 阅读(...) 评论(...) 编辑 收藏

导航

公告