《软件框架设计》word版

《《软件框架设计》word版》由会员分享，可在线阅读，更多相关《《软件框架设计》word版（49页珍藏版）》请在装配图网上搜索。

1、软件框架设计一、优秀的框架的特征1.重用(1)为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。重用是框架实现中最为核心的目标，重心中的重心。提高复用度是框架的首要目标。(2)层次分明，高度组件化，在框架中的各个部件高度独立，可拆可组(任意拆卸，任意组合)，着力通用。(3)部件细化，设计精巧，运行高效，内存占用低。(4)耦合度低(可拆可组)2.高效不论是什么系统，我们都希望架构是高效的。3.安全运行安全稳定【可以通过完善TDD测试机制来保障】4.可拓展我们需要架构具有可拓展性，以适应未来可能的变化。5.简明一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满足

2、目的的情况下尽可能的简单明了。【但是简单明了的含义究竟是什么好像并没有一个明确的定义。例如：使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设计模式的人，他会认为这个架构很复杂。】6.透明把过多的实现细节隐藏起来，仅把需求的接口呈现出来(具体的实现对使用框架的开发者来说就是透明的)。这样就提高了使用者的效率，降低了学习的门槛。二、设计具体指导原则1、概要框架总体功能目的2、对框架总体功能目的进行细化，分层(层次之间相对独立，互不干涉)，仔细斟酌，理清层次之间的依赖关系(如，核心层，中间层，应用层)。*核心层：处于最低层，不依赖于框架中的其它层；数据访问层指导概览这

3、一章主要描述设计数据访问层时要注意的主要原则。它们覆盖了设计数据访问层遇到的通常问题及错误。下面的图表展示了数据层怎样嵌入一个通用的应用架构。(cnblog我的图片一直上传不了，报Remote server Error,只能使用网络图片了)数据访问层组件l数据访问层组件。数据访问层组件将访问底层存储介质的必要方法抽象出来。将数据访问功能集中起来，可以使应用程式便于配置和维护。l Data Helpers/Utilities。Helper和Utilities功能帮助操纵，转变和获取数据。他们由一些特别的类库组成以增强数据访问性能以及减少逻辑组件和服务代理的开发要求。l服务代理。当业务组件必须将功

4、能通过外部服务暴露时，你可能需要创建程式管理通信服务所需要的协议。服务代理将你的程式从调用不同的服务中分离出来，并且提供额外的服务，如服务的数据格式和你的应用程式需要的格式之间的映射。方法正确的设计数据层可以减少程式部署后的开发和维护工作。这章会简要的概述一个设计访问层有效的方法。当设计数据层时使用下面的方式：1.创建一个总体的设计。A.确定数据源要求。B.确定数据访问方式。C.选择怎样映射数据结构到数据源。D.确认处理数据源错误时的策略。E.确认怎样连接数据源。2.设计你的数据访问层组件。A.列举你要访问的数据源。B.决定每一个数据源的访问方式。C.确认是否需要Hlper组件以简化数据访问组

5、件开发和维护。D.确认相关的设计模式。例如，考虑使用表格数据，查询对象，Repository，以及其它模式。3.设计你的数据访问层Helper组件。A.识别可以从数据访问组件中拿出来通用的功能以重用。B.研究可用的Helper组件。C.考虑为连接字符串，数据源认证，监视以及异常处理设计自定义的Helper组件。D.考虑实现数据访问监视和测试你的Helper组件。E.考虑实现你的Helper组件安装和日志。4.设计服务代理。A.使用合适的工具以添加引用。生成一个代理和数据类来代表服务中的数据契约。B.确认服务怎样使用。对于大多应用程式来说，最好在业务层和数据访问层之间使用一个抽象层，这样会提供一

6、个一致的接口而不考虑数据源。对于小的应用程式来说，业务层或者表示层，可以直接访问服务代理。设计原则下面的设计原则包括了设计数据层时应该考虑的不同方面。章节的剩余部分会提供给你选择合适的技术和设计模式的详细信息。l选择数据访问技术。合适的数据访问技术选择依赖于你处理的数据类型，以及你怎样操纵程式数据。特定的技术会适用特别的场景。下面的部分讨论了所选择的数据访问技术的好处以及缺点。l使用抽象以实现和数据访问层松耦合的接口。这个可以通过定义接口组件来完成，如众所周知的输入和输出Facade,可以将请求翻译为层组件可以理解的信息。另外，你可以定义接口或抽象基类，以被组件实现。l考虑稳固的数据结构。如果

7、你要在数据访问层处理基于Table的实体，考虑使用DTO来帮助你把数据转换为统一的结构，DTO鼓励使用粗粒度的操作，以使数据在不同的边界层移动。l用数据访问层封装数据访问功能。数据访问层隐藏了访问数据源的详细信息，它用来管理连接，生成查询，以及映射程式实体到数据源结构。数据访问层的调用者使用自定义对象，Dataset,DataReader,以及XML文档等抽象结构来交互。其它应用程序层使用操作更复杂的方式来操纵数据以满足应用程式功能。分开的考虑可以帮助应用程式开发和维护。l决定怎样映射应用程序实体到数据源结构。应用程序使用的实体类型是最主要的决定因素。l决定你怎样来管理连接。实际上讲，数据访问

8、层需要管理应用程序所有的数据源连接。你必须选择合适的方法去存储和保护连接信息以满足应用程序的安全需要。l决定你怎样处理数据异常。数据访问层应该捕获以及处理所有和数据源、CRUD操作引起的异常。如果只是数据异常，数据源访问及超时异常，数据访问层应该处理。如果错误影响应用程式的功能或响应的话，那异常应该被传递到其它层。l考虑安全风险。数据访问层应该防止数据偷窃和破坏，保护访问数据源的机制。应该使用最少权限的设计方法以限制需要执行的应用程式操作。如果数据源自己有能力限制权限的话，那数据访问层和数据源都要考虑安全。l减少数据包往返。考虑使用批处理命令以使用一个数据库操作。l考虑性能和客观上可测量性。可

9、测量以及性能在设计数据访问层时就应该被考虑。例如，当设计一个基于网络的商业程式，数据层性能是程式的瓶颈。当数据访问层性能是决定性时，要限制昂贵的数据操作。数据访问层设计Category Common Issues BLOB不适当的在数据库中存储BLOBS以替代文件系统。对数据库中的BLOB数据使用了不正确的类型。搜索以及操作BLOB数据。Batching没有使用批处理以减少数据包往返。Holding onto locks for excessive periods when batching.没有考虑使用批处理策略以减少数据库数据包往返。Connections对连接池使用了不适当的配置。没有处

10、理连接超时和连接断掉。执行的事务跨越过个连接。在过长的时间内保持连接打开。使用单独的认证以代替全信任的子系统去访问数据库。Data Format选择了错误的数据格式。没有考虑串行化需求。没有映射对象到关系数据存储。Excepion Management没有处理数据访问异常。没有对调用者掩盖数据库异常。没有记录致命性的异常。Queries使用字符串连接来组建查询语句。查询混合了业务逻辑。对于查询语句没有优化。Stored Procedures没有正确的将参数传给存储过程。在存储过程里实现业务逻辑。没有考虑存储过程里的动态SQL可以导致性能，安全以及可维护性。Transactions使用不正确的隔

11、离等级。在多个数据源间使用了事务。使用了个别锁，可能导致死锁。允许长时间运行的事务导致锁住了数据访问。Validation对于数据字段没有使用数据类型验证。没有处理NULL值。没有过滤不正确的字符。XML没有考虑怎样处理非常大的XML DataSet.没有选择合适的技术以方便XML和关系数据库交互。没有设置合适的索引导致沉重的XML查询负担。没有使用Schema来验证所有的XML输入。BLOB BLOB是二进制的大型对象。如果数据以数据流的方式存储或检索，那它就是BLOB。BLOBs也许有结构，但显然不是数据库存储的结构或者数据访问层读写的结构。BLOB数据如果不能直接存储在数据库，则通常存储

12、在文件系统中。BLOBs典型的使用方式是存储图像数据，但也经常用于存储以二进制为代表的对象。当设计BLOBs策略时，考虑以下原则：l当存储图像到硬盘不实际的时候，才会存储到数据库中。l在服务器间使用BLOBs来简化大型的二进制对象同步。l考虑你是否需要搜索BLOB数据。如果需要的话，创建其它数据库可搜索的字段来代替解析BLOB数据。l考虑为BLOB数据使用文件系统以提高性能。数据库的结构和实现决定着系统性能提升的高度。使用文件系统你还要考虑存储和同步数据库中的相关元数据。l当检索BLOB,把它转换成业务层或表现层需要操作的合适类型。l当使用缓冲传输的时候不要把BLOB数据存储到数据库中。批处理

13、数据库批处理命令可以提高数据访问层的性能。在进入数据库执行环境前要消耗比较多的资源。批处理可以减少前端花费以及提高吞吐量和减少响应时间。对相似的查询使用批处理比较好，因为数据库对相似的查询会使用缓存以减少查询执行计划。当设计批处理时，考虑以下原则：l使用批处理以减少数据库数据包往返以及减少网络流量。l为大量的相似查询建立批处理可以获得最大的效益。为不相似的或随即的查询建立批处理是无用的。l使用批处理和命令以及DataReader以加载或拷贝多个数据集。l当加载大量的基于文件的数据到数据库时，使用BULK Copy工具。不要为长时间运行的批处理命令设置锁。连接连接到数据源是数据访问层的基础。数据

14、层必须管理所有的数据源连接。在数据层和数据源之间建立及管理连接都需要昂贵的资源。为了最大的提高性能，遵循下面的创建，管理和关闭连接原则。l选择一个策略以处理数据库连接字符串。l使用默认的连接池以减少活动的连接数量。l确定连接没有特别的不需要的字符。在效率不高的连接池里，多余的字符会使一些同样功能的连接获取到不同的值。l在每一个事务后不要打开或关闭连接，考虑在一定的时间里保持连接以允许重用。在部署前，要模拟真实的负载情况来测试你的应用程式，对需要大量时间处理的地方做出改变以优化性能。l不要以来垃圾回收器来释放连接。在明确的地方尽快释放它们。l在可能的地方使用单一的连接来执行事务。l设计Retry

15、的机制以应付数据源丢失或连接超时的情况。l由于安全原因，避免使用系统名或用户数据源名(DSN)。l考虑在配置文件里对连接信息加密。例如，使用.net内置的机制加密连接字符串。数据格式正确的数据格式用来合理的解释数据库的原始字节以形成数据层传递的信息。选择适当的数据格式可以提高程式间的互操作性，简化不同进程和机器间的串行化通信。数据格式和串行对于业务层存储和检索非常重要。当设计数据格式时，考虑以下原则：l为程式选择合适的数据格式。l在很多情况下，你需要使用自定义的数据或业务实体来提高程式可维护性。这需要额外的代码来映射实体到数据库操作。O/RM解决方案可以减少大量的自写代码。l数据访问层使用的数

16、据结构不能包含业务规则。l当使用经常改变的结构化数据时可以使用XML。l决定数据的串行化需求。l考虑互操作性需求。异常管理在数据库中设计统一的异常管理策略。如果可能，在数据库Helper组件中使用统一的异常处理逻辑。要特别注意在信任的层边界发生的异常。设计不能处理的异常策略以使敏感的应用程式信息不会暴露。当设计异常管理策略时，考虑以下原则：l决定哪些异常可以呈现给调用者。死锁，连接问题和网络检测可以在数据层解决。l实现全局的异常处理以捕获不可知的异常以及将它抛给原调用者。l当通过服务接口来暴露数据层时，使用异常屏蔽信息以避免暴露敏感数据。l在数据层中处理所有数据访问相关的异常。l考虑对数据源错

17、误和操作超时实现Retry机制。l告诉User异常会影响程式体验。考虑将异常信息传到业务层处理以及将它报告给User。l Log异常以容易的查找特定的错误。l如果有多个数据源，记录异常和错误的时候要包括单个数据源信息。查询查询是数据层主要的数据操作方式。它们将程式请求转换为Create,Retrieve,Update和Delete(CRUD)数据库操作。由于查询是很基本的东西，所以应该优化查询以最大的提高数据库性能和吞吐量。当设计数据层查询，考虑以下的原则：l当存储过程不实用的时候使用SQL查询语句。l在SQL语句中使用参数以减少SQL注入。l当需要动态的创建查询，不要允许用户输入来决定查询的

18、详细信息。l在数据层中不要使用字符串拼凑来创建动态查询。l使用对象来创建查询。例如，实现Query Object模式或使用ADO.NET对象。存储过程存储过程可以优化查询性能以及提高安全。它比SQL语句提供了更高的性能因为数据库可以针对它做出执行优化，并且可以根据存储过程里的语句来优化数据库。存储过程也提供了额外的安全，因为调用者可以从它获取数据而不用去数据库表或者视图里获取。存储过程同样可以参数化以支持多个应用程式的复杂查询。当设计存储过程，考虑以下原则：l使用存储过程来提高数据库效率和数据层安全。l使用Output参数来返回单个的值。l避免动态SQL。当数据访问是程式的瓶颈时尽可能的使用存

19、储过程。l对于单个的数据输入考虑使用单个的参数。l对于列表形式的数据考虑使用XML参数。l使用适当的事务来保持数据一致性。l设计合适的异常处理返回错误以被应用程式处理。l在存储过程里避免实现业务逻辑。l当处理数据时避免创建临时表。而且，在内存中创建、使用临时表比在磁盘中好。事务事务是将一系列的数据库操作作为一个原子单元联系起来以满足请求和保证数据库一致性。当所有动作的信息完成以及数据库的数据永久性更改代表了事务结束。事务可以在发生的错误的时候回滚数据库以保证数据库的ACID属性。当设计事务时，考虑以下原则：l在需要的时候使用事务。例如，对于一个单独的SQL语句不需要使用事务，因为SQLSERV

20、ER可以自动将每一个SQL操作作为一个事务来执行。l保持事务尽可能的短以减少锁住的时间。l使用合适的隔离等级。数据一致性的平衡是很有争议的。高隔离级可以在并发的时候提供高的数据一致性。低隔离级可以通过降低一致性的花费而提高性能。l如果针对一个数据库执行事务，可以使用人工控制的事务。l如果一个单独的事务跨越了多个数据库，那你应该使用自动的事务。l避免混合人工控制和自动的事务。l如果使用人工控制的事务，考虑在存储过程里实现事务。l考虑在事务里使用MARS来加强并发以避免潜在的死锁问题。l如果执行多条Insert,Update和Delete，将他们在一个事务里处理以获取更好的性能。验证设计一个有效的

21、输入和数据验证策略对你的程式安全至关重要。决定从其它层，第三方组件，数据库或数据存储获取的数据验证规则。你可以验证任何在你信任的边界中通过的数据。l验证数据层中调用者发出的所有数据。l验证所有从数据库中检索的数据。l你可以验证任何在你信任的边界中通过的数据。l决定其它层的验证方式。如果数据已经是可信的数据，那没必要重复验证。l当设计验证时考虑数据输入的目的。l在执行数据库Update前验证所有的数据。l当验证失败的时候返回警告信息。XML XML在数据库外是维护数据结构的很有用的方式。由于性能原因，在大量数据集时小心使用XML。使用Schema去验证XML结构和内容。当设计XML使用时，考虑以

22、下原则：l使用XML读写器去访问XML格式的数据。l使用XML Schema来定义数据存储格式和传递。l用适当的Schema来验证接收到的XML。l在XML Schema里为复杂的数据参数使用自定义的验证。l用特定类型的列来存储XML，如果可能的话，使用数据库来获取最大的性能。l对于读Sqlserver里XML数据比较频繁的程式，考虑使用XML索引。管理注意点当设计管理策略时，考虑以下原则：l仔细考虑你是否需要创建自定义的实体或者其它数据表示可以更好的满足需求。开发自定义的实体会加重开发负担。通常，自定义实体是为了方便开发者定制。l从一个基类派生业务实体可以提供基本的功能和封装通用的Task。

23、l依靠为复杂数据使用内置的DataSet或XML Document来代替内部的集合，结构和其它编程结构。l实现一个通用的集合接口以从你的业务实体暴露通用的功能集合。l设计业务实体依赖于用于数据库交互的数据访问组件。统一实现数据访问策略和相关的业务逻辑。例如，如果你的业务实体直接访问SQLSERVER，那所有部署的程式客户端使用的业务实体都需要SQL连接和验证策略。l使用存储过程来从潜在的数据Shema中抽象数据访问。小心不要过度使用存储过程因为它会降低代码维护和重用，包括存储过程维护。过度使用的症状就是大量的存储过程互相调用。避免使用它们来实现控制流，操纵单个的值以及一些在T-SQL中难以实现

24、的功能。性能考量数据层设计及数据库设计都要考虑性能。在调节系统吞吐量的时候考虑以上两点。当设计性能策略时，考虑以下原则：l考虑改变数据查询隔离级别。如果你在创建一个高吞吐量的程式，特殊的数据操作业务可能会在较低的隔离级执行。混合的隔离级别会影响系统数据的一致性，因此你要通过一个个实际例子小心的分析它。l考虑批处理命令以减少数据库的数据包往返。l使用连接池以及根据模拟实际场景来调节性能。l对非变化的数据使用并发来减轻数据库锁数据的花费。这可以避免锁住数据库行，以及因为锁一直打开的数据库连接。l如果更新数据只需要很少的时间，而且数据容易被更改，那尽量避免使用并发。长时间的锁越多，设计的可能性就越少

25、。l使用DataReader来执行顺序的查找有助于提高性能。安全考量数据层必须保护数据库免受偷窃或者破坏。同时也必须保护数据源可受访问。当设计安全策略时，考虑以下原则：l当使用SqlServer时，考虑使用Windows验证而不是SQL验证。l考虑到性能问题，避免中间层来扮演此角色。l验证所有穿越可信任边界的数据。l如果使用SQL语句，考虑使用参数方法来代替字符串拼凑以防止SQL注入。l在配置文件里加密连接字符串以代替使用系统或DSN。l加密敏感数据或使用数据库加密来存储密码，使用Hash代替加密密码版本。l在网络或Internet传递时，加密敏感数据。l考虑在访问数据源中实现最少权限。l在数

26、据层中要求调用者使用身份认证来审核。l记录登陆和身份认证信息。部署考量当部署数据访问层，软件架构师要考量生产环境中的性能和安全问题。当部署数据访问层时，考虑以下原则：l把数据层和业务层放到同一个位置以提高程式性能。l如果你要支持一个远程的数据访问层，考虑使用TCP协议来提高性能。l你不能把数据访问层和数据库服务器放到一起。模式映射Category Patterns General Active Record Application Service Domain Model Layered Architecture Transaction Script Table Data Gateway Re

27、pository Exception Management Exception Shielding Transactions Master-Master Replication Coarse Grained Lock Capture Transaction Details Implicit Lock Optimistic Offline Lock Pessimistic Offline Lock Transaction Script重要模式l Active Record。将数据访问层放置域对象中。l Capture Transactions Details。创建数据库对象，如触发器和记录表，来

28、记录变化。l Repository。封装数据库和持久化操作中的对象集。l Data Transfer Object。使用数据对象来减少调用方法的次数。l Table Data Gateway。让sql统一访问一个表或视图来完成Select,Insert,Update和Delete操作。技术考量当选择合适的数据层技术时，考虑以下原则：l使用客户端的数据库访问以提高性能。l考虑使用企业库模块来简化数据访问代码。l使用System.Xml和其子命名空间来操作XML格式的数据。l使用DataReader来呈现数据对基于的用户接口比较有益，DataReader是一个只读的，向前的读写器，读取每一行的速度

29、很快。Additional Resources For more information on data access performance,see the following resources：Architecture and Design Review of a.NET Application for Performance and Scalability at Guidelines for Application Performance at ADO.NET Performance at SQL Server Performance at Scenarios-Optimistic C

30、oncurrency at more information on data access design patterns,see the following resources：Data Patterns at Solution Patterns Using Microsoft.NET at more information on general data access guidelines,see the following resources：.NET Data Access Architecture Guide at storage,reading,and writing BLOBs

31、at stored procedures instead of SQL statements at ADO.NET scenarios For more information on security,see the following resources：Architecture and Design Review for Security at Guidelines for Secure Web Applications at中间层：根据具体框架的需要自行定义，取名，注意理清层次之间的依赖关系；业务层原则概览这章描述业务层的设计过程，包含了设计业务层和业务组件是重要的原则。这些原则被分成不

32、同的种类，包括设计业务层和实现合适的功能，如Security,Caching,Exception Management,Logging,Validation.这些代表了商业层设计时容易发生错误的主要区域。业务层组件下面的列表解释了业务层包含的主要组件角色和任务：l应用程式Facade.(可选).应用程序门面合并了多种业务操作到一个基于消息的操作。你可以从表示层使用不同的通信技术来访问应用程式门面。l业务组件。当用户进程收集了需要的数据后，就是使用业务规则来处理。规则会描述数据怎么被操作以及转变。规则也许简单或者复杂，由它本身业务决定。当业务需求演变后，规则跟着被更新。l业务实体组件。业务实体被

33、用来在组件中传送数据。数据代表了真实世界的业务实体，如产品或者订单。应用程序内使用的业务实体结构有DataSet,可标记语言(XML)流。同样，他们也可以用自定义的面向对象的类来代表真实世界的实体，如产品或者订单类。l业务工作流。许多业务流程包含了多个步骤，必须在正确的命令下才能执行。业务工作流定义和协调了长时间运行，多步的业务流程，可以使用流程管理工作来实现。方法当设计业务层时，你必须考虑业务层的构成，如业务组件，业务实体和业务工作流组件。这节简要的介绍了设计业务层各组件的方式。业务层。当设计业务层，你需要考虑以下几点：l确认业务层调用者。l确定怎么暴露业务层接口。l确定业务层的安全要求。l

34、确定业务层的验证要求和策略。l确定业务层的缓存策略。l确定业务层的异常管理策略。业务组件。当设计业务组件时，你需要考虑以下几点：l确认应用程序要是使用的业务组件。l对业务层的位置，耦合以及交互作出主要决定。l选择合适的事务支持。l确认你的业务规则处理方式。l确认适合需求的模式。业务实体。当设计业务实体时，你需要考虑以下几点：l确认业务实体的统一数据格式。l选择数据格式。l可以选择性的设计自己的自定义对象。l可选择确定你需要的串行化支持。业务工作流。当设计业务工作流时，你需要考虑以下几点：l确认工作流适用的场景。l选择一个授权模式。l确定规则的处理方式。l选择一个工作流解决方案。l设计业务组件以

35、支持工作流。设计注意事项当设计业务层时，软件架构的目标是通过分离任务到不同的关注区域以减少复杂性。例如，业务处理，业务工作流，以及业务实体都代表了不同的关注区域。对于每一个区域，你设计的组件需要专注于特定的区域以及不能有代码关联到其它区域。当设计业务层时，需要遵循以下原则：l决定你是否需要一个单独的业务层。尽可能的使用一个单独的业务层可以提高应用程式的可维护性。l确定业务层的责任。用业务层来处理复杂的业务规则，传送数据，应用策略，以及验证。l在业务层不要混合不同类型的组件。用业务层使业务逻辑和表现层及数据访问层解耦，并且简化业务逻辑测试。l重用通用的业务逻辑。使用业务层以集中通用的业务逻辑功能

36、和提高重用。l确认业务层的调用者。这可以帮助你确认业务层的暴露方式。例如，如果你的表现层和一个外部程式需要使用业务层，你可能要选择暴露你的业务层通过WebService。l当访问一个远程业务层时要减少数据往返。如果你使用基于消息的接口，考虑使用粗粒度的数据包，比如DTO。另外，考虑为业务层实现一个远程的FACADE。l避免层之间的紧耦合。当创建业务层接口时使用抽象。可以使用公共对象接口，通用接口定义，抽象类，或消息来实现抽象。对于WEB程式，考虑在表示层和业务层之间使用消息接口。业务层框架Category Common Issues Authentication在需要的地方使用验证。设计自定义

37、的验证机制。在合适的时候使用单点登录。Authorization使用了不正确的角色粒度。在不需要的时候使用了匿名和代理。授权代码和业务处理代码混合。Business Components使用了不相关的功能重载了业务组件。在业务组件里混合了数据访问逻辑和业务逻辑。没有考虑使用基于消息的接口以暴露业务组件。Business Entities在不合适的地方使用了域模型。为你的业务实体选择了不正确的数据格式。没有考虑串行化支持。Caching缓存了易变的数据。在业务层缓存了过多的数据。没有在ready-to-use的时候缓存数据。在没有加密的窗体缓存了敏感数据。Coupling and Cohesio

38、n(耦合和衔接)层之间紧耦合。没有明确分离业务层关注点。在层之间没有使用基于消息的接口。Concurrency and Transactions(并发和事务)没有提供对可写的静态数据的并发访问。没有选择正确的数据并发模型。使用了长时间运行的事务锁住了数据。Data Access从业务层直接访问了数据库。在业务组件里混合了数据访问逻辑和业务逻辑。Exception Management对于终端用户显示了敏感信息。要为应用逻辑使用异常。没有记录重要异常的详细信息。Logging and Instrumentation对业务组件没有使用适当的监控。没有Log致命的系统和业务事件。没有处理记录失败的情

39、况。Service Interface破坏了服务接口。在业务接口实现了业务规则。没有考虑互操作需要。Validation依赖于表现层的验证。没有验证参数的各个方面，比如范围，类型以及格式。没有重用验证逻辑。Workflows没有考虑程式管理的需要。选择了不正确的工作流模式。没有考虑处理所有的异常状态。选择了不正确的工作流技术。验证设计一个业务层有效的验证策略对系统的安全性和可靠性很重要。没有设计一个好的验证策略会使你的应用程式易受欺骗攻击，字典攻击，会话劫持和其它类型的攻击。当设计验证策略时，考虑以下原则：l如果业务层和表现层互相信任，并且位于同一个层里，那么在业务层不要使用验证。l如果业务层

40、部署在单独的层里或者被其它应用程式共享，请使用用户验证。l如果你的业务层被多个程式调用并且位于一个信任的环境里，请实现单点登录机制。l决定你的业务层是否需要遵循调用者的标识。l使用信任的子系统去访问后台服务以加大数据连接池的应用。l避免设计自定义的验证机制。l如果使用WebService,考虑使用IP过滤以显示来自表示层的调用。授权设计一个业务层有效的授权策略对系统的安全性和可靠性很重要。没有设计一个好的授权策略会使你的应用程式易受信息披露，数据篡改，以及权限提升。当设计授权策略时，请遵循以下原则：l访问不同层级的粒度时请使用角色控制。l对使用自己的身份，账户组或角色的调用者使用授权以保护资源

41、。l对于业务决策使用基于角色的授权。l对于系统审核使用基于资源的授权。l当使用混合了身份，角色，许可，权力以及其它因素的联合授权时，考虑使用基于债权(claims-based)授权。l避免使用匿名和代理，因为它会显著的影响性能和伸缩性。通常一个匿名客户端的调用比直接调用代价高的多。l避免在业务处理代码中混合授权代码。业务组件业务组件用不同的模式实现业务规则，接收以及返回单个或复杂的数据结构。你的业务组件应该暴露需要执行的服务，而对数据存储不可知。编写业务组件注意要有意义以及保持事务的一致性。设计业务组件是一个重要的工作。如果业务组件设计的不合理，那代码则很难维护。当设计业务组件时，遵循以下原则

42、：l避免加载不相关的组件或混合功能。想l避免混合数据访问逻辑和业务逻辑。l设计组件要高聚合。l考虑使用基于消息的通信来调用业务组件。l通过服务接口来暴露进程。l保证业务组件的输入和输出数据是一致的。l将服务功能暴露，而对数据存储不可知。要使用松耦合的设计。l考虑使用业务流程组件来实现业务规则。l如果程式中的业务规则经常改变，则将规则存储在一个业务引擎里。l如果业务流程涉及多个步骤以及长时间运行的事务，考虑使用工作流组件。l对组件的各个组成部分实现高效和合适的管理。业务实体业务实体存储数据值并且通过属性来访问；他们提供有状态的编程方式去访问业务实体以及相关的功能。因此，设计或选择合适的业务实体对

43、于提高性能和业务层效率是至关重要的。当设计业务层实体时，考虑以下原则：l在不合适的地方避免为业务实体使用域模型模式(Domain Object,系统的核心业务对象)。l为你的业务实体选择合适的数据格式。l为你的业务实体考虑串行化需求。l使用轻量级的域对象(Domain Object)来呈现业务实体。l如果数据库中的表代表了业务实体，考虑使用Table Module模式。l尽量减少物理层间的调用。例如，使用DTO对象。缓存设计合适的缓存策略对于提高程式业务层的性能和响应非常重要。使用缓存来优化数据查找，避免网络数据包往返，避免不必要的和重复的处理。作为缓存策略的一部分，你必须决定什么时候并且怎样

44、来加载缓存数据。为避免客户端延迟，使用异步加载数据方式或者使用批处理。当设计缓存策略时，考虑以下原则：l评估业务层缓存的数量规模。过度的缓存会引起反作用。l在业务层缓存静态数据可以经常的被重用。l缓存数据可以不通过数据库来快速和有效率的检索。l在业务层使用Ready-to-use缓存数据。l如果可能的话，避免缓存敏感的数据，或者在缓存里设计一个机制以保护敏感数据。l考虑Web怎样部署会影响你的业务层缓存方案。耦合以及内聚当设计业务层组件的时候，保证他们都是高内聚，并且层间低耦合。这有助于帮助提高程式的可伸缩性。当设计耦合和内聚时，遵守以下规则：l在层之间避免紧耦合。业务层只需要知道它以下的层(

45、数据层)，而不需要知道以上的层(表现层或访问业务层的外部程式)。l对业务层使用基于消息的接口。l业务层组件要高内聚。l避免在业务层组件中混合业务逻辑和数据访问逻辑。并发和事务设计并发和事务时，选择合适的并发模型和决定管理事务的方式非常重要。你可以在乐观的模型和悲观的模型之间(an optimistic model and apessimistic model)选择并发模型。当设计并发和事务时，考虑以下原则：l如果在操作重要的业务，考虑使用事务。l当访问单一的数据源时使用基于连接的事务。l注意事务的边界。l在不能使用事务的地方可以使用compensating方法将数据回复到以前状态。l避免长时间

46、保持锁状态。l考虑你是否要使用optimistic or pessimistic locking。l选择合适的事务隔离级别。数据访问为业务层设计一个有效的数据访问策略对于维护以及分离关注点非常重要。当设计数据访问层策略，考虑以下原则：l避免在业务层组件中混合数据访问代码和业务逻辑。l避免在业务层中直接访问数据库。l考虑使用单独的数据层来访问数据库。异常管理设计有效的异常管理方案对于业务层的安全性和可靠度非常重要。如果不考虑这些的话你可能会使用程序至于DoS攻击或者暴露敏感信息。产生以及处理异常是昂贵的操作，要考虑性能的影响。当设计异常管理策略时，考虑以下原则：l不要使用异常来控制业务逻辑。l区

47、分对待边界异常和内部异常。l考虑是否需要在边界间传递异常。l用统一的方法处理边界异常。l设计合适的异常产生策略。l为不能处理的异常设置策略。l设置合适的异常log策略。l设置合适的紧急错误和异常通知策略。l不允许异常暴露敏感信息。日志监控设计好的日志和监控方案对于业务层的安全性和可靠性非常重要。如果不考虑这些的话程序容易遭受抵赖威胁，用户可以抵赖他们的行为。在合法的处理中验证错误做法也需要日志文件。记录资源访问的具体时间以及访问方式，那么审查会更有权威。当设计日志和监控策略时，考虑以下原则：l统一记录和监控你的业务层。l在业务层中要监控关键业务的事件和紧急系统事件。l在业务层中审核和记录所有访

48、问功能。l不要在日志中存储敏感信息。l保证日志记录失败不会影响正常的业务层功能。服务接口当设计服务接口，考虑服务粒度和互操作性。当设计服务接口，考虑以下原则：l设计服务接口，当业务逻辑改变的时候不影响接口。l如果业务逻辑被不同的客户端以不同的方式访问，考虑实现多个服务接口。l根据组件需求考虑实现缓存映射，以及接口类型转化。l不要在服务接口中实现业务规则。l对参数使用标准的格式以最大化不同客户端的兼容性。l设计服务接口时，考虑不同平台之间的互操作性。l使用合适的技术以实现服务。l为服务考虑合适的传输协议及消息格式。验证对业务层不使用有效的验证策略，会使你的程式易受跨站脚本攻击，SQL注入攻击，缓

49、冲区溢出，以及其它类型的输入攻击。对于一个有效的输入和恶意的输入并没有完全的定义。当设计验证策略，考虑以下原则：l当设计验证方案，假设所有的输入都是恶意的。l在业务层所有输入和方法参数使用验证，同样包括表现层。l统一验证方法以重用。l选择合适的验证技术。l限制，拒绝，过滤所有输入。工作流当设计工作流组件时，考虑怎样管理工作流以及理解那些选择是否可用非常重要。请考虑以下原则：l在包含多步或长时间处理组件中使用工作流。l选择合适的工作流形式依赖于应用背景。l在工作流内处理错误的条件，暴露适当的异常。l如果组件必须有顺序以及同步的执行特定的步骤集合，考虑使用管道模式。l如果处理程式在任何命令下需要异

50、步执行，考虑使用事件模式。部署考虑当部署业务层时，考虑生产环境的性能和安全问题。请考虑以下原则：l将业务层和表现层放置到相同的物理层以提高程式性能。l如果必须支持远程的业务层，考虑使用TCP协议提高性能。l使用IPSec来保护业务层之间的数据物料传输。l使用SSL来保护业务层组件和远程WebService之间的调用。模式地图Category Relevant Patterns Authentication Direct Authentication Brokered Authentication Federated Authentication(SSO)Authorization Role B

51、ased Authorization Resource Based Authorization Claims Based Authorization Trusted subsystem Impersonation and Delegation Business Components Transaction Script Work Unit Command Application Faade Chain of Responsibility Business Entities Entity Translator Domain Model Table Module Caching Cache Dep

52、endency Coupling and Cohesion Adapter Dependency Injection Concurrency and Transactions Coarse Grained Lock Implicit Lock Optimistic Offline Lock Pessimistic Offline Lock Transaction Script Capture Transaction Details Exception Management Exception Shielding Logging and Instrumentation Provider Serv

53、ice Interface Service Interface Service Layer Faade Workflows Data-driven workflow Human workflow Sequential workflow State-driven workflow重要模式l程式门面(Facade)提供统一的服务层。l责任链(Chain of Responsibility)通过允许多个对象来处理请求以避免请求和发送者紧耦合。l命令(Command)在通用的执行接口里将请求处理封装在不同的命令对象里。l依赖注入(Dependency Injection)使用基类或接口来定义共享的抽象

54、以及使用它来注入到实例中以和共享的抽象接口交互。l域模型(Domain Model)创建Web的互连对象，每一个对象都代表一些有意义的个体，它可能象一个公司那么大或者象一条线或一个命令窗体那么小。l实体转换(Entity Translator)实现一个对象以将消息数据类型转换为业务需要的类型，将响应的业务数据类型转换为输入需要的类型。l门面(Facade)对操作集合使用统一的接口以减少系统间的耦合。l服务接口(Service Interface)系统使用编程接口来和其它系统交互。l服务层(Service Layer)使用单独的层来实现服务接口。l表模块(Table Module)创建一个组件在

55、数据库表或视图中处理业务逻辑。技术考虑l使用Windows工作流以简化工作流开发，自动支持安全，可依靠性，数据交互，广泛的传输和编码选择以及提供内置的持久性及行为追踪。l如果要和非微软系统交互，使用BizTalk Server 2006来执行EDI操作。l只有当业务层被限制只能访问SharePoing站点时使用MOSS。l使用Transaction Scope(System.Transactions)来管理横跨多个数据源的事务。Additional Resources For more information on caching techniques,see Caching Architec

56、ture Guide for.NET Framework Applicationsat more information on data access techniques,see.NET Data Access Architecture Guideat more information on design patterns for business layers and components,see the following resources：Enterprise Solution Patterns Using Microsoft.NETat Patternsat Orientation

57、 Patternsat Patternsat more information on exception management techniques,see Exception Management Architecture Guideat more information on performance in business layers and components,see the following resources：Design Guidelines for Application Performanceat and Design Review of a.NET Applicatio

58、n for Performance and Scalabilityat more information on security issues in business layers and components,see the following resources：Designing Application-Managed Authorizationat Guidelines for Secure Web Applicationsat and Design Review for Securityat应用层：在核心层以上，依赖于核心层；表现层原则概览：表现层的组件要实现和展示用户接口，管理用户

59、交互。这一层包括用户输入和显示的控件，用户交互的组件。下面的图表显示表示层如何融入一个通用的应用架构。表现层组件l UI组件。UI是用户和应用程序交互的接口，负责呈现和格式化数据，同时获取和验证用户输入数据。l用户处理组件。用户处理组件同步和协调用户交互。当系统有复杂的用户接口时，单独的用户处理组件可能会有用处，用分离的组件实现通用的用户交互模式，可以使你在多用户接口时重用它们。方法当设计表现层时，用下面的步骤帮助组织你的思维：1.识别你的客户端类型。根据你的需求，基础结构和部署限制来选择客户端类型。2.确定你怎样去呈现数据。选择数据格式并且决定UI的数据呈现方式。3.确定数据验证策略。使用数

60、据验证技术过滤不安全的用户输入。4.确定业务逻辑策略。减弱业务逻辑对表现层的依赖。5.确定与其它层的通信策略。如果你的系统有很多层，如数据访问层及业务逻辑层，确定你的表现层与它们的策略。设计时考虑的内容：当设计表现层时，使用下面的原则：l选择合适的UI呈现技术。确定你是要实现Rich(Smart)Client,还是Web Client,Rich Internet Application(RIA)。l实现相关的模式。用已经证明的模式去解决通用的表现层问题。l设计时专注于不同的方面。使用专门的呈现UI；使用专门的表现层实体获取数据，并将数据提交给视图；使用专门的UI处理组件来响应用户交互。l考虑用

61、户体验。审查系统的用户交互设计，根据不同的客户端类型和开发技术来修改原有的用户交互准则。l坚持用户驱动设计原则。在设计表现层前，要了解客户。要充分的调查，研究方案的可用性，跟客户访谈来决定最好的表现层设计，以满足客户的需求。表现层框架类别通常的问题Caching缓存了易变的数据。缓存了没有加密的敏感数据。选择了不正确的缓存存储方式。在WEB开发时没有使用适当的缓存技术。假设数据在缓存里一直可用-但它有可能过期或被移除。Composition没有考虑在运行时使用模式或类库来实现动态布局和视图注入。使用依赖类和服务支持的表现层组件来代替支持运行时的依赖注入。没有在组件中使用发布/订阅方式来支持事件

62、。没有使应用程序象单独的模组一样容易添加。ExceptionManagement没有捕获不可处理的异常。当异常发生时没有清空资源和状态。将敏感的信息展现给终端客户。使用异常来实现程序逻辑。捕获你处理不了的异常。在不需要的地方使用自定义异常。Input设计的时候凭直觉，或实现了超级复杂的接口。设计的不容易理解。没有考虑不同的屏幕大小和分辨率。没有考虑不同的设备或输入类型，如移动设备，触摸屏等。Layout为Web设置不适当的布局。实现了过为复杂的布局。没有选择合适的布局组件和技术。没有坚持可理解性和可用性的准则。实现了不合适的工作流接口。没有支持本地化和全球化。Navigation不一致的导航。重复的逻辑处理导航事件。使用硬编码导航。对于向导式的导航，没有管控状态。Presentation Entities定义了不需要的实体。在需要的时候没有实现序列化。RequestProcessing在长时间的请求中锁住了用户接口。混合了处理和呈现逻辑。选择了不合适的请求处理模式。User Experience显示了无帮助的错误信息。缺少响应。过于复杂的用户接口。缺少用户个性化。缺少用户权力。设计了效率低的用户接口。UIComponents在不需要的时候创建了用户组件。在MVC模式下没有