WEB技术之四层架构

如果你的系统是大型的软件开发，那你就要做好更多层的分解，但是原则和理论上，我认为，不用分得太细。我们都知道，MVC模式把系统，分成Model、View、Controller。这样的分法是把表示层同逻辑层分开，也就是说把页面设计师同软件设计师分开。系统分析师再把各个功能写成接口，软件设计师就可以通过业务逻辑来写程序。

我所说的四层架构的分法，就是想把软件设计师工作量降下来，减少重复性的代码，提高开发速度，使软件有相当好的可维护、易扩展，这种四层架构对多人开发同软件来说，可以有个清晰的思路。我把系统分成表示层(UI)、业务逻辑层(Bussiness)、数据访问层(DataAccess)、数据实体层(DataEnity)。如果你还考虑到数据库设计的话，就是五层架构。我的出发点是从软件设计师角度，所以说是四层。其中，最好把所有的存储过程和SQL语句都写在数据库里，可以便于数据库的改变的修改和维护，同时也可以减少程序中的不稳定性。接下来，就是讲到如果更合理、更有效地把复杂的系统分析成多层，以达到系统的结构清晰、提高速度。

数据实体层(DataEnity)就是把实际数据库里的映射到内存中，也称为OMapping。其中有数据框架(.XSD格式)、也有微软提供的方法：继承DataSet、DataTable等。这层也是对微软技术的熟悉程度，对.net FrameWork类库中ADO.NET的学习是很关键的。

表示层主要就是做好合理的、适合客户的页面，这主要是美工的工作，程序员只需把对应的数据传过去就行了。当然，这就是你对ASP.NET控件的熟悉程度了。也是对微软技术学习中慢慢积累起来的。如果客户有需求你做电子商务，那你就要考虑用到WebServer,还要用到XML。从系统分析来说，表示层就是输入操作与输出操作的平台，你要把要输入的数据转换到下面一层及业务逻辑层(Bussiness)要可以操作数据，和把下层业务逻辑层(Bussiness)传出的数据，转成客户想要的效果，格式有很多种：是Office的格式（.doc/.exel等），还是图形图像，还是报表等及其它格式。对WEB技术来说，我们要把页面设计的一些元素统一管理，可以创建一个图书馆(Lib)：图片放入(Images)、脚本放入(Js)、CSS。其中还有上传图片、附件可以新建一个文件夹(LoadFilder)。做成这些程序设计外的准备以方便设计阶段的有上清晰的认识。

数据访问层(DataAccess)是.NET的核心技术的运用，当从这层的表面意思，你应该知道，这是对数据进行底层和原始数据的操作，要把提高开发速度与质量就是做好数据访问层的分析的优化。当然，业务逻辑层的业务逻辑分析很重要的，我现在讨论的数据访问层只对SQL Server数据库的操作，不讨论对其他数据库的操作。对数据库操作，要做到事务处理及异常捕获，及各种不种数据库之间联系。比如：对单表的操作、对联系表的操作，对不同数据库间的操作，从SQL语句来说，就是做好Insert、Select、update、delete的应用，对数据库的操作就是可以返回不同的数据类型，可是DataSet、DataTable、DataReader、Bool等，在.net架构里，可以把这一层基类写详细、写完善，把它生成DLL文件。只要通过组件的引用就可以现实数据访问的功能，所以你写好了，就可以把数据访问层的写代码量的时间省下来。数据访问层主要是能对数据进行四种常用操作，也就是数据读入输出的作用，可以用SQL语句，也可以用参数如：DataTable的变通方法。程序设计的开发，就是从数据库设计开始，这足以说明数据库设计的关键。

现在来谈谈业务逻辑层(Bussiness)，我在学习其他的多层架构时，在想这多层架构嘛，只要一个就够了，只要能提高开发速度，达到可易维护性、可扩展，就行了。有一种架构，把页面写类库完全分开，这就是用到CodeBehind技术，在开源的时代，我个人认为这种代码才是最好实现隐藏性把页面与程序的彻底的分开，使系统有很大的扩展空间，这种方案有待下次讨论，这里先做个标记。此层关系系统是否可用的关键层，越是关键就越觉得模式的重要性，一种做法是：同数据访问层相对应，把概要设计分出的角色类添加方法、属性、事件、索引、接口。真正代码的实现部分就在这里，这是一个智慧的地方。可是没有人注意到这一点，只认为这一些的代码无非是对数据访问层的一种重用。第二种做法是：定义接口把它的代码实现部分包装起来。在这种做法中，可以用到多种设计模式。

有的人把通用的基类及通用的函数到通用层，或是把通用的基类写到各个层类。这是种不可取的方法。如果有一个框架层(FrameWork)，这一层做什么用的呢？就是要通用的类库集中在这层。也是一个通用的基类，可以把一些常用的基类换在这层。也可以动态引用动态类库。对软件技术开发来说，对已有技术的一种引用是一种聪明的做法、也最有效的做法。

分层分得太多可能会增加软件的复杂程度。如果是小型性软件，要的就是简单与易用，没有必要分太多，对于扩展性的问题，可以运用框架层来解决。