应用框架的设计与实现.net平台--应用框架解析（框架开技术）

为了有效的应用框架技术，你需要了解一些框架开发的通用技术；下面列出了一些有用的技术和方法，能够帮你开发出易用又可扩展的框架

• 通用点
• 扩展点
• 黑盒框架
• 白盒框架
• 灰盒框架
• 设计模式

其中，通用点，扩展点和设计模式是用于开发框架的技术，黑盒，白盒和灰盒是开发框架的方法

2.3.1 通用点

通用点代表业务反复出现的通用主题位置。如果应用某些部分重复出现，且其中又没有太多变化，那么我们就将他从应用层中提取出来，作为通用点，封装成框架层组件。通过通用点移到框架层，避免了这些通用点在应用层的重复出现，从而促进了代码重用，这样，开发者能够简单地在他们的应用当中引用框架层的通用点，从而减少开发量图2-3说明了通用点和框架以及业务层应用的关系

                                                     

在图2-3中，应用框架包含了一些组件，这些组件实现了应用中一些不同的通用点。当开发者开始构建应用时，他们将引用框架组件实现通用点，而不用亲自去开发它们，结果，他们要编写的代码总量就减少了。

什么样的主题才能成为通用点呢？是不是必须在整个应用中，都一精确相同的方式出现的主题才有资格成为通用点？答案是否定的，只要差异不大，你依然可以把这个主题作为通用点：只是需要通过参数化或者配置选项的方法，来处理这些小的变化。

将通用点主题医道框架组件层中的实际工作并不困难，困难的是分析阶段，如何从尚未开发的业务应用中识别哪些通用点。识别这些深藏在应用中的通用主题确实不易，通常需要多次尝试才能做到。

通用点既可以存在于特定的领域框架层中，也可以存在于跨领域框架层中。例如:商业文档交换，是B2B应用中最重要的主题，可以考虑把商业稳定对象最为通用的主题，放入特定的领域框架层组件中，例外一个例子就是数据加密服务，对很多类型的应用来说，数据的加密解密通常需要被应用到不同部分使用，可以把数据加密，解密组件作为跨领域框架层组件，他简化了开发者的工作量。

从技术观点来看，通用点的实现是直观易懂的。识别出通用点之后框架设计者可以开发组件来封装通用点中的主题和逻辑：这些组件常常采用具体类或者可执行的形式，为了包容组件中的些小变化，可能需要为该组件引入一些配置数据，例如，你可以在配置文件中分配特定的段来参数化该组件。这样，若要在应用中引入该组件，开发者几乎不需要写代码就可以办到；

通用点捕捉应用中反复出现的主题，然而，每个业务应用都有其独特性，多个应用之间，既存在大量通用点，又会因每个应用的本质不同，而存在大量显著不同之处，因此，应用中可能有通用主题，也有显著的变化和客户化，为了保证在上述两种情况下，应用开发者都能利用框架，最为框架的设计者，也需要考虑这点变化。这把我们带到下一个主题：扩展点

2.3.2 扩展点 

框架中具有灵活性的点即扩展点；也可以看做是上课过程中的占座，将来在此处可以针对特定的应用进行定制。

扩展点和通用点正好相反，通用主题在框架中实现，而扩展点只留下一个空的座位，以便不同的人可以坐上去（及客户化实现）。因为每个业务负责为框架中的扩展点提供自己的实现。所以框架还能够被设计成适用不同业务的原因。图2-4说明了引用框架如何通过扩展点具有了灵活性。

在上图中，应用框架的组件包含了众多的扩展点，或者说空座位。每个应用可能适用框架：当应用框架中的扩展点的时候，该应用都需要提供具体的实现。

和通用点类似，识别扩展点或许不容易，为了识别潜在的扩展地方，必须彻底了解业务领域，理解业务应用的 哪些点可能需要定制，如果框架内有太多的不必要的扩展点，将导致应用开发团队额外的工作量。扩展点少，框架灵活性就很差。使得应用开发团队期望定制变得困难。尽管可以通过覆盖基类中大部分的或者全部的虚方法来获得这种定制性的可能，但会降低代码的重用性，进而影响效果。

创建扩展点的方法：继承，组合，适配，插件

继承法：

钩子法：

抽象类中的抽象方法

抽象方法对于应用开发科框架开发来说都很重要。定义抽象类，每个子类可以根据实际情况来实现抽象的方法和属性；

尽管应用提供抽象方法的实现，但是在程序调用的时候，通常通过模板方法来调用

2.3.3 白盒框架

由抽象类组成的框架，通过继承法支持扩展点，见图2-7

百合框架的所有实现都是继承，使得应用易于设计和实现，但它缺乏灵活性，而且要非常熟悉业务，耦合程度非常高，一般不推荐使用

2.3.4 黑盒框架

黑盒框架包含很多通用点，要借助组合法来支持扩展点。图2-8说明了一个黑盒框架

2.3.5 灰盒框架

白盒和黑盒框架的集合

2.3.6 设计模式

策略模式：处理应用中算法变化的设计。支持可发着即插即用，定制特定的算法。

桥接模式：解耦抽象和实现的设计。支持开发者为应用部件提供不同的实现，而不影响其他部分

装饰模式：提供处理数据层次方法的设计，支持开发者方便的装配处理数据

观察者模式：提供订阅发布通信模型的设计。支持开发者在不同的对象之间建立松耦合的通信

中介者模式：阻止多个对象显示相互调用的设计，支持开发者对不同的对象建立松耦合关系，定义处理流程和协调逻辑

访问者模式：定义新操作而不改变旧操作的设计，支持开发者将一个操作与经常变化的协调逻辑解耦合

单例模式：确保一个类只创建一个实体的设计。支持开发者更好的控制对象

抽象工厂模式：提供创建对象族的接口，而无须指定具体类的设计，支持开发者减少应用中具体类的引用，从而减少具体类发生变化时需要改变的代码量；