WordPress右下角提醒,温州seo网站建设,ps里怎么做微网站模板,有没有做网站的个人总结#xff0c;仅供参考#xff0c;欢迎加好友一起讨论 文章目录 架构 - 层次式架构设计理论与实践考点摘要层次式体系结构概述表现层框架设计MVC模式MVP模式MVVM模式使用XML设计表现层表现层中UIP设计思想 中间层架构设计业务逻辑层工作流设计业务逻辑层设计 数据访问层… 个人总结仅供参考欢迎加好友一起讨论 文章目录 架构 - 层次式架构设计理论与实践考点摘要层次式体系结构概述表现层框架设计MVC模式MVP模式MVVM模式使用XML设计表现层表现层中UIP设计思想 中间层架构设计业务逻辑层工作流设计业务逻辑层设计 数据访问层设计5种数据访问模式工厂模式在数据访问层应用ORM、Hibernate与CMP2.0设计思想灵活运用XML Schema事务处理设计 数据架构规划与设计 架构 - 层次式架构设计理论与实践
考点摘要
层次式体系结构概述★
第二版架构新教材里新增加内容对应第13章新增的内容是有关层次架构的总结性知识偏理论多案例题中有内容涉及。
层次式体系结构概述
层次式体系结构设计是将系统组成一个层次结构每一层为上层服务并作为下层客户。 在一些层次系统中除了一些精心挑选的输出函数外内部的层接口只对相邻的层可见。连接件通过决定层间如何交互的协议来定义拓扑约束包括对相邻层间交互的约束。由于每一层最多只影响两层同时只要给相邻层提供相同的接口允许每层用不同的方法实现同样为软件重用提供了强大的支持。
分层架构的一个特性就是关注分离separation of concerns。 该层中的组件只负责本层的逻辑组件的划分很容易明确组件的角色和职责也比较容易开发、测试、管理和维护。
层次式体系结构是一个可靠的通用的架构对很多应用来说如果不确定哪种架构适合可以用它作为一个初始架构。但是设计时要注意以下两点 要注意的是污水池反模式。 污水池反模式architecture sinkhole anti-pattern就是请求流简单地穿过几个层每层里面基本没有做任何业务逻辑或者做了很少的业务逻辑。比如一些JavaEE例子业务逻辑层只是简单的调用了持久层的接口本身没有什么业务逻辑。 需要考虑的是分层架构可能会让你的应用变得庞大。 即使你的表现层和中间层可以独立发布但它的确会带来一些潜在的问题比如分布模式复杂、健壮性下降、可靠性和性能的不足以及代码规模的膨胀等。
表现层框架设计
MVC模式 MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离形成了控制器、模型、视图三个核心模块。
控制器Controller接受用户的输入并调用模型和视图去完成用户的需求。该部分是用户界面与Model的接口。一方面它解释来自于视图的输入将其解释成为系统能够理解的对象同时它也识别用户动作并将其解释为对模型特定方法的调用另一方面它处理来自于模型的事件和模型逻辑执行的结果调用适当的视图为用户提供反馈。模型Model应用程序的主体部分。模型表示业务数据和业务逻辑。一个模型能为多个视图提供数据。由于同一个模型可以被多个视图重用所以提高了应用的可重用性。视图View用户看到并与之交互的界面。视图向用户显示相关的数据并能接收用户输入的数据但是它并不进行任何实际的业务处理。视图可以向模型查询业务状态但不能改变模型。视图还能接受模型发出的数据更新事件从而对用户界面进行同步更新。
使用MVC模式来设计表现层可以有以下的优点
允许多种用户界面的扩展。在MVC模式中视图与模型没有必然的联系都是通过控制器发生关系这样如果要增加新类型的用户界面只需要改动相应的视图和控制器即可而模型则无须发生改动。易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展只要保持一种公共的接口控制器和视图的旧版本也可以继续使用。功能强大的用户界面。用户界面与模型方法调用组合起来使程序的使用更清晰可将友好的界面发布给用户。
MVP模式 MVPModel-View-Presenter模式提供数据 View负责显示 Controller/Presenter负责逻辑的处理。
MVP是从经典的模式MVC演变而来MVP与MVC 的区别MVC模式中元素之间“混乱”的交互主要体现在允许View和Model直接进行“交流”这在MVP模式中是不允的。在MVP中View并不直接使用Model它们之间的通信是通过PresenterMVC中的Controller来进行的所有的交互都发生在Presenter内部而在MVC中View会直接从Model中读取数据而不是通过Controller 。
使用MVP模式来设计表现层可以有以下的优点
模型与视图完全分离可以修改视图而不影响模型。可以更高效地使用模型因为所有的交互都发生在一个地方Presenter内部。可以将一个Presenter用于多个视图而不需要改变Presenter的逻辑。这个特性非常的有用因为视图的变化总是比模型的变化频繁。如果把逻辑放在Presenter中就可以脱离用户接口来测试这些逻辑单元测试。
MVVM模式 MVM模式全称是模型 - 视图 - 视图模型Model - View - ViewModel它和MVC、MVP不同的是View与Model的交互通过ViewModel来实现。ViewModel是MVVM的核心它通过DataBinding实现View与Model之间的双向绑定其内容包括数据状态处理、数据绑定及数据转换。例如View中某处的状态和Model中某部分数据绑定在一起这部分数据一旦变更将-会反映到View层。而这个机制通过ViewModel来实现。
ViewModel即视图模型是一个专门用于数据转换的控制器它可以把对象信息转换为视图信息将命令从视图携带到对象。
ViewModel通常要实现一个观察者当数据发生变化ViewModel能够监听到数据的变化然后通知对应的视图做自动更新而当用户操作视图ViewModel也能监听到视图的变化再通知数据做改动从而形成数据的双向绑定。这使得MVM更适用于数据驱动的场景尤其是数据操作特别频繁的场景。
使用XML设计表现层
XML可扩展标记语言与HTML类似是一种标记语言。与主要用于控制数据的显示和外观的HTML标记不同XML标记用于定义数据本身的结构和数据类型。XML已被公认为是优秀的数据描述语言并且成为了业内广泛采用的数据描述标准。
由于XML本身就是一种树形结构描述语言所以可以很好地支持控件之间的层次结构。GUI主要是由GUI控件组成。控件可以看成是一个数据对象其包含位置信息、类型和绑定的事件等。这些信息在XML 中都可以作为数据结点保存下来每一个控件都可以被描述成一个 XML结点而控件的那些相关属性都可以描述成这个XML结点的Attribute。
表现层中UIP设计思想
表现层开发的痛点
导航和工作流控制这些将不会出现的Ul中但是经常因为要基于业务逻辑决定哪一个视图将被显示。这导致代码的不雅和难于管理。导航和工作流改变用传统的UI技术改变应用程序的界面改变页面的顺序或者添加删除页面是非常痛苦的。状态管理不管是在windows form还是在web form中在视图间维护状态都是比较困难的。保存当前交互的快照你可能想保存一个交互的快照并且在别的地方不同的时间不同的地点重新开始它。
UIPUserInterface Process Application Block是微软社区开发的众多Application Block中的其中之一它是开源的。 UIP 提供了一个扩展的框架用于简化用户界面与商业逻辑代码的分离的方法可以用它来写复杂的用户界面导航和工作流处理并且它能够复用在不同的场景、并可以随着应用的增加而进行扩展。 UIP框架的应用程序把表现层分为了以下几层
User Interface Components这个组件就是原来的表现层用户看到的和进行交互都是这个组件它负责获取用户的数据并且返回结果。User Interface Process Components这个组件用于协调用户界面的各部分使其配合后台的活动例如导航和工作流控制以及状态和视图的管理。用户看不到这一组件但是这些组件为User Interface Components提供了重要的支持功能。
中间层架构设计
业务逻辑组件分为接口和实现类两个部分。
接口用于定义业务逻辑组件定义业务逻辑组件必须实现的方法是整个系统运行的核心通常按模块来设计业务逻辑组件每个模块设计一个业务逻辑组件并且每个业务逻辑组件以多个DAOData Access Object组件作为基础从而实现对外提供系统的业务逻辑服务。增加业务逻辑组件的接口是为了提供更好的解耦控制器无须与具体的业务逻辑组件耦合而是面向接口编程。实现类业务逻辑组件以DAO组件为基础必须接收Spring容器注入的DAO组件因此必须为业务逻辑组件的实现类提供对应的Setter方法。业务逻辑组件的实现类将DAO组件接口实例作为属性面向接口编程而对于复杂的业务逻辑可能需要访问多个对象的数据那么只需在这个方法里调用多个DAO接口将具体实现委派给DAO完成。
业务逻辑层工作流设计
工作流管理联盟Workflow Management Coalition将工作流定义为业务流程的全部或部分自动化在此过程中文档、信息或任务按照一定的过程规则流转实现组织成员间的协调工作以达到业务的整体目标。 过程定义导入/导出接口。这个接口的特点是转换格式和API调用从而支持过程定义信息间的互相转换。这个接口也支持已完成的过程定义或过程定义的一部分之间的互相转换。早期标准是WPDL后来发展为XPDL。客户端应用程序接口。通过这个接口工作流机可以与任务表处理器交互代表用户资源来组织任务。然后由任务表处理器负责从任务表中选择、推进任务项。由任务表处理器或者终端用户来控制应用工具的活动。应用程序调用接口。允许工作流机直接激活一个应用工具来执行一个活动。典型的是调用以后台服务为主的应用程序没有用户接口。当执行活动要用到的工具需要与终端用户交互通常是使用客户端应用程序接口来调用那个工具这样可以为用户安排任务时间表提供更多的灵活性。工作流机协作接口。其目标是定义相关标准以使不同开发商的工作流系统产品相互间能够进行无缝的任务项传递。 WFMC定义了4个协同工作模型包含多种协同工作能力级别。管理和监视接口。提供的功能包括用户管理、角色管理、审查管理、资源控制、过程管理和过程状态处理器等。
用工作流的思想组织业务逻辑优点是将应用逻辑与过程逻辑分离在不修改具体功能的情况下通过修改过程模型改变系统功能完成对生产经营部分过程或全过程的集成管理可有效地把人、信息和应用工具合理地组织在一起发挥系统的最大效能。
业务逻辑层设计 业务框架位于系统架构的中间层是实现系统功能的核心组件。采用容器的形式便于系统功能的开发、代码重用和管理。大大降低业务层和相邻各层的耦合。表示层代码只需要将业务参数传递给业务容器而不需要业务层多余的干预。有效地防止业务层代码渗透到表示层。
Domain Model是领域层业务对象它仅仅包含业务相关的属性。Service是业务过程实现的组成部分是应用程序的不同功能单元通过在这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义没有强制绑定到特定的实现上的特征称为服务之间的松耦合。松耦合系统的好处有两点一是它的灵活性二是当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时它能够继续存在。Control服务控制器是服务之间的纽带不同服务之间的切换就是通过它来实现的。通过服务控制器控制服务切换可以将服务的实现和服务的转向控制分离提高了服务实现的灵活性和重用性。
数据访问层设计
5种数据访问模式
在线访问
在线访问是最基本的数据访问模式在实际开发过程中最常采用的。
这种数据访问模式会占用一个数据库连接读取数据每个数据库操作都会通过这个连接不断地与后台的数据源进行交互。
Data Access Object
DAO模式是标准J2EE设计模式之一开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。
一个典型的DAO实现通常有以下组件
一个DAO 工厂类一个DAO接口一个实现了DAO接口的具体类数据传输对象这当中具体的DAO类包含访问特定数据源的数据的逻辑。
Data Transfer Object
Data Transfer Object是经典EJB设计模式之一。 DTO本身是这样一组对象或是数据的容器它需要跨不同的进程或是网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法而且这些方法最好不要再调用其他的对象行为。
在具体设计这类对象DTO时通常可以有如下两种选择
使用编程语言内置的集合对象。通过创建自定义类来实现DTO对象。
离线数据模式
离线数据模式是以数据为中心数据从数据源获取之后将按照某种预定义的结构这种结构可以是SDO中的Data图表结构也同样可以是 ADO.NET 中的关系结构存放在系统中成为应用的中心。离线对数据的各种操作独立于各种与后台数据源之间的连接或是事务与XML集成数据可以方便地与XML格式的文档之间互相转换独立于数据源离线数据模式的不同实现定义了数据的各异的存放结构和规则这些都是独立于具体的某种数据源的。
对象/关系映射Object/Relation MappingO/R Mapping
大多数应用中的数据都是依据关系模型存储在关系型数据库中而很多应用程序中的数据在开发或是运行时则是以对象的形式组织起来的。
工厂模式在数据访问层应用
在编写应用系统的时候尽量做到数据库无关。这就需要在实际开发过程中将数据库访问类作一次封装。经过这样的封装不仅可以达到良好的封装性和可维护性还可以减少操作数据库的步骤减少代码编写量。工厂设计模式是使用的主要方法。
工厂模式定义一个用于创建对象的接口让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。这里可能会处理对多种数据库的操作因此需要首先定义一个操纵数据库的接口然后根据数据库的不同由类工厂决定实例化哪个类。
ORM、Hibernate与CMP2.0设计思想
ORMObject-Relation Mapping在关系型数据库和对象之间作一个映射这样在具体操纵数据库时就不需要再去和复杂的SQL语句打交道只要像平时操作对象一样操作即可。
提到Hibernate必须要说到Mybatis相关内容自行搜索开发人员必备。
灵活运用XML Schema
XML Schema用来描述XML文档合法结构、内容和限制。XML Schema由XML1.0自描述并且使用了命名空间有丰富的内嵌数据类型及其强大的数据结构定义功能充分地改造了并且极大地扩展了DTDs传统描述XML文档结构和内容限制的机制的能力将逐步替代DTDs成为XML体系中正式的类型语言同XML规范、Namespace规范一起成为XML体系的坚实基础。
事务处理设计
事务必须服从ISO/IEC所制定的ACID原则。 ACID是原子性Atomicity、 一致性Consistency、 隔离性Isolation和持久性Durability的缩写。
原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。一致性表示当事务执行失败时所有被该事务影响的数据都应该恢复到事务执行前的状态。隔离性表示在事务执行过程中对数据的修改在事务提交之前对其他事务不可见。持久性表示已提交的数据在事务执行失败时数据的状态都应该正确。
数据架构规划与设计
Web上存有大量的XML文档并需要持久保存这一需求引发了人们对XML文档的存储技术研究。已经提 出的XML文档的存储方式有两种基于文件的存储方式和数据库存储方式。
基于文件的存储方式。基于文件的存储方式是指将XML文档按其原始文本形式存储主要存储技术包括操作系统文件库、通用文档管理系统和传统数据库的列作为二进制大对象BLOB或字符大对象CLOB。这种存储方式需维护某种类型的附加索引以建立文件之间的层次结构。基于文件的存储方式的特点无法获取XML文档中的结构化数据通过附加索引可以定位具有某些关键字的 XML 文档一旦关键字不确定将很难定位查询时只能以原始文档的形式返回即不能获取文档内部信息文件管理存在容量大、管理难的缺点。数据库存储方式。数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。一种比较自然的想法是采用数据库对XML文档进行存取和操作这样可以利用相对成熟的数据库技术处理XML文档内部的数据。数据库存储方式的特点能够管理结构化和半结构化数据具有管理和控制整个文档集合本身的能力可以对文档内部的数据进行操作具有数据库技术的特性如多用户、并发控制和致性约束等管理方便易于操作。
