第4讲 关于软件架构设计的思考(节选).pdfVIP

简单之美》第4 章 4.3.2 软件框架 框架的本质是约束。框架的设计者正是通过约束来传递软件构架思想的。在软件开发 过程中，采用一个框架，就意味着接受一种构架软件的思想，以及随之而来的约束。所以， 从某种程度上来说，框架担负着传承知识资产的重任。 很多软件开发新手分不清架构和框架的区别。其实，这是两个完全不同的概念。我想从 多个角度来说明这两者之间的区别： q 架构是指软件的结构，以及结构元素之间的动态关系，而框架是架构的一个组成元 素； q 从企业应用系统的角度来看，框架是编程的工具，而架构是目标； q 框架本身也具有架构，而架构可以不考虑使用框架； q 架构对于软件开发人员的约束是方向性的，它留有巨大的创造空间，而来自框架的 约束是具体的、广泛的； q 框架为软件开发人员提供了丰富的服务，而架构只会对结构元素提出各种服务的要 求。 框架的约束是全方位的。使用框架，意味着接受框架设计者的想象和思想，意味着使用 固定的编程模式，意味着编写指定格式的类型，意味着无条件接受框架提供的服务，意味着 你将受限于框架的能力。 比方说，你使用了Struts 框架，那么你必须要认同MVC 模式思想。你必须要思考页面 的流转、对象模型的建立、 务逻辑的控制，你必须要引用或继承框架提供的Action，你 必须要按照框架的要求配置你的工作成果，然后 用框架帮助运转工作成果的自动化过程， 最后，你必须要接受Struts 框架的各种缺陷，以及它的发展时间表给你带来的不便。 所以，一种正确的做法是，在使用任何框架前，应该先了解该框架对 件开发带来的 种种约束，根据组织和项目的实际情况，权衡利弊后再做决策。 简单之美》第4 章 在网上经常看到这样的讨论，比如Struts 的执行效率比较低，嵌入Tag 的页面不好编 辑，配置比较繁琐，安全机制无法与组织的安全框架集成等。这取决于你的选择。 在软件开发实践中，有一些错误使用框架的做法。例如，当框架不能满足项目的需要时， 轻率地对框架进行改动，或者零星地借鉴一些框架的思想，自己动手编写新的框架。这些做 法的结果通常都很糟糕。 糟糕的根源，一方面来自于软件开发人员创建框架的能力，另一方面来自于那些轻率的 改动，可能会打破框架思想的完整性。 我曾经见过一个糟糕的框架，尝试在Hibernate 框架上加入一些奇怪的想法，例如，打 破对象之间的关系，隐藏对象模型等。 基于这些想法创建的框架，为应用系统带来了复杂性。而且，也正是因为这些想法，在 后续的软件实现中，只能无奈地放弃Hibernate 框架的缓 机制，最终造成极其严重的性能 问题。 框架，应该被作为一个整体来使用。除非，你和框架设计者一样，透彻了解它的创作思 想以及创作细节。即便你了解了作者的创作思想和细节，你在当前做出的正确改动，也可能 会因为将来框架新版本的推出，而产生问题。 为了扩展项目需要的特殊功能，框架应该使用集成的方式，换句话说，软件开发人员要 保证集成的元素 （如框架）是可拆卸的，要为各种元素的独立演进提供可能。 回想一下，上一节中我们提到了J2EE 规范。Java 社区推出规范的目标之一，难道不是 为了保证集成元素的可拆卸性吗？ 很多集成元素都是以框架的形式来实现的。框架的实现是多种多样的，只要在支持规范 的前提下，这些框架都应该可以被替换。框架像是一种特殊的工具。生活常识告诉我们，只 要使用螺丝刀，就可以拧螺丝，而不需要局限于使用某一把特定的螺丝刀。 综上所述，我们可以看到框架所具有的一些特征： 简单之美》第4 章 q 它是一种隐喻 q 它是一种工具 q 它是一种规范 q 它是一种服务 只有认识到框架的约束本质，才能把关注点放到如何进行更好的约束上来。 在软件架构中，可以不采用任何框架。但是，没有使用框架的软件架构，常常是不可想 象的。这意味着，我们放弃了前人积累的知识财富。对于企 级应用来说，不使用框架，几 乎不可能使项目成功。要知道，在企 级应用中，要考虑的因素太多了，如此大规模的计算 要求，不是可以从头开始的任务。 由于框架的重要性，框架的选择和使用，就成了一件很重要的事情。正如我在前面指出 的那样，选择框架，必须要权衡框架所带来的利与弊。而当确定框架之后，我们应该采用集 成的方法来使用它，而不是尝试去改变它。 有时，由于项目的需要，