.Net桌面系统架构设计

面临问题

1.人机交互和用户界面不够友好

2.个性化UI需求

3.没有一套便捷的通用数据导入导出高效解决方案

4.系统安装包太大，应用部署和升级发布麻烦，版本控制较乱

5.不支持二次开发，系统模块化、组件化较差，扩展性不太好，应对业务变化不够灵活

系统技术总体架构——参考技术架构

此版本的C/S系统，基于.NET Framework 4.0，

Windows技术平台下的富客户端应用；

采用自主的模块化可扩展的开发框架；

O/R Mapping组件IBatis.Net

数据访问支持Access、MS SQL Server、MySQL、Oracle主流数据库

应用开发模型使用Prism开发框架，UI层使用MVVM开发模式

技术框架基础组件：WPF,Enterprise Library，Unity，Prism，MahApps.Metro，NPOI等

开发平台逻辑架构

开发平台逻辑架构——总体介绍

1.框架基础服务

2.表现层（UI）

3.领域层（业务逻辑）

4.数据服务层（数据访问）

开发平台使用典型的分层架构是三层架构，即自上向下依次是表现层（ UI 层）、领域层（业务逻辑层）和数据服务层。这种经典架构经历了时间的考验和实践的多次检验，被认为是合理、有效的分层设计。开发平台逻辑分层架构是可以分层部署的软件架构，可以把逻辑上独立的软件层次部署到不同的服务器上,实现软件层次物理上独立。

例如：业务层可以是一组部署在本地的DLL程序集，未来也可以使用中间件服务器（APP Server）方便进行集群来扩展应用，不同层服务提供者与消费者之间不直接调用，而是通过依赖注入（ Dependency Injection ）的方式，实现层之间松耦合。

总体介绍—框架基础服务层

1.框架基础服务层——基础服务需要为框架中所有层的组件提供服务。

IOC容器、用户认证、用户权限控制、安全服务、日志、缓存、Utilities库、配置管理、消息管理、网络连接监测、异常管理、元数据、数据验证、数据同步、配置管理、加/解密、访问控制、定时任务、打印、文件传输、web服务等

框架基础服务——基础服务需要为框架中所有层提供服务,主要由以下几个部分组成：

元数据（Metadata）描述数据的数据，对数据及信息资源的描述性信息，用于表单生成、报表设计等。

用户认证（Authentication）用来唯一标识一个用户身份的过程，当用户试图建立与应用程序或服务的连接时，需要提供他的身份证明。

用户授权（权限管理）用于管理经过认证的用户是否有权限访问某个操作或资源。

网络连接监测 为系统提供基本网络连接服务，可监测网络状态使系统以无缝的方式切换线模式和离线模式。

数据验证 客户端数据验证是为了验证数据的长度、类型等是否符合输入要求，服务器端验证则是验证输入数据是否与数据库中已存在的数据匹配

定时任务 系统支持定时器框架来实现定时任务，如邮件自动提醒功能、报表数据分发等功能

加密解密是为了保证系统安全访问提供数据服务，可支持本地数据加密解密等。

审计（Auditing）是出于安全的目的跟踪用户在应用程序中的业务操作活动，并记录业务活动的类型、数据、时间以及用户

文件传输 提供远程文件传输的功能

日志是在任何应用程序中的基本工具，应用程序利用日志记录应用程序与用户交互时的事件。

缓存（Caching）是一种基本的工具用于将经常被应用程序访问的数据保留，预备下一次被应用程序读取。也用于保留需要花费许多时间或者资源创建、获取和传递的对象。

Utilities库以服务的方式提供Utilities全局库供其它所有层访问

配置管理提供简单有效对应用程序配置数据的读写访问。

打印服务 提供实现系统打印功能的基本服务。

Web 服务 使系统可方便访问外部Web Service API。

多语言使用资源文件的方式提供多语言支持

统一异常管理提供对程序异常的统一封装。

基础服务层为系统提供一个IOC容器，不同层之间和服务提供者与使用者之间不直接引用，而是通过依赖注入的方式，实现松耦合。IOC容器支持系统事件发布和订阅机制，使不同模块之间减少耦合，还可以支持AOP方面的扩展。

2.表现层（UI）

——表现层在于数据的收集和展现，关注重要的操作易用性、简洁美观性，但该层并不包括相应的业务逻辑，业务逻辑由逻辑层封装。

表现层使用SCSF2010提供可扩展的框架，可视元素（UI控件）与控制它们的应用程序完全独立，可视元素可以自由组合，用以提供复杂而灵活的用户UI。不同UI模块之间采用事件发布/订阅来实现相互通信，采用基于弱类型引用的共享状态和状态保持来实现数据共享。

在表现层使用MVC/P模式来实现模型、视图、控制器逻辑代码分离。 表现层（Presentation）包含富客户端程序用以响应用户输入输出，同时包含移动端、Web端及可扩展插件（Add In），关注于数据的收集和展现，实现操作易用性、简洁美观性。

1.表现层SCSF2010框架

Prism框架（采用SCSF2010框架进行开发，该框架可提供一个开发环境能很好的隐藏复杂度和提高生产力，通过高度抽象和关注点的分离，开发人员能够关注于业务逻辑提高基础框架代码的复用。

Shell Applicaiton是Prism应用程序的主窗口，是启动程序最外部的容器。Shell From和Module模块直接松耦合，模块根据目录或配置文件动态实现装置。

根据业务需要，系统平台应用程序由多个Module（DLLs）组合而成。每个Module包含了包含可视化的View组件和非可视化的Service和用户业务逻辑的封装组件。

在每个模块内部本身代码来控制把本模块相关可视化内容添加到Shell中的导航区域和工作区域。

可视元素可以自由组合，提供复杂而灵活的用户UI Ø不同模块之间通过物理隔离（独立DLL文件）消除耦合。

不同模块之间在代码层面也是松耦合的关系，采用（Event Broker）事件发布/订阅来实现相互通信，采用基于弱类型引用的共享状态和状态保持来实现数据共享。模块之间不需要代码直接调用/引用。

2.应用布局设计

顶部是区域为公共菜单和工具栏区域。左侧是功能模块导航区域，右侧部分为主工作区域。

3.UI模块化设计

UI模块内部使用MVVM模式，定义一个接口负责View Model和View之间的通信，使代码职责分离，将界面独立于业务逻辑，让界面和业务逻辑松散的耦合起来。

使用IOC容器把Application Service注入到Presenter中，Presenter层使用Application Service 获取Domain层数据。

Domain层通过相对应的Domain Repository调用Data Service从数据持久层中获取数据。

4.菜单导航

3.领域层

——主要提供给表现层调用，负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。

领域服务 主要是向外界提供访问业务组件的入口点，它作为一种服务存在

业务实体对象用于代表真实世界中的对象，一般使用数据结构来表示、XML流或者是用户自定义的面向对象的类，业务实体用来在各层之间以及各组件之间进行通信和传递数据

业务外观层集中处理业务流程，涉及多个业务步骤以及集中的事务处理，通过组合和调用多个业务组件来完成一个特定的业务处理

系统集成模块用来集成第三方应用，和对外提供标准API

领域层——主要提供给表现层调用，负责系统领域业务的处理，负责逻辑性数据的生成、处理及转换。领域层包括领域服务层、应用程序层、应用程序外观层、系统集成模块。

根据系统需要还可以在此层中部署实现一个Web Service服务层以支持移动端、Web端或第三方AddIn插件使用。

领域层由上到下包括：

1.应用程序外观层（ Application Service Façade ）

根据系统需要应用程序层中还应该包含应用程序外观层（Application Service Façade）的用意在于为上层（表现层）提供粗粒度的调用接口。本身不处理任何业务逻辑，主要是将一个上层请求委派给一个或多个 Application Service 进行处理。

提供了一组功能性Open API来支持第三方扩展。

2.应用程序服务层（Application Data Service)

应用程序服务层（Application Data Service)中从应用程序级别定义并实现了平台应用程序提供API（基于程序功能或任务）接口

应用程序服务层还包含一个远程访问代理（Remote Service Proxy），使应用程序可以访问远程和本地服务无缝切换

不包含任何业务逻辑和业务状态对象。

本层还提供Data Adapter/Converter功能，可以把跨层基础组件中定义的Data Contract对象转换为领域服务层中Domain对象。

3.领域服务层（Domain Model Layer)

领域实体对象用于代表真实世界中的对象，一般使用数据结构来表示，是用户自定义的面向对象的类

领域服务和服务接口—向外界提供访问业务组件的入口点，它作为一种服务存在。

领域值对象

领域Repository接口定义，领域服务通过领域Repository与数据持久层通信。

领域层关注实现系统中相对稳定和核心的业务逻辑，

领域层只关注与业务，不考虑数据访问相关技术性的内容。

领域服务层还提供基于领域级别的数据事务支持。

4.系统集成模块（System Integration）

基于平台开放API的开放应用开发和接入环境以及为业务应用提供内容和信息的服务，包括：开放API、数据订阅分发服务

把外部系统集成到本数据采集平台中，使外部系统和本平台融为一体，包括应用集成、服务集成、数据集成。

4.数据服务层

——抽象为所有数据存取、更新和设定操作的存取点，负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。

数据服务层定义了数据服务所使用的数据模型对象（Data Model）

提供独立于底层数据源的标准的可重用的数据读写接口，通过此接口可以以统一的方式访问各种不同类型的数据库、文件系统、第三方应用程序提供的服务。

O/R 数据库存取中间件（ NHibernate、ADO Entity等）

提供服务代理引擎（Service Agents）实现访问第三方应用提供服务（通常是Web Service）

数据服务层（Infrastructure Layer for Data Persistence）定义统一标准与数据库无关的数据访问接口和数据对象模型，可以以统一的方式访问各种类型数据、本地文件系统和本地缓存系统。

数据服务层抽象为所有数据存取、更新和设定操作的存取点，负责与数据源的交互，即数据的插入、删除、修改以及从数据库中读出数据等操作。

Domain的Repository对象和Data Service接口对上层公开。数据库访问层为多个单独DLLs文件，可分别部署在服务器端和客户端。

1.数据提交与同步

2.Domain Repository

Domain Repository层通过调用Data Service接口的方式访问数据数据源

3.Data Service

Data Service提供一组独立于底层数据源的可对标准的可重用的读写接口，使用统一的标准中调用不同种类数据库访问组件（O/RMapping）来实现访问多种数据源。

4.将对象映射到关系库（O/R Mapping 与Data Model）

定义了数据服务所使用的数据模型对象（Data Model），使用第三方O/R Mapping工具，提供数据传输对象（DTO）到Data Model的转换功能。

5.Service Agents

为了方便与第三方系统集成，同时提供服务代理引擎实现访问第三方应用程序服务。支持用户使用Plug In插件的方式扩展数据服务层功能，用户可以根据需要实现自己个性化数据服务接口，来实现为平台提供用户数据

开发平台架构优势

1.提供一个针对企业级智能客户端应用的公共开发体系结构，提供成熟的模块化方案，支持模块化应用程序开发，允许构建由各个具有协作关系的独立模块组合成的复杂应用，并且在运行时对各个模块进行动态管理，使系统可以拆分成多个部分来对立开发，适合较大项目多个团队合作开发，方便整合。

2.通过将前端UI和后台逻辑完全分离（包括事件），让开发团队每成员都能专注于自己的工作，使得核心开发人员能够关注于业务逻辑，让不熟悉业务的UI人员也可以方便的参与开发，可以使用测试驱动开发，方便编写单元测试，保证系统稳定性，对于大型开发团队来说，能够提高生产率，缩短产品开发周期。

3.高度可扩展性和灵活性，由于逻辑分组的组件和多层体系结构带来的解耦，可以很容易地添加新的功能，而不会影响太多对整个系统。

4.功能模块封装成物理独立DLL文件，通过配置服务的方式接入系统，可以实现功能插件的“热插拔”。还可以提供外部服务的动态接入（通常是通过WebService）。

5.系统稳定性，单独的层升级或是改变不影响其他的层，依赖接口的实现能很好的减弱所有的层之间的单独改变而不怎么影响其他层。例如，如果保持接口不变，我们能单独的更新或替换任何层的实现，而不需要影响整个系统，例如，起初我们主要使用Windows Form,现在我们主要使用WPF，如果我们的原始系统是通过层架构来实现的话，我们就只需要把客户端从Windows Form更新成WPF而不需要改变服务层。

6.对于开发来说比较友好和高效层的解耦是逻辑软件组件组的主要功能，他们对于软件开发来说都非常的友好和高效，每一层可以被单独分配到一个团队专攻特定的功能区域；一个专业团队可以处理相关的任务更有效。

7.更好的可重用性，基础框架代码可复用，这是由于部分的逻辑分组，层与层之间的松散耦合。松散耦合的组件通常是在更一般的方式实现的，因此他们可以通过更多的其他应用程序中重复使用，增强编码生产效率。（组件重用性，API）

8.系统安全性，包括身份认证、授权、数据安全（访问、传输、存储）等。能够保障本地的潜在机密信息的安全，对于整个系统更好的和更精细的安全控制。我们能根据每层的安全需求不同而进行不同的安全控制。

9.系统部署方便性，提供版本监测及系统自动升级，易于部署和配置。

10.系统可扩展性，支持二次开发，页面自动生成，（UI、Addin、服务）在基于框架平台高度可复用和可扩展的基础上，以非常容易的支持二次开发，只要遵循相同的接口和协议，就可在框架平台进行二次开发。

系统基本组件设计——通用数据导入/导出组件

数据导入采用界面配置导入模板的方式配置导入信息,方便用户配置和配置信息的重复使用

通过Excel Manager 获取导入Excel文件信息

通过Import Manager设置需要导入的业务模型信息和保存导出配置

Import Config通过Excel文件信息和业务模型项进行映射后生成相应的业务模型数据,设置提交数据校验字段和数据冲突处理后,提交到相应的服务去做入库校验和入库处理 数据入库失败回滚当前的操作并提示错误信息供用户修改导入模型或导入Excel文件信息

导入数据校验模式

通过设置数据校验字段和数据冲突处理模式可以在入库时对当前数据库中的数据和导入数据发生冲突时进行处理

全覆盖模式:删除当前井筒的当前业务项所有数据后导入当前数据

更新模式:可以通过校验字段检验出已经存在的业务数据.然后采用两种解决方法.

全部更新:删除当前井筒已经存在的业务数据后导入当前数据

部分更新:删除当前数据中的已经存在的业务数据后导入当前数据

数据导出

数据导出采用界面配置导入模板的方式配置导入信息,方便用户配置和配置信息的重复使用

通过Export Manager获取和保存导入配置

Export Config通过获取业务模型设置Excel填充项并调用Export Manager保存导入配置信息.

通过Excel Manager 获取Export Config的配置信息向与业务模型对应服务发出数据请求,带数据返回后导出数据为Excel文件

系统基本组件设计——量纲组件

采集客户端系统提供统一量纲系统服务，也可以集成外部提供量纲服务。

码表管理组件

平台同时可以使用由数据中心统一管理的系统码表和自定义的个性化码表系统，同时提供一套基于XML描述的数据映射机制，采集客户端向数据中心提交数据时，必须把数据中使用的数据码表映射到系统数据码表。

应用个性化组件

不同用户根据需要UI定制，使用符合自己使用习惯和业务需求的UI操作界面。

在用户使用过程中系统会记录登录用户的操作习惯，记录用户UI相关数据、包括窗体位置、窗体大小、最经常使用的功能、最近录入数据等的设置，当用户下次登录系统自动为用户加载这些设置，方便用户操作。

数据访问组件

数据服务层定义统一标准与数据库无关的数据访问接口和数据对象模型，可以以统一的方式访问各种类型数据、本地文件系统和本地缓存系统，为了方便与第三方系统集成，同时提供服务代理引擎实现访问第三方应用程序服务（通常是Web Service服务）。

数据持久化存储支持数据源：

关系数据库：基于配置的形式通过O/R Mapping来支持各种主流关系数据库（MySql、Oracle、MSSql等）。

实时数据库：支持对实时数据库的只读访问。

文件服务器或文件系统：系统可以既可以本地文件，也可以访问远程文件服务器上文件，文件包括结构化的文件（例如：Access、SQLite等基于文件的数据库）和非结构化大文件（数据文件、流文件、图片、文档等二进制文件）。

关系数据+文件系统：把文件位置索引等文件元数据信息存储到关系数据库，文件存储到文件系统，由系统提供对文件的访问。

对象数据库和文档数据库：支持使用流行对象数据库和文档数据库进行数据存储。

第三方数据服务：支持通过XML SOAP访问外部数据服务。

系统基本组件设计——应用集成组件

1.是基于平台开放API的开放应用开发和接入环境以及为业务应用提供内容和信息的服务，

开放API

数据订阅分发服务

2.把外部系统集成到本数据采集平台中，使外部系统和本平台融为一体

包括应用集成

服务集成

数据集成。

3.系统平台兼顾融合和特性和开放的特性。支持内容融合、支持多来源，多形态的内容接入分发。同时也支持应用融合，提供统一的与第三方应用融合的解决方案。

应用易接入

分层的平台架构

开放的API，面向应用屏蔽网络、系统平台和多终端接入的差异性和复杂性。

基于SOA架构，服务可集成，服务易重用，简化应用间的服务交互。

资源共享化，数据资源共享。

人机交互及用户友好性

人机交互友好，用户数据录入便捷。简化用户工作，在尽可能降低录入出错率的情况下完成数据录入。

除了使用表单录入数据外，系统可以在数据列表中提供类似于填表式的数据编辑和录入功能，以方便处理大量数据。

尽量减少用户输入，同样的信息在多处都需要时，系统可以自动复制信息，用户可以不输入使用系统提供的缺省值。

系统应该及时为用户提供帮助和反馈信息，如当鼠标移动到输入框上，提示用户需要输入的内容、格式等。

提供错误检测和修改方法，系统应该具备简单的恢复功能，提供恢复以前的数据项。还需要数据检测防止错误数据录入，及时向用户提示出错信息。

提供临时状态保存的功能，用户可以暂时退出保存当前状态。

系统简单部署自动升级

多语言支持

一、系统数据模型中相关码表需要提供多语言支持，对于不同的语言提供相对应的码表数据,这部分需要数据模型进行相应的扩展，码表服务层设计支撑模型的扩展。

二、应用程序本身多语言支持

应用程序UI中涉及到的标题、文字以及信息提示框等文本信息多语言支持。使用不同资源文件的方式存储多语言的文本内容。

应用程序中日期类型数据多语言支持，系统内部使用统一日期格式进行存储，然后根据不同语言对应的系统区域设置，系统自动选择需要显示的日期格式。例如：针对日期‎数据“2015/1/30”，根据不同区域设置，中国可以显示成 “2015‎年‎1‎月‎30‎日”，美国设置显示成“Jan 30，2015”，英国设置显示为“30 Jan，2015”

应用程序中时间类型和时区支持，如果需要可以根据系统区域设置中对应的时区进行显示。根据系统需要可以在系统中存储UTC（通用协调时）时间，根据系统所在区域设置显示系统区域所在时区的时间。

数值类型数据也需要按区域设置指定的格式进行显示，不同语言、不同区域设置中数值格式也有所区别，系统根据当前区域设置，转换成合适的格式进行显示。输入录入方面也需要考虑显示格式的差异性。 例如：英文数值“56.23”，而法语中是“56，23”，不同语言之间数字显示有差异，根据系统区域设置，自动转换成需要显示的数值格式。