以下是阎宏博士在CSDN一个关于构架和框架概念的讨论中的发言，对我们理解这两个概念很有帮助！
“
架构：architecture
框架：framework
软件的大尺度结构就是架构。一个软件不管好坏，都会有一个架构。软件架构中可以利用框架，也可以不利用框架。譬如JSP就是一种框架，而你的系统可以利用JSP框架，形成自己的架构。
所有的framework都是遵循好莱坞原则设计的，否则就不叫framework。所谓好莱坞原则，说的是You don't call us - we will call you. 意思就是在一个framework下的代码，都是被动地被framework调用，而不是相反。通过这种方式，大量重复的代码就可以隐藏在framework里面，需要特别设计的代码以预定接口的方式交给开发人员，写好后由framework调用。
譬如JSP就是一个framework。你写的JSP脚本会被JSP引擎编译成servlet的一部分。这种servlet都带有大量重复的代码，是JSP程序员不需要考虑的，由framework负责。
”
“
如果用房屋作比喻，架构就是忽略掉细节的抽象建筑结构，在图纸可以看到，存在于人脑之中，不体现为房屋的某一个物理部分。架构师就是建筑设计师，英文都是architect。
软件架构师：software architect
建筑设计师：building architect
框架是房屋的骨架，房屋的骨架是物理存在的。
卡尔。马克思在《资本论》中说，蜜蜂建造的蜂房可以使人类最杰出的建筑黯然失色，但是最蹩脚的建筑设计师也胜过蜜蜂，因为在设计师开始设计之前，房屋的架构就已经存在于设计师的脑中了。
马克思的意思是说人类的设计是有目的的活动，而蜜蜂不是。马克思所说的这个存在于人类脑中的，是架构不是框架。房屋的框架如果掉到了人脑里，哪怕是一小部分，人就死了。
“
“
下面摘自我的一本书，一直没有工夫完成。
第1.1节、什么是架构
什么是软件系统的架构（Architecture）？一般而言，架构有两个要素：
 它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。所谓架构元素，也就是组成系统的核心“砖瓦”，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
 建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点，一是建筑风格，而是建筑模式。独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
下面的照片显示了中美洲古代玛雅建筑，Chichen-Itza大金字塔，九个巨大的石级堆垒而上，九十一级台阶夺路而出，塔顶的神殿耸入云天。所有的数字都如日历般严禁，风格雄浑。难以想象这是石器时代的建筑物。
图1.1、位于墨西哥Chichen-Itza的古玛雅文明的建筑。（摄影：阎宏）
软件与人类的关系是架构师必须面对的核心问题，也是自从软件进入历史舞台之后就出现的问题。与此类似地，自从有了建筑以来，建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说，我们构造建筑物，然后建筑物构造我们（We shape our buildings, and afterwards our buildings shape us）。英国下议院的会议厅较狭窄，无法使所有的下议院议员面向同一个方向入座，而必须分成两侧入座。丘吉尔认为，议员们入座的时候自然会选择与自己政见相同的人同时入座，而这就是英国政党制的起源，这个起源的关键就是建筑物对人的影响。
在软件设计界曾经有很多人认为功能是最为重要的，形式必须服从功能。与此类似地，在建筑学界，现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能（Forms follows function）。
几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的，当然就是模式理论和XP理论。
架构的目标是什么
正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：
 可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
 安全行（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
 可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。
 可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
 可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展
 可维护性（Maintainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费
 客户体验（Customer Experience）。软件系统必须易于使用。
 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。
架构的种类
根据我们关注的角度不同，可以将架构分成三种：
 逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图
图1.2、一个逻辑架构的例子。
从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
 物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。
图1.3、一个物理架构的例子。
 系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出，就很难更改的。
根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档。
架构师
软体设计师中有一些技术水平较高、经验较为丰富的人，他们需要承担软件系统的架构设计，也就是需要设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定的作出。
这样的人就是所谓的架构师（Architect）。在很多公司中，架构师不是一个专门的和正式的职务。通常在一个开发小组中，最有经验的程序员会负责一些架构方面的工作。在一个部门中，最有经验的项目经理会负责一些架构方面的工作。
但是，越来越多的公司体认到架构工作的重要性，并且在不同的组织层次上设置专门的架构师位置，由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。
“
“
MVC是一个架构模式。.net是一个开发平台。
一个软件系统可以同时使用到多个框架。
不可能每一行代码都要用到某一个框架。
不懂得软件工程而可以开发出软件的人很多，对这样的朋友我只会说good luck，到此为止。你想怎么都可以。
如果你认真对待软件工程，那最好还是使用通行的概念。概念本就是为了交流用的，如果你使用的是自己定义的概念，除了交流会产生混乱之外，不会有别的结果。
库（library）或类库（class library）不是框架，虽然框架可以体现为库或类库。好莱坞原则是所有框架的特点，不是仅仅出现在好框架中的。
想要创造，而不是人云亦云，这个很好，但不是在使用术语和概念的时候。术语和概念就是需要人云亦云。
举个例子，北京有一家餐馆禁止日本人入内，外面立个牌子，写了一行英文（为什么不是日文，我不知道）写着“Japanese forbid entering”。这是一句根本不通的话，听上去好像是日本人禁止别人入内。学习语言，必须人云亦云，不然就到了美国人听不懂你的英语的程度，你能用英文创作吗？先把人云亦云这一关过了，然后才谈得上创造。
学习任何科学技术，都有采纳通行术语概念的问题，就像英文是用来交流的一样，这些名词术语概念和它们的含义要首先掌握。要想创造，先过了这一关。反过来，放弃这些已有的名词术语概念，自己创造一套，唯一的效果就是四不象，好像是英文，但是照英文理解根本不通，好像是软件工程，照软件工程那样讨论对牛弹琴。
遇到这样的问题，你面临的就根本不是能不能创造的问题，而是还没有入门的问题。日本人就是japanese，禁止就是forbid，入内就是entering，因此日本人禁止入内就成了japanese forbid entering。有很多讨论中的虚无观点，其实是幼稚的表现。除非他什么都不做，但凡做出来的，就差不多是japanese forbid entering这类的东西。
“
