Architecture和Framework的区别[转@大数据翻译]

架构（Architecture）和框架（Framework）杂谈 by 潜鱼在渊 经常感觉很多人对于架构和框架分得不是很清楚，随便写一点关于这方面的东西吧。如果以后对于这方面的认识更加深刻的话，再补充好了。 1. 架构和框架的设计层次不同 类似于硬件设计，软件设计也分为不同的层次。典型的软件设计层次如下图：

在这个图中我们可以看到，Framework处于Micro-architectures和Application Level之间。Deisgn Patterns是Micro-architectures级的设计，Framework由多个Design Pattern和其他微架构设计元素形成。而Object&classes、Micro-architectures和Framework被称为 Micro Level设计。就是说，从Objects&classes到Framework，还没有发生质变。 对于Application Level到Global/Industry Level的设计来说，就都是Architecture的范畴了。从Application Level来说，它是由零到多个Framework组成的独立的应用程序，会考虑诸如UI之类的重要问题。System Level由多个应用组成，每个应用在整个系统中代表不同的角色，这些应用共同组成一个系统工作环境。Enterprise Level又是由System Level组成，通常跨越整个企业（这里是广义的企业）中的多个组织机构。Global/industry Level由多个企业通过Internet和商业市场组成一个相当大范围内的系统应用，B2B就是这样的Global Level设计的应用系统。 显然Framework和Architecture在这里的差别是巨大的，哪怕和Application Level相比。当一个应用中只使用了一个Framework时，我们可以把它叫做Architecture吗？事实上，Framework仅仅是 Architecture中的一个微不足道的部分。在Achitecture中，我们考虑技术视图时，会选择J2EE或.NET，然后才会考虑：是否要用 Spring、Hibernate？从这里可以看出，Framework只是技术视图的一个设计决策。 2. 架构和框架的Design Forces不同 其实，仅仅上面的描述也应该能够让大家清楚的认识到Architecture和Framework的区别了。但我还想在另外的方面更进一步说明。 Design Forces我不知道怎么翻译，只能解释一下了：Design Forces指设计主要针对的问题、领域和能力。勉强可以翻译成“设计针对”吧。 Framework的Design Forces主要是功能性、复杂性和性能。从Framework的定位和设计层次来说，它主要目的是帮助开发人员完成公共的、系统的功能，这些功能在大多 数应用中都需要，差别在于多少而已。对于一个Framework，完成系统的功能，隐藏并尽量简化这些系统功能的复杂性，同时提供可接受的性能，这就是它 的设计目标了。 而对于Architecture，其最主要的Design Force就是变更。其次，所有可能的问题都是要在Architecture中考虑：复杂性、功能、性能、技术、所有非功能需要等等。。。 3. OOP、AOP还是FOP（Framework oriented Programming）？！ 做Java有一个好处，就是各种框架技术层出不穷，使用方便。但这不见得就是好事情。感觉很多人非常专注于框架的使用和研究，对框架注意力 甚至超过了对OO、Java、J2EE规范等基本的东西的注意力。倒是有些象当初Windows下面，用VB、VC、Delphi，还是 CBuilder？似乎有些人把OOP、AOP变成了FOP。 在我看来，框架这个东西，用用是可以的，研究就不必了；自己写个框架也是可以的，但也不应该停留在框架这个层次。不要在框架上浪费精力，把这个事情交给毕业生做好了。 4. 慎用Framework！ 小标题夸张一点，是为了提醒大家。一般情况下，使用Framework可以大大减少工作量，使开发变得容易。通常使用框架应该是值得鼓励的。但是也要注意： 不要滥用Framework。不要在一个不是很大的项目中使用过多的Framework，不然维护会受到影响。 尽量不要同时使用几个功能上有交叉的Framework。这会使项目开发的管理更加复杂，同样会导致维护问题。 在Enterprise Level的应用中使用Framework时，要对Framework进行严格的评估，确保其Design Forces不和Enterprise Level的应用冲突！Framework在设计时刻通常不会考虑到Enterprise Level的问题，你不能想当然的认为它一定可以适合你的Enterprise应用！ 关于架构和框架，可以用一首诗来做结： 横看成岭侧成峰，远近高低各不同。 不识庐山真面目，只缘身在此山中。 ### Framework 和 Architecture 有何不同? by 小朱® http://www.dotblogs.com.tw/regionbbs/archive/2009/06/12/framework_vs_architecture.aspx 前幾天我在幫我顧問公司的員工上課，剛好講題就是 Software Architecture，我在課堂上順便問了一個小問題：Framework 和 Architecture 有什麼不同？結果學員多數都答不出來，因為那間公司都把 Framework 叫做架構，但光是架構這個詞在很多技術用語上都會被套到，像網站架構，其實是 Site Map 或 Site Layout 或是 Site Structure，和真正的 architecture 根本沒有關係，只是用語上好用而已 ... 套句 Bill 大的話：資訊業的解釋名詞真的很難,因為大家每天都有新名詞會發明出來。 昨天我在噗浪中發問：你認為 Framework 和 Architecture 有什麼不同？結果出現了兩種不同的答案，有人認為 Framework 可以 cover Architecture，但又有人認為 Architecture 的位階比 Framework 要高，其實，Architecture 這個字是建築之意，也就是由沒有建築物到完成的過程，以及如何將建築生產出來的方法（即建築學），它是一種 Guideline，又稱藍圖（blueprint），它指導了建築物應該要怎麼蓋，牆要幾公分高，樑柱的位置，地基的面積，基礎要打在哪，高度要多高，房間要多大等等都有。但它卻沒有叫你要用什麼方式（工法）蓋。 軟體也是一樣，所謂的軟體架構（Software Architecture）是一種軟體的藍圖，它告訴你這個軟體的結構，功能，介面，用法，與其他系統的構連以及資料交換等等規範，但它並沒有叫你要用什麼方式實作，因此軟體架構通常會產生文件，圖樣，原型以及規格等，就是沒有可用的程式碼，因為那不是軟體架構應該有的東西，就像蓋房子時是給你藍圖，而不是一幢蓋好的房子。 相對的，軟體框架（Framework） 的英文名稱原意是骨架，拆開來看是 "Frame"-"work"，表示是在一個既定的框架下可以做的工作，也就是說，這是一個已經成形的方法，而且有程式碼實體（例如鋼構工法也是要有鋼材才能做），並且會告訴你要如何使用它（即 Framework Documentation，MSDN Library 即為一最佳例子），但怎麼使用它是程式設計師（也就是監工）的工作，與 Framework 無關。 Framework 和 Architecture 經常被用來叫做架構，其實它們兩個本質上的差異是很大的，Framework 只會告訴你怎麼用，但不會告訴你怎麼實作出特定功能，而 Architecture 是告訴你某些功能的走向以及方針，但卻沒有程式碼給你，所以 Architecture 通常會需要 Framework 來實現，而 Framework 也需要 Architecture 才能發揮其所長。 ### 人们对软件架构存在非常多的误解，其中一个最为普遍的误解就是：将架构（Architecture）和框架（Framework）混为一谈。 框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。 软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。或许，人们常把架构和框架混为一谈的原因就在于此吧! 节选自《软件架构设计》书稿