三层体系结构的概念

BLL将USL与DAL隔开了，并且加入了业务规章各层的作用：数据数据访问层:主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，详细为业务规律层或表示层供应数据服务.:业务规律层:主要是针对详细的问题的操作，也可以理解成对数据层的操作,对数据业务规律处理，假如说数据层是积木，那规律层就是对这些积木的搭建。:表示层:主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx,假如规律层相当强大和完善，无论表现层如何定义和更改，规律层都能完善地供应服务。详细的区分方法：数据数据访问层:主要看你的数据层里面有没有包含规律处理，实际上他的各个函数主要完成各个对数据文件的操作。而不必管其他操作。:业务规律层:主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。:表示层:主要对用户的恳求接受，以及数据的返回，为客户端供应应用程序的访问。三层结构解释所谓三层体系结构，是在客户端与数据库之间加入了一个中间层，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简洁地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指规律上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规章、数据访问、合法性校验等工作放到了中间层进行处理。通常状况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换.开发人员可以将应用的商业规律放在中间层应用服务器上，把应用的业务规律与用户界面分开。在保证客户端功能的前提下，为用户供应一个简洁的界面。这意味着假如需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务规律的分析、设计和开发，简化了应用系统的开发、更新和升级工作。那么为什么要应用“中间业务层”呢？举些例子：我们假设有一段登录代码，则可以这样处理Web程序，外观层负责接收前台页面的数据，然后传给中间层，中间层对数据进行处理，比如格式化，防SQL注入等等一些，这样的数据再传给数据访问层然后与数据库进行操作，比如与数据库的用户名和密码匹配等等一些代码。"中间业务层”的用途有很多，例如：验证用户输入数据、缓存从数据库中读取的数据等等.・・・・・但是据中间业务层"的实际目的是将"数据访问层"的最基础的存储规律组合起来，形成一种业务规章。例如:"在一个购物网站中有这样的一个规章：在该网站第一次购物的用户，系统为其自动注册”。这样的业务规律放在中间层最合适：在"数据访问层"中，最好不要消失任何"业务规律"！也就是说，要保证"数据访问层"的中的函数功能的原子性！即最小性和不行再分。"数据访问层"只管负责存储或读取数据就可以了。ASP.NET中的三层结构说明完善的三层结构的要求是:修改表现层而不用修改规律层,修改规律层而不用修改数据层。否则你的应用是不是多层结构，或者说是层结构的划分和组织上是不是有问题就很难说.不同的应用有不同的理解，这只是一个概念的问题.理解ASP.NET中的三层结构——为什么要分三层？我们用三层结构主要是使项目结构更清晰，分工更明确，有利于后期的维护和升级。它未必会提升性能，由于当子程序模块未执行结束时，主程序模块只能处于等待状态。这说明将应用程序划分层次，会带来其执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大不相同的效果。需要说明一下，三层结构不是.NET的专利，也不是特地用在数据库上的技术。它是一种更加普适的架构设计理念。此种架构要在数据库设计上留意表之间的关系，尽力满意主与子的关系。在功能上对用户要有肯定的限制，不要表现在对于子表的删除操作肯定要慎重，以免造成主表与子表的数据在规律上消失的主表的外键在子表中没有相对应的值。对于表的综合查询方法是：先对主表查询，调用主表所对应的DL。再依据主表的纪录分别对每一个子表进行查询。将自表的查询结果添加的主表后，形成一个大的查询集合。对于表的操作（增删改）：此时只对主表进行操作，调用主表对应的DL中的操作方法。RL层是规律推断层，主要是对页面上传入的数据进行规律推断。RL层之上就是UI如何建立一个三层体系结构解决方案新建一个空白解决方案。然后："添加"-"新建项目"-"其他项目"-"企业级模版项目"-"C#生成块"-"数据访问"（数据层，下简称D层）"添加"-"新建项目"-"其他项目"-"企业级模版项目"-"C#生成块"-"业务规章"（业务层，下简称C层）"添加"-"新建项目"-"其他项目"-"企业级模版项目"-"C#生成块"-"Web用户界面"（界面层，下简称U层）右键点"解决方案"-"项目依靠项"，设置U依靠于D、C,C依靠于D。对U添加引用D、C,对C添加引用Do到此为止，一个三层的架子建立起来了。我上面说的很详细很"傻瓜"，知道的人觉得我废话，其实我这段时间很剧烈的感觉到特别多的人其实对这个简洁的过程完全不了解。虽然不反对建2个“空项目"和1个"AspnetWeb应用程序项目"也可以作为3层的框架，而且相当多的人认为其实这些"企业级模板项目"其实就是个空项目，这是一个误区。没错，企业级模板项目你从解决方案资源管理器里看它是个什么也没有的，但是你可以用记事本打开项目文件，观察不同了吧？？有些东西在背后，你是看不见的，不过系统已经做好了。也就是说，假如你在c层里的某个类里"usingSystemDataSqlClineit",或者使用一^SqlConnection对象，编译时候不会出错，但是会在"任务列表”里生成一些"策略警告"，警告你在C层里不要放应当放在D层的东西（虽然就程序来说没错，但是可读性可维护性就打了折扣）而这种功能，空项目是无法给你的。在新TraceLWord3中，应用了"企业级模板项目”。把原来的LWordTask.cs,并放置到一个单一的项目里，项目名称为：AccessTask。解决方案中又新建了一个名称为：InterService的项目，该项目中包含一个LWordService.cs程序文件，它便是"中间业务层"程序。为了不重复命名，TraceLWord3的网站被放置到了WebUI项目中。更完整的代码,可以在CodePackage/TraceLWord3名目中找到 面象对象与实际的结合我们知道建桥需要砖块，应当是先预备好砖再来建桥，不过为了讲解上的挨次性和连贯性，简洁性。我们先建桥，建的过程中需要砖块再现做，这样就不会多出来"桥不需要的东西"。留意在实际中，还是应当先预备砖块。U层其实就是桥，C层是砖块，D层是原料（石头、沙子X这也解释前面为什么U层要引用、依靠D层（而不是U对C,C对D的层次），由于桥除了需要砖头，其实也需要石头沙子。"三层结构”的缺点有些网友在读完这篇文章前作之后，对我提出了一些质疑，这提示我文章至此还没有提及"三层结构"的缺点。"三层结构”这个词眼好像始终都很热门，究其缘由，或许是这种开发模式应用的比较普遍。但是"三层结构"却并不是百试百灵的“万灵药"，它也存在着缺点。下面就来说说它的缺点……"三层结构"开发模式的一个特别明显的缺点就是其执行速度不够快。当然这个“执行速度”是相对于非分层的应用程序来说的。从文中所给出的时序图来看,也明显的暴露了这一缺点。TraceLWordl和TraceLWord2没有分层，直接调用的ADO.NET所供应的类来猎取数据。但是，TraceLWord6确要经过多次调用才能猎取到数据。在子程序模块程序没有返回时，主程序模块只能处于等待状态。所以在执行速度上，留言板的版本越高，排名却越靠后。"三层结构"开发模式，不适用于对执行速度要求过于苛刻的系统，例如:在线订票，在线炒股等等……它比较擅长于商业规章简洁变化的系统。"三层结构"开发模式，入门难度够高，难于理解和学习。这是对于初学程序设计的人来说的。以这种模式开发出来的软件，代码量通常要稍稍多一些。这往往会令初学者沉没在茫茫的代码之中。望之生畏，对其产生反感，也是可以理解的……其实，无论哪一种开发模式或方法，都是有利有弊的。不会存在一种“万用法"可以解决任何问题。所以"三层结构”这个词眼也不会是个例外！是否采纳这个模式进行系统开发，要作出比较、权衡之后才可以。切忌滥用！参加资料MainDoc.rar（《浅谈"三层结构"原理与用意》1.30M）petshop4.0的体系结构（只是略微看了一下，了解一下结构）简介：PetShop随着版本的不断更新，至现在基于.Net2.0的PetShop4.0为止，整个设计渐渐变得成熟而优雅，而且有很多可以借鉴之处。PetShop是一个小型的项目，系统架构与代码都比较简洁，却也凸现了很多颇有价值的设计与开发理念。下载地址：PetShop架构设计三层"应用结构：数据访问层、业务规律层