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

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

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

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

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

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

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

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

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

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

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

　　　　　　　　　　　　　　　　　　　　　　

　　最后向大家做一个小结：

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

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

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

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

　　　　　　表现层（ui）：主要是指与用户交互的界面；

　　　　　　业务逻辑层（bll）：该层主要负责处理系统的业务逻辑，以及充当表现层与数据访问层之间的桥梁，负责数据的传递和处理；

　　　　　　数据访问层（dal）：主要实对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。