件开发架构----前台
概述
模块化、插件化软件开发，首先需要确定什么是模块化，什么是插件化。
模块定义
词典中解释为“家具或建筑物里的一个可重用的标准单元”
在程序设计中，解释为完成某一功能所需的一段程序或子程序；或指能由编译程序、装配程序等处理的独立程序单位；或指大型软件系统的一部分。
模块,又称构件,是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。它具有两个基本的特征：外部特征和内部特征。外部特征是指模块跟外部环境联系的接口（即其他模块或程序调用该模块的方式，包括有输入输出参数、引用的全局变量）和模块的功能；内部特征是指模块的内部环境具有的特点（即该模块的局部数据和程序代码）。
插件定义
插件是一种遵循一定规范的应用程序接口编写出来的程序，是一个可以嵌入到另外一个程序中运行的程序。如浏览器插件，为使浏览器能实现更强大的功能而开发的一些程序。
插件化其实就是模块化的一种表现形式。
如何做到模块化
模块的可重用范围和这个模块的领域（行业）有关，如果要提高模块的可重用性，方法是让这个模块属于更大的行业，而不是属于一个具体的小行业。模块属于哪个行业，可以用领域词汇来分析。
如何做到可扩展性
很多技术都可以提高扩展性，比如封装、高内聚松耦合原则、设计模式等等。设计的架构的时候应该考虑需要什么样的灵活性，要考虑以后会有哪些变化和扩展，然后决定架构的那些部分应该灵活。
提高可扩展性最有效的手段是设计模式，比如MFC能够灵活扩展的一个重要方面是应用了MVC模式。很多设计模式都利用了动态绑定的多态性来实现可扩展性，这个也可以看作是一个更抽象的模式，如果没有合适的设计模式，可以直接利用多态性和继承机制来构造灵活的结构。
微软在可扩展性上的步伐
托管可扩展性框架 (Managed Extensibility Framework 简称MEF) 是 .NET Framework 4 中新增的一个库，用于简化在部署后可由第三方进行扩展的可组合系统的设计。MEF 可使你的应用程序具有开放性，从而允许应用程序开发人员、框架编写者以及第三方扩展程序不断引入新功能。
在 Microsoft 的平台上，.NET Framework 自身内部包含组件模型和 System.Addin。同时存在若干种开源解决方案，包括 SharpDevelop 的 SODA 体系结构和“控制反转”容器（如 Castle Windsor、Structure Map 以及模式和实践的 Unity）。
既然目前已有这些方法，为何还要引入新事物？这是因为我们当前的所有解决方案对于常规第三方可扩展性都不理想。这些解决方案要么规模过大，不适合常规用途，要么需要主机或扩展开发人员一方完成过多工作。MEF 在最大程度上秉承了所有这些解决方案的优点，尝试解决刚才所提及的令人头痛的问题。
框架技术性建议
使用托管可扩展性框架构建整个程序，可以应用于开发环节的整个过程
架构说明
开发架构
【补充：2010-05-11：对mef进一步了解，发现核心层只保留契约就可以，其他的一切都模块，mef这种架构和以前的模式真的不一样了，刚开始应用感受到激情，也弄的我头大，真不知道微软怎么设计出来的】
具体细节
数据层
数据层，为整个软件开发的核心层，它包括：数据建模、产品应用技术界定、契约，数据层可分为公司层面的数据层，产品线层面的数据层。
针对数据层如果抽象的问题，建议核心数据层只抽象产品级别的，如：网络监控产品线有告警数据，资源产品线有资源数据，公共基础产品线有权限数据等。
每个产品线针对自己的产品，可以有自己的核心数据层，但必须继承于公司的核心数据层。
每个公司在软件开发的过程中积累或应用了一些核心技术，非公司级别的技术可以放到自己的核心层或服务层中。
产品线级别的相互调用，需要在核心层中以契约的形式定义下来。
应用层
应用层，包括业务逻辑和服务层两个方面
服务层
主要的功能是数据的访问与操作，服务于一个或多个模块，具有一定的通用性，如我们使用中间件制定的一些服务，使用webservice的一些通用接口，可以在服务层中体现。
业务逻辑：
业务逻辑就是模仿人类思考的过程，它不依赖于你的软件的存在而存在，相反，它先于你的软件存在并限制了你的软件应有的行为。
业务逻辑在系统架构中体现核心价值
通俗来讲：就是把业务需求按照一定的逻辑关系分成几块方面，比如先有什么然后有什么，最后有什么。这里强调要有逻辑性，不能乱来，否者业务无法正常进行。
业务逻辑的划分：
整个软件的功能，其实就是来完成某个业务逻辑，根据复杂程度可以划分为多个小的业务逻辑，最小的业务逻辑最好是能够使用自然语言描述，并能够量化且不好再分。
业务逻辑的可变性：
业务逻辑是可变的，环境不同，业务逻辑也会千变万化。整体设计上，应能适应这种变化，而付出的代价最小。
展现层
展现层包括视图和控制，由控制把视图和业务逻辑结合，由控制来划分不同的模块，由控制来组成不同的产品。
视图层实现界面。Wpf编程下，可以美工来实现，然后通过控制绑定到model层，在Winform下，需要使用mvp模式，把视图和model结合起来。
技术实现
托管扩展性框架
托管扩展性框架是什么？
托管扩展性框架（Managed Extensibility Framework，简称MEF），是.NET的一个新的类库，旨在促成应用和组件更大的重用。通过使用MEF，.NET应用将能从是静态编译的而变成可动态组合的。如果你正在建造可扩展的应用，可扩展的框架和应用扩展，那么MEF就可为你所用。
MEF实际上是个组合框架（composition framework），而且定位客户是“大的应用”极其大的应用，其中第一个客户大概就是Visual Studio本身。MEF提供的这些功能，
---不用装载程序集即可查询元数据
---可以静态地核实所有组件的依赖图和拒绝那些会造成系统处于不合法状态的组件
---契约适配器
---提供一套发现机制，用于定位和装载扩展
---允许附件元数据的标记设置，用于辅助查询和过滤
MEF 有几个基本核心概念：
可组合的部件（或简称“部件”）— 一个部件向其他部件提供服务，并使用其他部件提供的服务。MEF 中的部件可来自任何位置（应用程序内部或外部）；从 MEF 的角度来看，这并无区别。
导出 — 导出是部件提供的服务。某个部件提供一个导出时，称为该部件导出 该服务。例如，部件可以导出记录程序（对于 Visual Studio 而言则是导出编辑器扩展）。虽然大多数部件只提供一个导出，但也有部件可提供多个导出。
导入 — 导入是部件使用的服务。某个部件使用一个导入时，称为该部件导入 该服务。部件可导入一个服务（如记录程序），也可导入多个服务（如编辑器扩展）。
约定 — 约定是导出或导入的标识符。导出程序指定其提供的字符串约定，导入程序指定其需要的约定。MEF 从要导出和导入的类型派生约定名称，因此在大多数情况下，您不必考虑这一点。
组合 — 部件由 MEF 组合，MEF 将部件实例化，然后使导出程序与导入程序相匹配。
编程模型 — MEF 的外观
开发人员可通过编程模型使用 MEF。通过编程模型，可将组件声明为 MEF 部件。MEF 提供了一个现成可用的特性化编程模型。该模型只是 MEF 支持的众多可能的编程模型之一。MEF 的核心 API 完全与特性无关
MVP设计模式
MVP （Model-View-Presenter）是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。
在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
MVP的优点
1、模型与视图完全分离，我们可以修改视图而不影响模型
2、可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
模式图
MVVM设计模式
微软WPF技术的出现，本身可以通过绑定技术，实现view和model的结合，所以无需我们开发时再定义一个视图接口。这就出现了MVC模式的另一个变种，MVVM模式（Model-View-ViewModel）。
这种模式跟经典的MVP（Model-View-Presenter）模式很相似，除了你需要一个为View量身定制的model，这个model就是ViewModel。ViewModel包含所有由UI特定的接口和属性，并由一个 ViewModel 的视图的绑定属性，并可获得二者之间的松散耦合，所以
需要在ViewModel 直接更新视图中编写相应代码。数据绑定系统还支持提供了标准化的方式传输到视图的验证错误的输入的验证。
模式图
架构例子
模拟需求：
开发一个能实时监控设备告警的系统，本系统使用人员为监控室人员，系统能够实时呈现告警，监控人员可以对告警进行确认操作、清除操作，为方便监控，把告警分栏显示，如：活动告警一栏，确认告警一栏，清除告警一栏。用户可以通过本系统，直连telnet到设备，对设备进行命令行操作
数据建模：
在需求中，找相关的名词。
开发一个能实时监控设备告警的系统，本系统使用人员为监控室人员，系统能够实时呈现设备告警，监控人员可以对告警进行确认操作、清除操作，为方便监控，把告警分栏显示，如：活动告警一栏，确认告警一栏，清除告警一栏。用户可以通过本系统，直连telnet到设备，对设备进行命令行操作
提炼：用户，设备告警，设备【资源】
涉及到的技术：告警从设备上来，那么我们如何连到设备，需要确认，这里假设只有telnet一种方式。使用什么技术来实时呈现。这里我们假设使用现有技术，如：使用tuxedo中间件，公司积累telnet连接库等。
业务逻辑划分：
在需求中找相关的动词
开发一个能实时监控设备告警的系统，本系统使用人员为监控室人员，系统能够实时呈现设备告警，监控人员可以对告警进行确认操作、清除操作，为方便监控，把告警分栏显示，如：活动告警一栏，确认告警一栏，清除告警一栏。用户可以通过本系统，直连telnet到设备，对设备进行命令行操作
隐含动作，用户登录 ,用户信息维护 ，设备资源信息读取， 设备连接维护 ，由于仅仅是个例子，除登录以外，其他不考虑
整个系统可以有三个模块组成：用户登录，告警监控，设备操作
用户登录模块：
输入： 用户信息
输出： 权限验证信息
相关业务逻辑：用户登录
告警模块:
相关逻辑：告警呈现，确认告警操作，清除告警操作，告警接收
设备操作模块：
输入：设备名称，用户信息，操作动作
输出：操作结果
软件设计规划：
数据层：
实现 “用户，设备告警，设备”数据建模
实现相关技术
实现各个模块间的契约
应用层：
服务层： 用户登录服务，数据实时接收，确认数据操作，清除数据操作
业务逻辑层：用户登录业务，告警呈现业务，确认告警操作，清除告警操作，告警接收
展现层：
视图：用户登录界面，活动告警栏，确认告警栏，清除告警栏，telnet窗口
控制：组合各个模块，组合系统
软件设计实现：
【今天做不完，我会在以后发给大家】