AJAX架构培训资料-XHW

1、第1章 引言2第2章 系统框架结构设计32.1 多层结构设计32.1.1 多层架构结构示意图42.1.2 多层框架代码表达62.1.3 查询流程在多层结构中的流转过程82.1.4 编辑流程在多层结构中的流转过程102.2 多层结构实现说明112.2.1 数据实体层（Model）112.2.2 公共层（Common）132.2.3 数据访问层（DataAccess）152.2.4 业务层（Business）162.2.5 服务提供层（WebSite）182.2.6表现层（.aspx/html）202.2.7客户端处理层（.js）22第3章 模板代码解析233.1 数据模型组件(XXXXData.

2、cs)233.1.1 设计说明233.1.2 实现技巧说明243.2 数据访问组件(XXXXDao.cs)243.2.1 设计说明243.2.2 实现技巧说明253.3 业务组件(XXXXHandle.cs)263.3.1 设计说明263.3.2 实现技巧说明263.4 服务器端页面处理代码解析(XXXX.cs)273.4.1 设计说明273.4.2 实现技巧说明273.5 客户端页面处理代码解析(XXXX.js)273.5.1 设计说明273.5.2 实现技巧说明28 第1章 引言随着新虹伟科技术有限公司业务的急剧鼓胀，项目越来越多，项目的复杂程序也不断提升，原有的开发、组织模式已经远远不能

3、满足日益增长的业务需求,软件开发团队在不同程度暴露出以下几个方面的问题：1. 难以形成合力开发较大的软件项目2. 项目缺乏集中统一的管理，难以形成产品3. 难以估算工作量，项目或产品的预算严重超支4. 缺乏统一的基础架构，新进的人员很难在较短的时间内融入团队5. 项目经历人员流动带来的困难加剧这些问题给公司的管理带来了极大的困难，对公司的发展形成了极大的障碍。经过部门及公司的讨论，决定对现有的人员结构、开发模式进行较大幅度的调整、改进，最后经过核心技术人员的磋商，决定采用以“敏捷开发”为主要风格的项目管理模式来运作项目，并决定研发一套基础架构，来支持这种组织理念，并达成以下目的：1. 将软件开

4、发的流程在框架体现出来，并通过培训让团队成员快速掌握，从而将团队成员的一部分精力解放出来，可以更多的关心业务。2. 将纷繁复杂的开发规则以“模板代码”的方式提供出来，以减少团队成员的学习量，减少从文档到代码转换的工作量以及转换过程中产生的巨大偏差。3. 将常用的技术点都包含在其中，使用大家可以快速的掌握最有效的技术点。4. 为吸收更好的做法，促进、完善开发基础结构建立完整的物理基础。5. 为团队的管理（如工作量化，技术难点的分离，进度的估算等）提供可靠的物理支持。6提供对需求分析的方向性指导，并严格验证需求分析中的疏漏。第2章 系统框架结构设计2.1 多层结构设计多层框架是分布式系统的产物，一

5、般资料上所介绍的多层框架是指“物理意义上的多层框架”，如下图所示： 但在行业应用中，通常我们所用的多层框架是指逻辑上的多层框架，“业务逻辑组件”与远程服务器上的“远程服务发布组件”在绝大多数时候是部署在一台服务器上的。根据以往的经验，我们通常把业务逻辑组件分成两个部分：一是业务逻辑特性，二是部署特性。我们关注业务逻辑组件应该重点关注其“业务逻辑特性”,通常不直接提供分离部署的功能。如果“业务逻辑组件”与“远程服务发布组件”需要分离部署，我们则单独考虑“组件的远程通讯功能”。这样我们的精力主要关注“业务逻辑组件的业务特性”而不是其“部署特性”。在以下的部分中，我们所指的“业务逻辑组件”均不包含“

6、部署特性”, 所以我们所指的“多层架构”也是指“逻辑意义上的多层架构”, 如果我们没有特别说明，以后均遵循此约定。2.1.1 多层架构结构示意图(1) PDA框架(2) B/S应用端框架(3) 关于多层框架的结构说明上图所示结构，展示了业界流行的“三层架构”，无论我们用什么语言来实现，此结构均适用。在服务器端的业务层实现接口，是为了让业务组件可以具备远程通讯功能，接口是充当代理类的作用，而不是为了支持多种实现而设计，当然使用了接口，做多种实现肯定是可以的，但那不是我们设计的初衷。注：分布式系统在NET中常用的技术是很多的，早期的Remoting要实现组件的远程布署能力需要实现一个接口，并继承M

7、arshalByRefObject, 改进后的WCF需要实现一个接口，将来的C/S应用我们主要使用WCF所以让业务组件实现一个接口,从而为其增加远程布署特性。业务层（BLL)2.1.2 多层框架代码表达UI数据模型层( xxxxData.js)UI事件入口层(xxxx.js)UI处理层( xxxxProcessor.js)WCF代理层(Ixxxx)WS服务提供层(PPServices)表现层（Html-aspx )IE服务提供层AjaxPro.AjaxMethod )实体层(Model)数据访问层（DAL)公共层（Common）关于多层框架的结构实现说明：(1) “代码代达”不仅指用具体语言编

8、写的程序，它至少还应该涵盖以下几个方面的内容n 代码所处的位置，包括：解决方案、项目、文件夹。n 各种结构及类如何命名更加清晰，不易混淆。n 各种非代码性的资源组织。n 所解决的问题、组织思路。n 如何平衡其优缺点。如果在代码中不能完整的体现上面所说的几点，这个框架的完整性，就存在缺陷，必然在应用中不同程度的体现出来。(2) 良好的代码组织结构是工程良性进展的必要条件，是体现工程总体结构的实际可操作的蓝图，是开发过程控制中具有决定性战略意义的一环。(3) 充分理解系统框架是进行团队合作的“物质基础”。图中所示的部分与“多层框架示意图”有一一对应的关系，均在图中标明。蓝色部分属服务器端的结构，土

9、红色部分属客户端结构。(4) 目前，我们考虑到团队的具体情况先用vs2008+C#+ajax来实现这种结构，其中客户端与服务器端通讯采用较有名的第三方组件包“AjaxPro.dll”（官方网址：）2.1.3 查询流程在多层结构中的流转过程关于查询流程的实现说明：(1) 实现这个过程时，应该按图示的要求实现(包括：类的名称、方法名称)，并充分理解:目录组织规律、类文件命名规则、理解页面的工作过程。同时，对实现此过程的技术难点应先作测试。(2) 实现者必须明确一个理念：这个过程体现了我们编写数据库这类软件的基本思维过程，对我们“量化工作、控制过程”具有决

10、定性的战略意义。(3) 我们的一些具体规范，应尽量在代码中体现出来，尽量不要用文档以条目的形式来罗列，这样加大程序员“从文档到代码转化”的学习量和难度，必须明确一个理念：程序员的语言就是代码，用代码表达的规则是最无二义性的文档。其它用图形和文字描述的文档都是辅助性的，不是最终文档。甚至我们可以这样下一个结论，在中国绝大部分软件公司，如果把这些规则写成文档，并以文档作为主体来规范开发，是注定行不通的。(4) 在实现此过程时，应先整体后局部，先结构后细节，不要一个类一个类的顺序实现。(5) 实现过程中，在数据访问组件上除了体现查询数据库的基本过程，另外对我们开发的公用数据访问组件包的使用也应充分体

11、现出来。2.1.4 编辑流程在多层结构中的流转过程关于编辑流程的实现说明：(1) 查询流程的实现规则在此全部适用。(2) 实现过程中，应体现出“服务器端数据”传递到“客户端”的过程。2.2 多层结构实现说明2.2.1 数据实体层（Model）(1) 设计说明：n 充当层与层之间数据交互的载体，属系统的最底层结构，可被其它任何层使用，但不 能使用其它任何层(第三方组件包除外)。从项目引用的角度上来说即：不能引用其它任何项目(除第三方组件包)。n 每个最子模块单独起一个目录，每个子目录下至少分两个文件：Ø 一个以Query作后缀，用于传递查询参数;Ø 一个以Data作后缀，用于

12、传递要保存的数据;这样设计的目的是当遇到复杂的模块，需要写复合的实体类时，能很好的管理这些类。 (2) 文件说明：文件功能说明注意Common BaseData.cs(1) 用于定义数据实体常用的公共信息，目前包含：创建时间、更新时间，以后我们可能会酌情增加相关的公共属性。(2) 在数据表设计时，我们要求相关的数据表一律要创建这两个字段。(1) 如果没有特别说明，所有数据实体类应该继承该类。(2) 所有数据实体类继承该类会产生一定的数据冗余，但我们考虑到编程的方便性，允许这种冗余存在，使用时大家注意就行了。(3) 对于复合类的子类，在设计时可以不继承此类，但需要与主导设计的人员作个确认。Com

13、mon BaseQuery.cs用于定义查询实体常用的公共信息，目前包含的信息请查看文件以及相关的说明，这里只对部分属性作说明。具体用法，我们在框架讲解时再作说明。(1) Fields:很多时候我们查询时可能需要根据不同的需要，对字段作出筛选，该属性是用于作字段筛选用的。(2) FilterStr:用于承载前台查询条件，也就是当条件由前端生成时，使用些属性。(3) OrderByStr:用于承载前台生成的排序条件。我们已在系统使用此属性。(1) 如果没有特别说明，所有查询实体类应该继承该类。(2) 所有查询实体类继承该类会产生一定的数据冗余，但我们考虑到编程的方便性，允许这种冗余存在，使用时大

14、家注意就行了。CommonResultBase此类是复杂返回类型的基类，目前并有具体定义其具体的属性，可以根据系统的实际需要合理扩展。(1)如果有自定义的返回类型均应继承些类，以便为系统留下扩展空间模块关键字xxxxData.cs用于定义各模块在层与层之间传输的数据 (1) 各模块对应的数据类都应按设计的路径存放到指定位置，不应该随意存放，如果发现设计不妥应及时纠正。所有实体类均以Data结束。模块关键字xxxxQuery.cs用于定义各模块在层与层之间传输的查询参数(1) 同上(2) 所有的查询实体均以Query结束(3) 补充说明：n 数据实体不应该简单的理解为“与数据库字段一一对应”，很

15、多人之所以产生这种误 解，是因为我们编写软件，始终离不开“代码操纵数据”这样一个基本点，而我们“操纵的数据”来自于业务领域，数据库的字段也来自业务领域，所以在很多时候“数据实体”与“数据库字段”看起来是相似的，甚至是一致的。但是，从我们设计的角度来讲，它们是两个概念。n 数据实体定义得是否合理，会相当程度影响到代码的质量、工程的进度，所以大家不要单纯从“技术点”的角度去看待它，“数据实体”几乎不包含任何高深的技术点，但其作用远远超越我们“架构体系”中的很多结构。可以说，我们设计一个具体模块的时候，所围绕的核心之一就是“数据实体”，这个核心对分析、设计、编码都具有相当重要的指导意义。它是“以面象

16、对象方式来解决问题”中的重要一环。只要我们的数据实体定义得不合理，我们代码发生紊乱的可能性就非常大。在适合“以数据为中心”作系统分析的系统中，数据实体前承界面设计，后接数据库设计，可以很好的验证这两方面设计的不足之处。n 数据实体，在我们的体系架构中最明显的一个应用就是充当“层与层之间数据交互的载体”，包括“查询参数”、“新增/编辑产生的数据”、“返回数据”，但其应用范围远不止于此。同时，我们在编写数据实体时，对逻辑相关紧密的属性，应用尽量排列在一起，主要的属性往前排列，辅助性属性往后排列，适当花些精力排列这些属性，对易读性能产生一定的效果。n 在设计数据实体时，最重要的一个方面在于：良好的业

17、务命名，这也是最花时间的部分，希望大家在设计时，选用的英文单词时，在准确性、简洁性、完整性方面多斟酌，不要随便选取一个单词就了事。数据实体的属性命名如果取得不好，随着系统的发展，在逻辑上引起混乱的可能性非常大。n 关于其它一些细节，将在代码实现中体现出来，此部分说明只是代码的辅助说明。2.2.2 公共层（Common）(1) 功能说明n 用于编写系统一些较小的公用代码, 凡是在系统编写过程中发现一些较小的可复用的功能，应优先考虑在此处增加相应的类或在现成的类里增加相应的方法来处理，在此处增加的任何类或方法尽量与技术负责人商量，不要随意添加，并让团队所有成员都清楚,也不应随意改动。凡是功能较大的

18、复用代码，应该提交团队设计，不应该随意开发，如我们的数据访问组件包、web页面自定义控件都属于较大的、较成体系的复用代码，其复用程度更高，作用更大，其设计和实现难度不是一个工程能容纳的，我们单独设计开发。n 对于很高复用级别的代码，尽量脱离此解决方案编写，升级到公用组件包，这样便于沉淀积累适用范围更加广泛的复用代码。下图是与我们目前的解决方案中，有关的公用组件包及其关系(其中土红色部分是第三方提供的包，不由我们的产品部分维护)：(2) 文件说明：文件功能说明注意SysConfigs.cs此类管理在配置中设置的参数，所有在配置文件中的参数必须经过此类来向系统提供，不应该直接在其它地方读取。这样便

19、于我们观察系统中用到的配置参数，同时为修改提供方便。(1) 有些没在配置中配置的参数，但随着系统的演化，有可能被配置到配置文件中，我们也应该写在此处，通过空行或注释来区分，没必要另外起一个类。SysConnection.cs用于提供系统数据库连接对象，数据访问层所使用的连接对象都由此类提供，不应该另外自己写。目前支持SQL和Oracle两数据库的“连接对象”和“事务对象”(1) 虽然目前我们很少会同时使用多种数据库，但考虑到这个类经常使用，并且代码量也比较小，所以我们一般都线性扩展，而不删除没用到的方法。 SysTool.cs系统复用的小段C代码基本上都写于些处，此处的代码会随着系统的开发逐渐

20、增加，但需要严格管控。此处目前包含的主要方法不多，请参见相应的类。我们次框架设计，都会对此类的方法进行整理，这里就不一一列出。(1) 此处的类方法将为静态方法即修饰关键字都有(Static)。(2) 此处的方法应是大家共知的,建议增加的时候告知团队,并说明其用意。(3) 在不同的系统中，此处的方法需要维护不应该采用线性维护的方式扩展。ServicesManager.cs此类是用于启动WCF服务的管理类，将来做C/S会用到，这里暂时就不作讲述。注： (1) 标为红色的类 ：大家需要知道其中有些什么方法及其作用，并需要参与共同发展此类的功能。(2) 标注为绿色的类 ：大家只需明白如何使用即可(3)

21、未作标注的类 ：大家只需了解有这么一个类及其应用方向即可，无需具体清楚其用法及使用的地方。此规则适用以后的部分。2.2.3 数据访问层（DataAccess）(1) 功能说明该层主要用于编写和数据库操作相关的代码，主要包括增、删、改、查询及提供事务支持等功能，凡是编写此类，你应该尽量假设：当数据库的字段发生变化时，你的代码有多少需要修改？应尽可能让代码的修改量减少，并尽可能让这种修改可以在数据访问层完成，而不用修改数据访问层以外的其它代码。否则你的数据访问层代码质量就可能存在不同程度的问题。但是也要防止矫枉过正，过分运用OOD的形式，引入过多的晦涩结构。(2) 文件说明：n 所有数据访问组件均

22、以Dao结尾，即Data Access Ojbect的缩写。n 示例中的数据访问组件将是我们以后写这类组件的模板代码，以复制的方式生成，在此基础上修改，以尽可能保持书写风格一致。n 所有的数据访问示例均放在“DataAccessExamples”目录中，供以后框架培训专用。关于数据查询及增、删、改方法凡是可用“DataAccessExamples”中的示例代码改写的均以目录下的文件为基准，在此基础上修改。如果遇到其中没有提供示例的情况时，请与团队沟通。n 所有数据访问组件尽可能封闭单表的处理，遇到多个表的处理时尽可能在业务组件上聚合，百分之八九十以上的事务控制均应以业务组件作为事务的“根”，但

23、在“业务组件上实现事务”在框架中暂时无需实现。n 如果遇到主子表的处理时，应该在数据访问组件中同时封闭对主子表的操作。另外遇到多对对关系表的处理也应在一个组件中封装，不应单独另起组件。我们以员工档案管理来示例些规则的实现。n 由于数据访问组件包含实现级的模板，里面细节较多，我们是在制作出过程的前提下通过“重构”来精心调整，并体现出更细的规则，这里不再作描述，我们统一以一个实现示例详细说明其注意点。2.2.4 业务层（Business）(1) 功能说明:该层主要用于：n 编写和业务处理相关的代码n 转调数据访问层的功能n 聚合其它业务组件由于一般的数据库软件，业务处理都在SQL语句中的构造过程中

24、完成，业务处理代码在大多数情况下都比较少，所以这里集中解释其对数据访问层的转调功能。通常一个模块对应一个业务组件，一个指定模块对其它数据访问组件的调用严格来讲，只能通过“业务组件”调用“业务组件”来实现，不应直接在“业务组件”调用其它模块的数据访问组件。在业务组件的写法上我们通过标准示例展示，这里不再说明。注：在“层与层之间”或“同一层的不同模块之间”数据传输尽量使用水平或垂直传递，禁止使用斜向或交叉传递，以免造成数据调用混乱或结构不工整，即红色线所示的调用关系是不规范的。（2）文件说明: 在这节大家应该注意以下几个方面的问题：n 所有组件均以Handle结尾。n 访问其它模块的数据，应该用“

25、本业务组件上”调用“其它模块的业务组件”的方式“聚合”，而不应该出现图示中所示的调用规则。这主要是基于以下原因：Ø 在业务组件可能会数据进行处理，如果我们绕开业务组件可能导致这种处理失效。Ø 我们希望“业务组件”的“上层组件”对“业务组件”的调用不依赖于太多的“业务组件”，也就是以“本模块的业务组件”充当其上层组件的“门面”这样调用层对业务层的依赖降低。Ø 不宜以某个模块的处理简单为由，而放弃这个对调用规则的违背，因为我们无法对什么是简单，什么样是复杂进行较为精确的定义，为了较好的统一开发模型，我们决定这样做。同时，我们经过分析认为这样做带来的缺点是可以忽略的。n

26、 对永远只作为一整体使用的一组表在更新时，我们应该在数据访问组件中创建事务，不要在业务组件上创建事务，这样可以简化处理结构。除此而外，均应在业务组件上创建事务的根，但此结构示例中不用实现。n 在“员工档案的数据更新时”应体现出对多处记录同时进行更新的处理。n 以“员工档案的数据编辑”为例，体现出聚合规则。2.2.5 服务提供层（WebSite-xxxxService.cs）(1) 功能说明“服务提供组件xxxxService.cs”是提供JS调用服务器端功能的组件，客户端调用时是通过“JS代理类”完成的。而要生成这个代理类，则必须在“页面后台代码(xxxx.cs)”中注册，注册后就可以生成它在

27、客户端的副本(即JS代理类)，这样客户端便可调用服务器端功能。通俗的讲，这样做向客户端发布了xxxxService.cs类提供的服务。下图是，页面继承关系图，另外页面还关联了服务类。框架基类：用于抽取多个系统的公用代码，并为框架的扩展留下空间系统基类：用于抽取一个特定系统的公用代码，并为系统的扩展留下空间页面类AJAX基类：继承此类后可以正常使用Ajaxpro.dll提供的功能。同时，此类扩展了注册简单客户数据的方法控件基类：继承此类后可以正常使用自定义的控件。服务提供类：提供由JS(XXXXProcessor.js)类调用的服务方法，具体格式及用法参见代码 (2) 文件说明(以xxxxxLi

28、stService.cs子模块的列表页面为例)文件功能说明注意Microsoft.AjaxCommon. AjaxBasePage(1) 此类以第三方组件包的形式提供，只有继承了此类， 传统的.aspx文件才能提供针对“客户端即js类”的服务。(2) 此类是支持整个AJAX框架“服务调用”的基础，即支持“服务器-客户端”进行交互的基础，属组件级支持。(1) 大家需要理解这个类的作用，如何使用，框架已经封装好，在实际应用中不会直接使用此类(2) 此类存在于Microsoft.AjaxCommon.dll文件中。Microsoft.WebControls.Common.WebControlPage

29、Base(1)此类亦以第三方组件包的形式提供，它继承自上面的Microsoft.AjaxCommon. AjaxBasePage, 通过继承此类，.aspx文件中才能使用“Microsoft.WebControls.dll”中提供的控件。(2) 此类是支持整个AJAX框架UI的基础之一，属组件级支持。我们的UI元素主要由三个部分组成：(1) html标准元素(2) aspx服务器端控件/ html服务器端控件(3)第三方控件(包括在Microsoft.WebControls.dll中提供的控件)大家需要理解这个类的作用，如何使用框架已经封装好，在实际应用中不会直接使用此类。FrameBase.

30、cs(1) 此类直接包含在工程中，主要提供“基础框架级”的功能支持，它继承自上面的Microsoft.WebControls.Common.WebControlPageBase,主要用于扩展比较通用的功能，也就是，在各种系统中都适用的功能。(1) 大家需要理解这个类的作用，如何使用框架已经封装好，在实际应用中不会直接使用此类(2) 此类会根据系统基础框架的发展进行扩展，是需要维护的，新扩展的功能，应及时告知团队成员。PageBase.cs(1) 此类直接包含在工程中,主要提供“系统级”支持，它继承自上面的FrameBase.cs，主要用于扩展: 针对“特定系统”都通用的功能。(1) 大家需要理

31、解这个类的作用，如何使用框架已经封装好，在实际应用中一般人员不会直接使用此类(2) 此类会根据系统的发展进行扩展，是需要维护的，新扩展的功能，应及时告知团队成员。xxxx xxxxBase.cs此类是有关“特定模块”的相关页面的基类，主要用于提供整个模块所用到的公用功能，现在提供了对业务组件的引用，以后会在实践中扩展。 (1) 这里我们把基类按“代码复用”的方式来使用。基类还有另外一种使用方式，即作为一个“可带实现的抽象结构”，这在“设计模式”中会很常见。(2) 系统每确定一个模块都需要增加一个这样的基类。xxxxListService.aspx此类提供由客户端JS调用的AJAX服务，其发布由

32、List.aspx完成xxxxList.aspx定义UI、在UI传输到客户端之前进行一些初始化工作。真正的客户端代码应该是此文件经过服务器处理后，送到IE中的HTML代码及相关JS文件、样式文件等。 每个模块要完成相关的功能，都需要定义一组UI,这里仅例举了“单列表页面”的“列表”页面文件，其它文件，我们在具体分析框架的过程中讲解。2.2.6表现层（.aspx/html）(1) 功能说明A的页面由2-3个文件组成:n xxx.aspxn xxx.aspx.csn xxxx.aspx.designer.cs如果是以站点模式创建的页面只有前两个文件，以项目方式创建的网站，则有三个文件。通常大家把这

33、些文件统称为“页面”文件。真正的“表现层”应该是这些文件经过“IIS服务器”处理后生成到“浏览器”中的“代码及相关资源”，这些文件只是“表现层”的“中间文件”。在我们的框架中，分得比通常的做法更细一些，我们把生成到浏览器的“代码代码及相关资源”又划为了，如图所示的分层：下面是生成表现层的简单示意图，大家可以在浏览器中查看相关的表现层代码：首先用户输入网址，经过服务器处理后，然后生成响应流，最后生成 “呈现在浏览器中的文本”就是我们所要操作的表现层，我们的代码主要和此文本相关。单击页面右键将弹出一个菜单，点击查看源文件选项，将出现记事本，记事本里所包含的内容即是我们将要用JS操作的表现层读取文件

34、生成HTML（2）文件说明文件网页文件说明xxxxList.aspxxxxxList.csxxxxList.aspx.designer.cs这三个文件定义表现层元素及相关资源的引用，我们框架中样式及JS文件的引用，与一般的开发有差别，是通过代码生成的，其中：1 RegisterClientResources：引用相关的JS,CSS文件，并绑定客户端事件。这些资源并非在一个文件中完成，基也完成了一部分共用文件的注册。2 RegisterClientData：注册客户端数据，目前由AjaxPageBase,提供了ConfigData, ClientData两个属性，其实是两个Hashtable,

35、AjaxPageBase,会根据其中的内容在客户端生成两个JS类：ConfigData属性： 在客户端生成ConfigData实例(JS类)。ClientData属性： 在客户端生成ServerData实例(JS类)，之所以这样命名是因为相对于list.cs属服务器端代码，对它来说，是生成客户端数据，所以属性取名为ClientData，但对客户端(IE)来说，这些数据是来自服务器，所以取名为ServerData，这样命名，概念更加清楚。关于这两个 关于这两个属性的用法请参见代码。另外，在客户端是通过Pages/ Resources System/ JavaScript/ PageBaseDat

36、a.js这个类来引用“这两个属性生成的JS类”,即如下代码：/reference data from serverthis.ConfigData=window.ConfigData; this.ServerData=window.ServerData;3. 由系统框架已经注册的资源及数据(1) 已经注册的资源包括：* WebControlPageBase.cs完成：Pages/ Resources/WebControls/JavaScript/Common/WebTool.jsPages/ Resources/WebControls/JavaScript/Common/ InnerTool.j

37、s* FrameBase.cs完成：Pages/ Resources System/Css/base/main.cssPages/ Resources System/JavaScript/SysTool.jsPages/ Resources System/JavaScript/PageBase.jsPages/ Resources System/JavaScript/PageBaseData.js* List.cs完成：请参见代码(2) 已经注册的数据包括：* WebControlPageBase.cs完成：VirtualPath：网站虚拟路径WebControlsImagePath：控件所使

38、用的图片路径这两个属性是支持控件正常运行必须的，这两个属性均在ClientData中。* FrameBase.cs完成： 目前未注册任何数据ResourcesSystemCssmain.css所有“页面”公用的样式文件ResourcesSystemCsslist.css所有“分页列表页面”公用的样式文件其它文件由于系统涉及的文件较多，这里均不再列举，我们将在讲解示例时一一说明2.2.7客户端处理层（.js）(1) 功能说明按照上一小节所说的结构，将“生成到浏览器中的所有元素”视为表现层，那么这节所讲的内容，就是如何通过“JS代码”来操作这些元素，收集数据，处理数据（包括与服务器端交互）。(2)

39、 文件说明文件网页文件说明xxxxList.js本节的文件均在框架的示例中作说明xxxxListProcessor.jsxxxxListData.jsResourcesSystemJavaScriptPageBase.jsResourcesSystemJavaScriptPageBaseData.jsResourcesSystemJavaScriptListBase.jsResourcesSystemJavaScriptListBaseData.js第3章 模板代码解析3.1 数据模型组件(XXXXData.cs)3.1.1 设计说明(1) 关于实体封闭变化的说明 我们使用数据实体来充当多层框

40、架层与层之间数据传输的载体，主要基于以下方面的考虑：n 扩展性的考虑: 因为多层框架来源于分布式系统，而分布式系统有一基本原则：使用“粗粒度接口”而不是“细粒度接口”,这样当数据参数发生变化时，我们需要修改的地方就会减少。n 面向对象原则：从面象对象的角度来看，实际上就是我们分析出：引起接口变化的主要因素是参数，我们把这种变化用一个类来封装，从而改进了类的接口，提高了类的稳定性。因此从本质上来讲，这样做是符合面象对象的“开-闭原则”的。虽然在一些介绍分布式的书提到“粗粒度接口”可能不被一些面象对象的拥护者所接受，但我们认为“粗粒度接口”从本质上讲并不违背面象对象设计的原则。(2) 关于复合实体

41、类的说明(3) 关于复杂返回结构的说明3.1.2 实现技巧说明(1) 自动生成的技巧 创建实体类的时候，可以先从数据库复制字段到文件中，然后以此为参考，定义私有成员，然后利用系统自带的功能，自动生成属性，没有必要每个属都直接输入。(2) 另开工程创建的技巧 当系统类的数量较多，自动生成可能比较慢，这时可以开一个辅助环境，在辅助环境中来生成实体类最后再复制到现在的工程中。3.2 数据访问组件(XXXXDao.cs)3.2.1 设计说明(1) 关于数据访问组件使用第三方组件的说明现在流行很多和数据访问层相关的一些第三方组件，比如：Nhibernate, 微软企业级组件包等都是一些比较好的第三方组件

42、，那么，我们为什么不用这些第三方组件，而使用自行开发的组件包呢，主要基于以下原因：n 第三方组件包学习量较大，在我们没很好掌握之前不提倡使用，我们在使用第三方组件包的时候，应该先进行技术点的测试，然后进行“实用性”的测试，最后再综合评估其“使用价值”，而这个过程通常需要的时间是比较长的。n 设计的目的是“解决问题”，我们认为目前我们自己的组件包已经很好的解决了问题，而第三方组件包很多常用的功能并不提供，反而是提供了很多我们根本不怎么使用的功能，我们的组件使用已经很成熟学习量很小，所以从我“解决问题”的角度来说，我们并不认为第三方组件包优于我们自行开发的组件包。 (2) 关于SQL几个扩展参数的

43、设计说明（字段、排序、条件） 我们框架中的数据实体提供了Fields, SortFields, FilterStr三个参数，主是基于系统扩展的考虑，在我们系统示例中并不直接提供体现其作用的实现，但我们决定仍然保留这几个参数。此处我们不过多的解释这几个参数是为什么情况下的扩展而设计。以后在框架的运作过程中再作说明。(3) 关于运算密集型组件解释 在我们的框架中,对查询统一使用select()及selctPage()这两个方法，但这个物理结构对业务密集型运算并不适合，对业务密集型运算，应该以业务运算为中心组织类的行为即方法，而不是统一使用这两个方法。关于业务密集型运算，是个比较特殊的话题，我们不在

44、框架中体现对其如何处理,但我们应该知道，我们的数据访问组件模板代码，并不是任何模块都可以此为模板来修改完成，我们框架更注重的是“普遍性”而不是“特殊性”。(4) 关于异常处理结构的设计说明 在框架中我们的数据访问组件使用trycatch结构来处理一些异常，如“某字段是否重复、某数据是否正在使用中” 之类的异常，但这仅仅是一种处理方法。严格来讲，这些并不能算是异常，而是正常的操作，所以我们应该理解为：我们是借助C#的异常处理结构来验证用户输入的数据，无论这种验证是否通过，但这种操作都是正常的，而不是“异常”。(5) 关于OR映射的设计说明 关于OR映射的讨论是一个比较常见的问题，现在常见的一些第

45、三方组件通常都提供了对OR映射的支持，以及代码生成工具，对OR映射功能范围也是定义得比较广泛。但是我们实际使用OR映射通常是用于数据库字段与数据实体的对应，对其它方面的功能极少使用。而我们研究了一些第三方工具如：Nhibernate, 微软企业级组件包，我们发现这种映射从本质上讲就是在查询语句中进行“别名”转换。所以，我们认为没有必要为了这么一个简单的功能，而引入一个庞大的第三方组件包，因此我们通过提供一个类的私有成员m_XXXXMapping和一个通用方法:Microsoft.Common.Table.Mapping,来进行这种转换，如果有必要也可以将m_XXXXMapping放到XML配置

46、文件中。这样，我们即吸纳了OR映射最主要的优点，同时也避免了引入第三方组件包带的缺点。3.2.2 实现技巧说明(1) 关于复制处理的技巧说明 我们制作的示例是作为一种标准来使用。所以，以后在使用过程中主要是通过复制、粘贴来完成，然后通过查找替换来生成不同模块的初始代码，然后再在此基础上进行修改。但这并不意味着代码的重复，数据访问层在实际应用中存在着太多的特殊性，是很难作出一个完全统一的抽象或是实现的。(2) 关于实现顺序的说明 在实际开发中，我们实现一个模块的顺序是从“数据访问层”往“表现层”串联合理，还是从“表现层”往“数据访问层”串联更合理呢？这要看实际情况而定，不能一概而论，这里我们提供

47、几个经验供参考：n 如果一个模块的需求、设计越是模糊，就越适合从表现层开始往下串。n 如果一个模块的需求、设计越是清晰，就越适合从数据访问层往上串。n 如果需求、设计的清晰度不太好界定，就只能根据具体情况来看。 3.3 业务组件(XXXXHandle.cs)3.3.1 设计说明(1) 关于业务聚合的说明 业务组件在具体的系统中，总体遵循一个大的方向：一个模块对应一个业务组件，这样表现层对应的组件就会相对单一，系统结构就会相对变得更加清晰。从我们设计的意图来讲，就是让这个组件不仅提供业务处理功能，同时充当页面层访问业务组件的“门面”，当一个模块涉及到多个业务组件的时候应该聚合其它的业务组件，而不应该聚合数据访问组件。这样做的优点如下：n 如果我们要观察一个模块涉及哪些业务处理的时候，我们可以在模块对应的业务组件上观察，而不必从“调用处”去查找。n 如果直接聚合数据访问层，可能会绕过对数据的业务处理。n 由此可