cleverstar
给你点资料一般讲到三层架构，其实就是将整个业务应用划分为表示层、业务逻辑层、数据访问层等。 三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。 普通三层：数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。 表示层UI：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。 通用类库Common：通用的辅助工具类 工程模式：简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。工厂角色（Creator）是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。 抽象产品角色（Product）是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。 具体产品角色（Concrete Product）继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。 通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通 讯与中间层建立连接，再经由中间层与数据库进行交换 完善的三层结构的要求是:修改表现层而不用修改逻辑层，修改逻辑层而不用修改数据层 否则你的应用是不是多层结构，或者说是层结构的划分和组织上是不是有问题就很难说 不同的应用有不同的理解，这是一个概念的问题． MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。 MVC（模型Model-视图View-控制器Controller）是一种设计模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。 同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。 在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。 在ASP NET中的MVC架构编写的，具有极其良好的可扩展性。它可以轻松实现以下功能： ①实现一个模型的多个视图；②采用多个控制器；③当模型改变时，所有视图将自动刷新；④所有的控制器将相互独立工作。这就是MVC架构的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC架构实现的应用程序具有极其良好的可扩展性，是ASP NET面向对象编程的未来方向。MVC的不足体现在以下几个方面：（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。（4）目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。三层架构是将代码按其作用分成三部分，每部分解决自己负责的流程 三层架构的功用之处，在于驾驭大型web程序的结构，使之便于管理和扩展 在设计UI的时候，我们不需要关心其中的逻辑和数据问题，只需要空出对应的位置，用于放置数据 在设计和修改的时候，要解决的只是HTML的结构，代码看起来干净利落，做起来也是干净利落 UI直接将程序逻辑的任务丢给BLL，BLL就开始构建具体的实现细节BLL的创建依赖于业务 例如一个文章系统，BLL_Aticle就表示它是用于对文章的处理的BLL_Aticle可以提供给UI一个文章列表的recordset，显示在UI的预留位置 当BLL_Aticle需要从数据库中获取数据的时候，就将任务丢给DAL层 DAL层专门负责和数据库打交道，它从BLL获取参数，组织一个有效的SQL，建立数据库连接，执行SQL进行更新或获取，将返回的数据交给BLL 每一部分的业务都集中于一个UI-BLL-DAL的链中，上下清晰了然 至于是怎样的便于管理和扩展，将在后面结合实例进行分析 复杂的生命形式必有复杂的生存法则，若想在自己的项目中应用好三层架构，需要多用点心体会其中的应用法则 我对三层架构的理解还不够深，这些文章能算是抛砖引玉就不错了大家在阅读当中不要局限于我所构思的法则，要多向具体的应用中去实践，根据具体情况，寻出自己的法则 有所感悟，就记得写下来，这种感悟是进步的契机，但必然不是最终的结果有了感悟就拿去应用，可以发现它的优劣，继续完善三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。 史明媛回答 
有图片的，这里发不了图片，满意我的论文加分后联系我，我发给你。 基于关系数据库的模式匹配技术研究 摘 要 随着 网络 技术的 发展 ，信息处理需要对大量的、异构的数据源的数据进行统一存取，多源异构数据的集成 问题 就显得十分重要。而模式匹配是数据集成领域的一个基本技术。文章提出一种解决关系数据库语义冲突问题的模式匹配技术，以实现异构数据的共享与互操作。 关键词 数据集成；模式匹配；语义冲突 1 引言 随着 计算 机及网络技术的快速发展，网络上的各种信息以指数级爆炸性增长，成为了一个巨大的信息库，同时各 企业 单位开发了大量的软硬件平台各异的 应用 系统，在各种应用系统下又积累了丰富的数据资源。这样就形成了成千上万个异构的数据源，多为传统的关系数据库数据。这些数据资源由于软硬件平台各异、数据模型各异而形成了异构数据，使各数据源间的互操作变得复杂。为了更好地利用这些异构信息，以及不造成企业应用系统的重复建设和数据资源的浪费，模式匹配技术吸引了众多关注。本文针对模式匹配过程中存在的语义冲突进行分类，并提出了相应的解决策略，以达到异构数据源的共享和互操作。 2 模式匹配中的冲突问题 在数据集成领域中，由于数据源系统多是独立开发，数据源是相对自治的，因此描述数据的数据模型或存储结构经常会出现模式的不一致，数据源的自治性和数据源模式的异构性使数据源在共享和互操作上存在了语义冲突。这些正是模式匹配的焦点问题，它们形式上的性质使得人们很容易想到要用模式匹配去解决逻辑、语义和知识的描述问题。 对于描述模式匹配中的语义冲突有两种较有代表性的分类[4]。第一种分类将冲突分为异类冲突、命名冲突、语义冲突和结构冲突。第二种分类主要是对第一类异类冲突概念的一个细致的改进，但和其它分类仍有细微的不同，它把异类冲突看作是语义不一致的一类(如语义冲突)，把冲突分为命名冲突、域冲突、元数据冲突、结构冲突、属性丢失和硬件/软件不同。 模式匹配是一项复杂而繁重的任务，所能集成的数据源越来越多，上述冲突情况也会越来越普遍，想解决所有的模式冲突是不现实的。本文主要解决关系数据模式之间的语义冲突。 3 模式匹配中的语义冲突 本文所提出的模式匹配 方法 是根据关系数据库的特点设计的。关系数据库中关系的基本单位是属性，属性本身就包含着语义信息，因此异构数据源语义相似性就围绕着数据源模式中的属性来进行，并在匹配的过程中解决异构数据源模式之间的一系列语义冲突。 1 语义匹配体系结构 本文提出的语义匹配体系结构采用数据集成中的虚拟法数据集成系统的典型体系结构，采用将局部模式匹配到全局模式的语义匹配体系结构，自下而上地建立全局模式。首先进行模式转化，消除因各种局部数据模式之间的差异所带来的 影响 ，解决各种局部模式之间的语义冲突等，然后在转化后的模式的基础上进行模式匹配，其主要手段是提供各数据源的虚拟的集成视图。 数据仍保存在各数据源上，集成系统仅提供一个虚拟的集成视图和对该集成视图的查询的处理机制。系统能自动地将用户对集成模式的查询请求转换成对各异构数据源的查询。在这种体系结构中，中间层根本不实际存储数据，当客户端发出查询请求时，仅是简单地将查询发送到适当的数据源上。由于该方法不需要重复存储大量数据，并能保证查询到最新的数据，因此比较适合于高度自治、集成数量多且更新变化快的异构数据源集成。 本文中的语义匹配的体系结构如图1所示。 2 关系数据库模式中语义冲突问题分类及其解决策略 大多数数据库系统提供了一套概念结构来对现实世界的数据进行建模。每一个概念结构被认为是一个类型，它可以是一种复杂类型或一种基本类型。类型和它所表示的数据间的联系就称为语义[3]。 在关系数据库中，一个关系模式是一个有序对(R，c)，其中R为模式所指向的关系(表)的名称，而c则为具有不同名称的属性的有限集。同时，属性也是一个有序对(N，D)，其中N为属性的名称，而D则为一个域。可以看出关系模式的基本单位是属性。属性本身就包含着语义信息，因此模式语义相似性就围绕模式中的属性来进行，并在模式匹配的过程中解决异构数据库模式之间的一系列语义冲突。 根据语义的定义，在关系数据库系统中，语义系统是由模式、模式的属性、模式中属性之间的联系和模式间的属性之间的联系构成。这里将语义分为3级：模式级、属性级和实例级。下面将异构模式中存在的语义冲突问题进行了分类，并阐述了各种语义冲突的解决策略： 1)模式级冲突 (1)关系命名冲突。包括关系名同义词和关系名同形异义词。前者进行换名或建立关系名同义词表以记载该类冲突；后者进行换名或建立关系名同形异义词表以记载该类冲突。 (2)关系结构冲突。分为包含冲突和相交冲突。包含冲突是指在含义相同的两个关系 R1 和 R2 中一个关系的属性集是另一个的属性子集。相交冲突是指两关系属性集的交不为空，我们用 attrset 代表关系的属性集。对包含冲突：①如果两个关系的属性集相同即attrset(R1)=attrset(R2)，则合并这两个对象，Merge(R1， R2)into R3；②如果 attrset(R1) attrset(R2)，则 attrset(R2')=attrset(R2)－attrset(R1)，attrset(R1') = attrset(R1)；③对相交冲突：通常概括语义进行如下解决：generalize(R1，R2)其中 attrset(R3)=attrset(R1)∩attrset(R2)， attrset(R1')= attrset(R1)－attrset(R3)；attrset(R2')=attrset(R2)－attrset(R3)。 (3)关系关键字冲突：两个含义相同的关系具有不同的关键字约束。包括候选关键字冲突和主关键字冲突。解决候选关键字冲突的 方法 是，将两关系的候选关键字的交集作为两关系的候选关键字；解决主关键字冲突的方法是，从两关系的公共候选关键字中选一个分别作为两关系的主关键字。 (4)多对多的关系冲突：两个数据库中用不同数量的关系来表达现实世界的相同语义信息，就产生了多对多的关系冲突，这种冲突分3种：一对多，多对一和多对多。解决方法是在表示相同语义信息的数据库中关系之间建立映射来表示多对多的关系。 2)属性级冲突 (1)属性命名冲突：分属性名同义词冲突和属性名同形异义词。前者的解决方法是，换名或建立属性名同义词字典；后者的解决方法是，换名或建立属性名同形异义词字典。 (2)属性约束冲突：分属性类型冲突和属性长度冲突两种。当在两个相关的关系R1和R2的属性N1和N2具有不同的属性类型时，就发生属性类型冲突。解决方法是在全局模式中将发生属性类型冲突的属性统一到某种属性类型。对属性长度的解决方法是，在全局模式中将发生属性长度类型冲突的属性对统一定义为最大者就可。 (3)多对多的属性冲突：两个数据库中的关系分别用不同数量的属性来表达现实世界中相同的语义信息时，就发生了多对多的属性冲突，这种冲突分3种：一对多，多对一和多对多。解决方法是在表示相同语义信息的数据库中关系的属性之间建立映射来表示这种多对多的关系。 3)实例级冲突 (1)不兼容关系实例冲突：当含义相同的数据项在不同的数据库中存在不一致的数据值时就发生了不兼容关系实例冲突。其解决方法是：将关系实例的最近修改作为关系实例冲突部分的值，但不能保证数据的正确性。 (2)关系实例表示冲突：关系实例表示冲突是指用不兼容的符号、量纲和精度来表示相关关系实例中等价的数据元素，主要包括表达冲突、量纲冲突和精度冲突。表达冲突是指在两个相关的关系R1和R2中含义相同的属性N1和N2具有不同的数据表达时，这种冲突使用语义值的概念来解决，即将表示同一概念的多种表达在全局数据中进行统一即可。量纲冲突是指在两个相关的关系R1和R2和中含义相同的属性N1和N2具有不同的量纲表示。量纲冲突也可以语义值加以解决，解决过程如下：分别定义发生量纲冲突的局部数据源的语义值模式和语义值说明，然后再定义全局数据模式中相应的语义值模式和语义值说明，将发生量纲冲突的属性值在全局模式中进行统一。精度冲突是指在两个相关的关系 R1 和 R2 中含义相同的属性具有不同的精度。其解决方法是在全局模式中将发生精度冲突的数据项定义为最高精度即可。 4 总结 本文针对异构数据源管理自治和模式异构的特点，提出了数据源集成模式匹配的体系结构，制定了匹配策略， 研究 了基于语义的模式匹配过程。以关系模式为 参考 模式，对异构数据源关系模式间可能存在的语义冲突 问题 进行了分类，并阐述了解决这些语义冲突的策略。 参考 文献 [1] Bergamaschi S， Castano S， Vincini M Semantic Integration of Semistructured and Structured Data Sources [J] SIGMOD Record， 1999， 28(1)： 54- [2] Li W， Clifton C， Liu S Database Integration Using Neural Network： Implementation and Experiences [J] Knowledge and Information Systems， 2000， 2(1) [3] Reddy M P， Prasad B E， GReddy P A Methodology for Integration of Heterogeneous Databases [J] Information System， 1999，24(5) [4] Rahm E，Bernstein PA Survey of Approaches to Automatic Schema Matching[J] The International Journal on Very Large Data Bases (VLDB)，2001，10(4)：334- [5] 孟小峰，周龙骧，王珊数据库技术 发展 趋势[J]软件学报，2004，15(12)：1822-1835 [6] 邓志鸿，唐世渭，张铭，等Ontology研究综述[J]北京大学学报( 自然 科学 版)，2002，38(5)：730-738 [7] 郭志鑫基于本体的文档引文元数据信息抽取[J]微 计算 机信息，2006，22(6-3) 相关文献： 基于XML的多数据库系统集成数据模型 - 华中科技大学学报：自然科学版 - 卢晓蓉 陈传波 等 基于CORBA和XML的多数据库系统研究 - 郑州轻工业学院学报：自然科学版 - 张素智，钱慎一，卢正鼎， 集成数据库和文件系统的多数据库事务模型 - 华中理工大学学报 - 卢正鼎 肖卫军 基于主动规则对象的分布式多数据库系统集成 - 小型微型计算机系统 - 胡华，高济， 基于CORBA的多数据库系统 - 计算机科学 - 石祥滨 张斌 基于XML的文件系统与多数据库系统的集成 - 小型微型计算机系统 - 卢正鼎 李兵 等 基于CORBA／XML的多数据库系统的研究与实现 - 计算机研究与发展 - 卢正鼎 李兵 等 多数据库系统集成平台CMDatabase体系结构 - 计算机工程 - 魏振钢 郭山清 贾忠伟 多数据库系统的数据模式集成与查询处理 - 电脑开发与应用 - 陶世群 数据库网格：基于网格的多数据库系统 - 计算机工程与应用 - 任浩 李志刚 肖侬 高校学生收费系统基于多数据库系统集成的一种实践 - 昆明冶金高等专科学校学报 - 杨滨生，蒋涛勇，张中祥，谢静静， 基于RDBMS的地理信息集成数据库系统 - 计算机工程 - 江崇礼 王丽佳 等 基于CORBA的异构数据库系统集成模型的研究 - 现代计算机：下半月版 - 陈刚 基于分布式对象技术的多数据库系统 - 计算机工程与科学 - 韩伟红 隋品波 基于CORBA的多数据库系统互操作技术 - 计算机科学 - 肖明，肖毅，
最好是自己想，学习是自己的事！如果实在不行，可以参考别人的，也不要依样画葫芦!!
