智能建筑信息集成平台的设计与实现硕士毕业论文(57页).doc

《智能建筑信息集成平台的设计与实现硕士毕业论文(57页).doc》由会员分享，可在线阅读，更多相关《智能建筑信息集成平台的设计与实现硕士毕业论文(57页).doc（57页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-智能建筑信息集成平台的设计与实现硕士毕业论文-第 49 页 智能建筑信息集成平台的设计与实现 摘要智能建筑技术在我国已经发展了十几个年头，随着我国的建筑市场发展的越来越快，目前我国的建筑智能化已经成为全球最大的市场。而近年来随着IT技术的发展，智能建筑所采用的产品、技术、系统也获得了很大的进步，整个行业的管理也逐步的健全和规范。但是在运营管理、高效节能、项目维护、工程实施监管、软件规划设计等方面还存在着许多不足之处，特别是有关智能建筑系统信息集成方面，更是值得进一步的商榷。信息集成平台作为一个针对企业信息化建设而开发的分布式框架，使用微软最新的.NET平台下的C#语言构件的开发过程，以插件化

2、的构件定制和复用来生成业务实现过程，阐述了基础框架部分的开发模式，利用分层模型和抽象工厂模式来解决平台分布式和构件化的设计架构，并给出了基础业务框架层和应用实现层的体系结构，分析了集成平台的关键设计。并给出了集成平台的实现细节和实现技术。最后，通过该平台在建筑智能领域的应用，以该平台为核心，将集团的智能化系统从功能到应用进行开发和整合，从而实现对智能建筑全面和完善的综合管理。并且通过平台大幅提高后续子系统研发中的开发效率。对集团的技术积累和产品化路线规划起到积极的推动作用。关键字：智能建筑，信息集成，.NET，框架技术，构件AbstractIntelligent Building Techni

3、cal has developed about ten years in China. With the high speed developing of building market, China has been the biggest market in the world. Because of the development of IT technical, the system, technical and product of intelligent building have a great advancement. Everything goes well as befor

4、e. Even it has so many development, we can found there are still a lot of deficiencies exist. For example, Operation Management, Energy Efficient, Project Maintenance, Project Monitor, Software Design and so on. Especially the theory of Information Integration of Intelligent Building System needs to

5、 have more practices.The platform of Information Integration is a distributed framework which developed for Enterprise Information System. With the C# language of .NET framework. Using the pluggable and reuse to implement the business processes. It also elaborated the development model of basic fram

6、ework. Using hierarchical model and abstract factory to solve the distributed platform and component-based architecture. And designed the architecture of base business framework and application implement. Analyze the key design of integration platform. It also implement of the platform.Finally, thou

7、gh the exercise of the platform. Based on the this platform, integrate the function and application of enterprise intelligence system, to implement the integrated management of intelligent building, and improve the efficiency of development later. And promote the technical accumulation and product d

8、esign.Key Words: Intelligent Building， Information Integrated， .NET， Framework，Component.目录摘要IABSTRACTII图目录IV表目录V第1章 绪论11.1 课题背景11.2 研究意义11.3 论文结构21.4 本章小结2第2章 建筑智能信息集成平台的现状32.1 国内外现状32.2 存在问题42.2.1 缺乏全国性的权威组织42.2.2 智能化建筑技术产品还没有实现国产化42.2.3 缺乏政府的扶持政策42.2.4 智能建筑相关项目管理不规范42.2.5 对软件尤其是信息集成软件缺乏重视52.2.6 智

9、能子系统开发接口各异52.2.7 对现今的节能方面的考虑基本空白52.3 相关概念和目标62.4 本章小结7第3章 智能建筑信息集成平台系统架构设计83.1 平台总体分层模式83.1.1 整体介绍83.1.2 表示层（UI）93.1.3 服务层103.1.4 数据持久层113.2 总体技术架构123.2.1 整体架构介绍123.2.2 表示层技术架构133.2.3 服务层技术架构153.2.4 数据持久层技术架构153.2.5 基础组件架构163.2.5.1 异常管理模块163.2.5.2 日志管理模块183.2.5.3 配置管理模块193.2.5.4 事务管理203.2.5.5 缓存管理20

10、3.2.5.6 认证及授权管理213.3 总体功能架构233.4 部署及组件设计283.4.1 组件模型283.4.2 部署模型303.5 本章小结31第4章 智能信息集成平台系统详细设计324.1 分层详细介绍324.1.1 平台的数据持久层的详细设计334.1.2 平台实体对象层的设计374.1.3 平台服务层的设计394.2 平台系统类协作设计414.3 平台系统数据库设计434.4 平台系统界面设计444.5 系统设计与实现中的技术分析464.5.1 AOP(面向方面编程)474.5.2 WCF技术494.5.3 LINQ（语言集成查询）技术534.5.4 XML技术554.6 本章小

11、结58第5章 功能实现及应用效果595.1 建筑智能信息集成平台的实现效果595.2 功能实现效果分析625.3 本章小结62第6章 总结和展望636.1 本文总结636.2 未来展望63参考文献64作者简历66致谢67图目录图 3.1 智能建筑信息集成平台分层架构8图 3.2 人员模块的界面设计10图 3.3 智能建筑信息集成平台技术架构框图13图 3.4 表示层界面显示元素逻辑图14图 3.5Microsoft Exception Handling Application Block的设计图17图 3.6 Microsoft Logging Application Block的设计图19图

12、 3.7 Microsoft Caching Application Block的设计图21图 3.8 Microsoft Security Application Block的设计图23图 3.9 智能建筑信息集成平台功能结构图24图 3.10 智能建筑信息集成平台关键组件依赖关系图28图 3.11 智能建筑信息集成平台部署模型31图 4.1 平台数据持久层模块结构34图 4.2 平台实体对象38图 4.3 平台服务层模块结构40图 4.4 平台功能模块图41图 4.5 平台用户登录序列图42图 4.6 平台系统的数据库表结构44图 4.7 菜单维护的主界面设计图46图 4.8 菜单维护的新

13、曾界面设计图46图 4.9 LINQ（语言集成查询）概念结构图54图 5.1 平台登录主界面59图 5.2 平台日志管理界面59图 5.3 平台人员管理界面60图 5.4 平台数据字典管理界面60图 5.5 平台提示信息管理界面61图 5.6 平台角色管理界面61图 5.7 平台权限分级界面62表目录表 3.1 智能建筑信息集成平台模块说明和功能描述24表 3.2 公用模块说明和描述25表 3.3 通用编码模块说明和描述26表 3.4 主界面框架模块说明和描述26表 3.5 组织管理模块说明和描述26表 3.6 权限管理模块说明和描述27表 3.7 工作流管理模块描述和说明27表 3.8 元数

14、据管理模块描述和说明28表 3.9 智能建筑信息集成平台组件描述及说明28第1章 绪论1.1 课题背景随着社会发展和科技进步，智能化越来越受到国家和民众的重视。IBM提出了智慧地球的口号，我国也大力发展物联网。而体现在住宅等方面的需求也越来越大，欧美国家智能住宅由网络通信、安全防范、设备智控、影视娱乐、节能环保等五大系统组成。中国的智能化不仅会向发达国家的智能住宅功能方向上发展，而作为集团发展来说，多年来积累了大量的项目和产品，但是没法有效的集成在一起，同时为用户提供包括软件、硬件和技术服务以及嵌入式产品等。集团在如何整合现有的资源和数据整合方面的迫切需求，也需要一个智能化的集成平台来完成，所

15、以如何设计、开发一个智能化的集成平台，为用户提供独特、灵活、可靠的技术支持，使集团在住宅智能化领域获得持续的竞争优势。1.2 研究意义 我们在企业级应用软件开发中经常会遇到这样的问题，客户让我们开发一套业务系统，碰到的第一个用户需求就是用户期望在使用业务系统的过程中，其使用权限可以通过权限控制来设置，因此我们有必要在系统中录入客户的组织信息，提供一套在组织范围内的授权机制，于是我们得到了两个需求，即在系统中提供组织管理（隐式需求）和权限管理（显式需求）。还有一些需求，如一些业务的处理涉及到流程，流程有时是变化的；由业务产生的数据需要以不同的报表样式查看；多年的业务数据希望可以通过分析能够改进生

16、产经营等。我们最后发现，几乎所有的业务系统都有这样的需求：组织管理、权限管理、工作流、报表、综合查询和商业智能等。这成了业务系统的公共需求。如果我们提供一套统一的解决方案满足这些需求，剩下的研发工作就只需要关心业务层面了。这不仅缩减了开发工期，而且节约了开发成本，也解决了维护和升级问题。企业级应用软件一般包含一个应用平台，平台是应用软件的基础。一套应用软件的成功，很大一部分与其运行的平台有关，平台为其运行的业务系统提供底层支持。一个平台一般包含四个方面的应用：基础业务框架（含平台框架、组织、权限）、工作流、报表、综合查询和商业智能（提供基于平台基础上的统一编码处理机制，使各业务数据基于平台集成

17、）。平台将为我们的项目开发或产品开发提供完备的支持，将为我们的开发工作提供灵活多样性的配置，降低开发过程中的风险，促使开发工作的规范性和标准统一，也对我们技术的积累和技术产品路线的规划起到积极推动作用。而在智能建筑领域，实现智能建筑的两个共享和五项管理的功能1。1. 信息的共享；2. 设备资源共享；3. 集中监视、各个子系统联动和控制的管理；4. 通过信息的采集、处理、查询和建库的管理，实现整个平台的信息共享；5. 全局事件的决策管理；6. 各个虚拟专用配置、安全管理；7. 系统的运行、维护、管理和流程自动化管理。1.3 论文结构本文总共分为六章。第一章 介绍论文的背景和意义。第二章 智能建筑

18、集成平台的现状和分析，同时分析了相关的问题和概念。第三章 平台的整体架构分析，针对实际情况，对平台的分层模式进行分析，提出了平台的总体技术架构和功能架构，给出了平台的部署和组件设计。第四章 平台的详细设计，阐述了平台的分层技术细节、平台的类协作设计、数据库设计和界面设计，并简要介绍了平台用到的主要技术。第五章 系统的实际应用体验。第六章 总结本文的内容并对以后的工作方向做出了展望。1.4 本章小结本章介绍论文的背景和意义，并对论文研究的对象所存在的问题进行了一个总述，并对论文的整体结构进行了规划。第2章 建筑智能信息集成平台的现状2.1 国内外现状过去20年，计算机网络、无线通讯、传感网络、计

19、算网格，还有方兴未艾的普适通讯、普适智能空间、万维科学、Cyber Physical System（CPS）、物联网、物联社会网（CPSS）等，不仅深化了整个社会的信息化和网络化的进程，而且在极短的时间里，把我们带入了一个不同以往的物理空间，并将催生社会的巨大变革，改变传统的行业观念，这正是当今科技现状的本质与以往最大的不同之处2。在我们生活的复合空间里，许多传统上的人“软”的科学方法正成为“硬”的方法，同时许多“硬”的技术也在“软”化，以便适应对其日益增长的多样性、复杂性与智能化等要求。许多传统的大型企业已意识到必将到来的变化、除IBM之外，近来著名的通用电气公司GE也新组“智能平台”（In

20、telligent Platform）业务部门，开发智能平台，迎接即将到来的智能化产业。特别要指出的是，随着以SOA、SaaS、IaaS、PaaS等为特征的服务技术和系统不断成熟并向XaaS时代迈进，以及Google、百度、Facebook、人肉搜索、Crowdsourcing等以社会计算为主要手段的产业和现象的进步发展，新兴的智能产业也将迅速转战物理空间和传统的产业，引发“破坏性”的产业革命。智能信息集成在整合内外部系统资源、实施全程监控、提供决策信息等方面，特别适合行业高动态、高风险的特点，纵观国内外企业在智能化信息集成平台的整体水平，还存在着很多不足和问题，主要表现在以下几个方面3：第一

21、，我国在智能化的研究和实践方面起步较晚，同时也缺乏一些经典的产品，在世界范围内来讲，智能化也是一个很大的研究课题，无法形成统一的行业标准。第二，目前无论是本集团现有的智能化子系统，还是市面上存在的智能化子系统，开发方式各异，功能也各有特点，本身就存在着非常难以整合的缺点。第三，由于开发公司各异，现有的问题是由于一些保密性和专利性的问题，也比较难以开放，如何在这种情况下，把各个子系统集成在一个信息平台下面。2.2 存在问题2.2.1 缺乏全国性的权威组织我国自从“七五”国家重点科技攻关项目研究发展智能土木建筑领域以来，尚没有形成相应的政策、规范、标准，只是颁布了一些推动智能建筑发展的技术政策，颁

22、布了设计、布线、安防等实施措施，所以导致众多的智能土木建筑市场技术行为无章可循或者是无规可循。各职能部门管理不全面，造成了很杂乱的状态，智能土木建筑在我国尚处于刚刚起步的阶段，水平参差不齐，智能型建筑市场也比较混乱。我国的智能型建筑技术及其智能控制系统过分依赖 于国外，给了外商可乘之机。由于智能化建筑不是单一技术、单一设备产品, 而是多学科多专业多技术综合运用的整体建筑物业产品。它的技术发展必须要多个行业、多个部门的综合 协调同步发展, 需要全国统一计划、统一协调、统一对策, 而不是各部门、各行业、各环节“各自为战”、“互不协调”、“各自为政”。更不可“分封割据”打乱仗4。2.2.2 智能化建

23、筑技术产品还没有实现国产化智能化建筑技术发展要实现产业化，而不是仅看作一项应用技术。目前国内智能建筑市场仍由国外技术系统产品设备占主导，软件产品也大多参照国外。要大力扶持鼓励发展国产化的技术产品与软件系统, 建筑技术发展才可能形成国产化产业。当前, 不把智能化建筑作为一项产业发展, 就要“贻误时机”5。2.2.3 缺乏政府的扶持政策智能化建筑技术不同于传统技术领域。智能化建筑属新兴的高新技术领域,技术发展还 不成熟完善正处在变化极快之中。因此, 技术发展政策既需要有远见卓识的前瞻先进性, 更需要有深思熟虑的严谨准确性。历史实践已经证明; 政府的正确指导行为是技术发展的根本保障, 而不准确的指导

24、行为就会导致紊乱、滞后、误解、甚至失误。2.2.4 智能建筑相关项目管理不规范我国的建筑智能化经过十几年的发展，许多国内企业也自主开发了一些住宅小区智能产品，具有一批从事智能建筑的专业人员、从业人员，但是在项目管理、开发和实施中还是存在很多问题，比如项目的智能化需求不合理，片面追求高标准，造成浪费；工程质量、产品质量、验收不规范，造成不能正常运行；“重建轻管”较普通，智能化系统难以长期发挥作用；工程设计、施工、验收及产品标准化滞后工程应用，尚需完善；市场运作不规范。2.2.5 对软件尤其是信息集成软件缺乏重视国内许多单位，在实施智能化管理方案过程中，投入大量资金购买设备，配置专业养护人员，而对

25、软件却不屑于投资，软件的使用也是秘书或其他人员兼职了事。殊不知，在实施智能化的过程中软件是基础和核心，一套完整的信息化管理方案，无论硬件设施多么完美，缺乏软件的支持（确切说是支撑）其系统也不是一个成功的设计。而许多购买了软件部分的单位，又对系统缺乏有效的信息集成，导致很多重要的信息无法提取，使整个智能化事倍功半，无法达到预期效果6。2.2.6 智能子系统开发接口各异现在市面上做智能化信息集成的厂商很多，提供了很多相关的子产品，这就给后期集成尤其是项目分多期完成的时候造成了很大的困难，总线的标准不统一、开放性差、互操作困难，有时候还会造成重复建设，导致后期维护困难，造成人员和资金上的极大浪费7。

26、2.2.7 对现今的节能方面的考虑基本空白 随着社会的不断进步与科学技术的不断发展，现在人们越来越关心我们赖以生存的地球，世界上大多数国家也充分认识到了环境对我们人类发展的重要性，节能减排也是目前大多数国家正在采取的有力措施。家电节能是节能减排中的重要组成部分，其目的是促进实现科学用电，节约环保的和谐理想环境。如何在未来的智能建筑集成方面加大节能方面的投入和开发，是我们未来必须面对的重要课题8。2.3 相关概念和目标智能信息集成平台的目标是结合国内企业信息化现状，研究、开发面向企业的通用性智能信息集成平台。通过智能信息集成平台为行业管理、经营决策提供准确、完整、及时的分析数据，提高行业公司对市

27、场的快速反应能力，提高集团持续的市场竞争力和服务质量，提供多种多样的具有开放式和可扩展结构的应用程序和服务，将现有基础设施进行统一化和标准化，从而提升生产的灵活性和实时响应能力，为用户提供最先进最完善的解决方案。1、建立规范的基础构件管理体系通过可视化界面对基础构件、业务构件和接口构件等进行管理，灵活的配置使之适用于多种行业的需要，并对基础数据的建立和维护都有规范的流程控制，通过规范的配置结构来规范整个管理体系，降低这个行业的管理成本。2、建立完整的业务流程控制 对行业的业务流程控制进行标准化控制，在平台对业务流程进行规范以及对生成的数据进行汇总，解决了各个行业公司之间数据松散、大量的信息孤岛

28、问题。同时，数据能够相对稳定的反应行业历史变化。3、建立强大的统计报表功能智能信息集成平台是在控制系统和多种外挂系统和服务的基础上建立起来的，可以结合少量的手工录入数据，进一步对数据进行处理和应用，实现数据共享和行业管理、行业统计报表自动、快速生成, 使得行业管理人员从手工收集数据、制作报表等繁重的工作中解放出来，有更多的精力对数据进行分析，及时发现存在的问题，优化行业生产能力，提高生产管理水平和效率。同时也可以自由定制各种特色报表供企业进行行业分析。4、建立灵活的数据字典管理功能通过建立数据字典管理系统，用户可以在数据字典中灵活的自行定义业务所需的关键数据库结构，这样可以减少系统二次开发量、

29、实现系统的灵活应用。5、建立灵活的控制系统 该平台要有多样化的控制器，I/O和编程工具可供选择，易于集成、可扩展、具有强大的功能和可靠性，还可以支持多平台和第三方接口。帮助用户降低成本，提高效率并增强其盈利能力。2.4 本章小结本章就智能建筑信息集成平台的国内外现状进行了深入的分析，就目前存在的问题和不足进行了一定的分析，从而使信息集成平台开发的价值和意义突显出来，为下文进行系统的分析、研究和开发做了必要的铺垫，介绍了平台开发的一些基本概念和目标。第3章 智能建筑信息集成平台系统架构设计3.1 平台总体分层模式3.1.1 整体介绍这里的总体分层模式指的是纵向层次模式。采用普通的分层架构，为了考

30、虑到服务层针对Winform类型表示层的扩展项目的远程调用支持，表示层和服务逻辑层中间加了服务工厂对象层，用于不同类型的(主要是本地调用，远程Remoting，远程调用)服务对象实例的创建9 10。如图3.1所示：图 3.1 智能建筑信息集成平台分层架构表示层：人机用户界面层。服务对象工厂层：用于创建服务逻辑对象实例，和服务逻辑层统简称为服务层。有本地对象调用工厂，远程对象调用工厂的实现。服务逻辑层：业务逻辑的接口和逻辑的实现，供界面层调用。数据持久层：业务对象持久化到数据库的操作层。业务对象实体层：供以上各个层次间传递使用。3.1.2 表示层（UI）从Windows的角度来说，它们就是用户能

31、操作的图形用户界面。在这一层中，包括了决定用户界面的外观、导航路径，以及如何解释用户输入的逻辑，同时也包括了操作服务器端控件的代码。在很多应用程序中，UI代码非常复杂，它必须要以一种非线性的方式来响应用户的清酒（控制用户如何点击控件，或是进入或离开窗体或页面是很困难的）。UI代码还必须与业务逻辑进行互操作来验证用户输入，或是做任何其他与业务相关的动作。基本上，UI层代码的目的就是为了接受用户的输入，然后提供给服务逻辑层，在服务逻辑层中用户的服务得到验证、处理或是操作。然后UI代码必须把从服务逻辑层得到的结果显示出来，以响应用户。用户的数据是否是正确的？是否错误了，哪里错误了？等等。对于.NET

32、来说，UI代码几乎都是事件驱动的。Windows Form代码都是在用户键入和点击窗体的时候用来响应事件的，而Web Form代码都是在浏览器把用户的动作返回Web服务器的时候响应事件的。尽管Windows Forms和Web Forms技术都大量使用了对象，但是其中UI模块的代码都不是面向object的，而是过程化和基于事件的。这就是说，创建能支持特定类型UI的框架和可重用的组件是很有价值的一件事情。在创建Windows Forms的UI的时候，开发人员可以使用可视化的继承类和其他面向对象的技术来简化窗体的创建。在创建Web Forms的UI的时候，开发人员可以使用ASP.NET的用户控件和

33、定制的服务器控件来提供可以简化页面开发工作量的可重用组件11。如图3.2所示，是人员模块的界面设计。图 3.2 人员模块的界面设计3.1.3 服务层服务层包括服务对象工厂层和服务逻辑层，包含了所有的业务规则、数据验证、数据操作、数据处理和应用程序的安全性。微软业务逻辑的一个定义是这样的：“一个包含数据验证、登录确认、数据查找、策略方针和算法转换的集合，它制定了企业做业务的方式。”服务逻辑必须存在于UI代码之外的一个独立层中，即使如果你想把一些重复的业务逻辑放在UI代码中来提供一些更丰富的用户体验的话，服务层也一定要包含所有的业务逻辑，因为这是进行中央控制和提供可维护唯一的一个地方。必须要意识到

34、，应用程序通常用以下几种不同的方法使用服务逻辑。大多数应用程序都存在一些有用户交互性的过程，例如用户可以用来查看数据或向系统输入数据的窗体。同时，大多数应用程序还有一些非常没有交互性的过程，例如上报发票、补充库存、或者计算养老保险等费用。在理想的状况下，当用户直接向应用程序输入数据的时候，应该以一种非常丰富和交互式的方式使用服务逻辑层。例如，用户在输入生产订单的时候，他（她）希望订单的数据验证、看板计算和订单小结应该在数据输入的同时完成。这暗示这服务层可以被物理的部署在客户机或Web服务器上来提供用户所期望的高级别的交互性。另一方面，为了提供非交互性的过程，服务逻辑层则经常需要被部署在应用服务

35、器上，或者尽可能的靠近数据库的服务器。例如，交通罚单的计算可能包含大量的数据库查找和相当复杂的业务处理。这些过程应该发生在服务器的后台，而不是用户的桌面电脑。3.1.4 数据持久层对象持久层是负责数据在一个持久的数据存储中物理的创建、提取、更新和删除数据，同时，还封装并包含所有的数据访问技术（如ADO.NET）、数据库和数据结构的信息。服务层触发数据持久层，但是这一层经常包括额外的逻辑来验证数据和数据与其他数据的关系。有时候，这是根据一个数据库真正的关系数据建模；其他时候，是从外部应用程序的业务逻辑的应用。这就是说对象持久层通常也包括业务逻辑，而这些业务逻辑也是现在的服务层。这一次复制不可避免

36、，因为关系数据库需要保证关系的完整性；这是另一种形式的业务逻辑。数据访问机制通常是以一套服务的形式被实现出来的，每一个服务都是一个被业务逻辑调用的过程来提取、插入、更新或删除数据的。尽管这些服务经常是以对象来构建出来的，但是要知道高效的对象持久层设计实际上都是非常过程化的。试图强迫更面向对象的设计来访问关系数据库通常会造成更大的复杂性或者更低的性能。所以，最好的办法是把数据访问实现成一套方法，然后把它们封装在对象中保持它们的组织逻辑性12。有时候，数据访问要更复杂一点，提供更加抽象、或者甚至是原数据驱动的方法去处理数据。在这种情况下，数据访问层包含了大量的复杂代码提供抽象数据访问数据库。本平台

37、主要使用了ADO.NET，但是也可以使用LINQ，本平台也给出了部分实现。另一个数据访问层常见的角色是提供在面向对象业务逻辑和数据存储中的关系数据型数据之间的映射。一个良好的面向对象模型几乎肯定不会同时也是一个好的关系数据库模型。对象经常包含来自多张表中的数据，或者可能来自多个数据库中；或者反过来说，模型中的多个对象可以存在于一张数据表中。这种从关系模型的表中获取数据并把数据放进面向对象模型中的过程叫做对象-关系模型（ORM），本平台使用了ibatis来实现。3.2 总体技术架构3.2.1 整体架构介绍结合技术预研成果，考虑到平台的稳定性，兼容性，项目风险管理，企业信息化桌面应用软件的普及程度

38、等因素，平台采用.NET 3.5 的winform(桌面应用开发)和webform(ASP.NET)开发技术实现，其中winform表示层和服务层之间的通讯采用WCF远程对象调用技术实现而不是本地对象的引用，webform对服务层逻辑的调用采用本地对象调用方式。从整体架构上看，如3.1所介绍一样，分为五层，层与层之间，可直接基于接口来进行调用（local），也可以通过被调用层所暴露的Service来进行通信（remote，distributed），应根据不同的情况来灵活确定。比如，对于表示层与服务层的通信，如果系统是C/S架构，用户的客户端只是做简单的数据显示，所有的业务逻辑全部放在服务器端的

39、服务层来进行，则客户端的表示层通过访问服务层所暴露出的Service来进行通信；对于B/S架构来说，如果系统的业务复杂，数据访问量很大，考虑到负载均衡、备份等因素，可能将三层分别部署在不同的服务器上，同时各层也有不同的集群策略，此时，表示层与服务层间的通信，也是通过Service来进行，相反，如果系统的业务规模较小，三层均部署在同一台服务器上，则表示层与服务层之间直接通过接口进行调用。同样，对于服务层与数据持久层的之间的通信也是如此14。结合分层架构，给出平台技术架构框图，如图3.3所示：图 3.3 智能建筑信息集成平台技术架构框图3.2.2 表示层技术架构对于表示层，不包含任何业务逻辑，仅仅

40、负责界面显示，因此，不论是基于Windows Presentation Foundation、WinForm，还是基于ASP.NET来实现，在服务层上都有统一的访问接口。表示层包含了界面显示的元素及简单的显示逻辑，如图3.4所示：图 3.4 表示层界面显示元素逻辑图这里，上图及架构图中均只描述了常用的几种实现，由服务层提供统一的访问接口，因此，对于其他形式的界面显示层的实现（如手持终端应用）也是类似的设计。他们应该满足以下目标： 1. 根据项目的需要可以选择B/S、C/S或SmartClient的实现；2. 能够对界面风格进行统一管理；3. 界面能够支持国际化与本地化；表示层可以使用如下技术组

41、件：1. Microsoft Composite UI Application Block，用于SmartClient界面的开发；2. Microsoft User Interaction Process Application Block，可支持WinForm、SmartClient、ASP.NET程序的开发，用于将界面与显示逻辑、用户交互、界面流向等分离；3. DotNetNuke，开源的Web应用程序开发框架；4. WPF，微软新一代界面显示技术，B/S与C/S的融合；在该平台中，用cookie存储身份认证信息（比如登录用户ID）。更复杂的用户信息描述采用xml格式字符串或者JSON来描

42、述，比如，用户ID、姓名、所在岗位ID，岗位名称。在B/S实现中，ASP.NET WebForm直接调用服务层的业务逻辑组件，但Form与服务层逻辑的交互要求必须传递可序列化对象，以便后期Winform+WCF方式开发能够对业务逻辑进行的复用和便于搭建统一服务逻辑组件中心，方便客户端（WebForm、Winform和WPF）进行服务逻辑模块的统一调用。WebForm采用CodeBehind方式进行页面开发。主要是方便页面间模块化和界面逻辑间的解耦，并利用ASP.NET本身特性方便实现web页面插件化（热插拔）。3.2.3 服务层技术架构对于服务层，封装了系统的业务逻辑，并提供了供外部访问的接口

43、，包括API形式的调用接口（用于同一进程中的local调用），以及基于WCF暴露给外部的Service（用于分布式的remote调用）。对于暴露给外部的Service，有的只提供给表示层，有的只提供给外部系统；另外还有一些Service可以同时提供给表示层及外部系统，但提供的方式和策略是不同的，比如，考虑到网络环境及安全性要求等因素，对于不同的访问请求需要有不同的策略，对于表示层的请求，可以以二进制的SOAP格式通过TCP协议进行通信，而对于外部系统的请求，则以SOAP通过HTTPS进行通信。这种策略的定义，在WCF中是很容易配置的15。对于服务层所需要的数据，来源于两方面，一是来源于数据持久

44、层，二是来源于外部系统。3.2.4 数据持久层技术架构对于数据持久层，封装了对各种数据源的访问操作，提供了对底层的数据源（多种关系型数据库以及CVS、Excel、及其他各种文件等）的统一访问接口，屏蔽不同数据源之间的差异，并且提供O/R-Mapping层，根据不同项目、不同模块的需要，返回给服务层的数据，可以是业务对象形式（在O/R-Mapping层进行转换），也可以是基于表结构的DataReader、DataSet等对象。数据持久层对外提供的访问接口，也包括API形式的调用接口（用于同一进程中的local调用，即服务层与数据持久层部署在同一台服务器上，被业务逻辑层直接调用），以及基于WCF暴

45、露给外部的Service（用于分布式的remote调用，即服务层与数据持久层部署在不同的服务器上，供服务层调用）16。数据持久层可以再细分为两个层面，一层是用来进行O/R-Mapping，另一层是用来屏蔽数据源（多种关系型数据库以及CVS、Excel、及其他各种文件等）之间的差异，如架构设计图中数据持久层的设计所示。目前现有的一些数据访问层组件，在实现上将上述提到的两层结合在一起进行了实现，如NHibernate，既实现了O/R-Mapping，同时也屏蔽了多种数据库之间的差异。另外一些数据访问层组件，如微软的Data Access Application Block，提供了数据访问的统一接口

46、，屏蔽了数据库的差异性，但并未实现O/R-Mapping。数据访问层可选择组件：1. Microsoft Data Access Application Block2. NHibernate3. iBatis.NET3.2.5 基础组件架构3.2.5.1 异常管理模块可选用构件：Microsoft Exception Handling Application BlockMicrosoft Exception Handling Application Block提供异常处理的API以及异常处理策略的配置界面，开发人员在调用API时使用相关的异常处理策略名称，而具体处理异常的策略的内容可在任意时刻

47、（包括系统运行时）进行编辑，使得异常处理可实现运行时的个性化定制，根据客户不同的需求来编辑不同的处理策略。图3.5是Microsoft Exception Handling Application Block的设计图： 图 3.5Microsoft Exception Handling Application Block的设计图结合AOP及WCF的思想及实现，通过与WCF类似的编程方式可将Microsoft Exception Handling Application Block在AOP方面更进一步，使得开发人员在编码时完全不用考虑异常的处理（即不用去写具体的try.catch等语句）。3.2.5.2 日志管理模块1. 日志管理的设计需要满足以下目标：2. 支持多种层次的日志级别3. 同步/异步的方式都要支持4. 支持多种输出形式，如文件、数据库、控制台、Email等5. 简单易用的管理界面6. 提供统一