基于构件的软件开发？？？（回帖沾边儿就给分）

[waxberry]

在基于构件的软件开发中，框架是应用系统的骨架，如何来设计、实现框架？ （比如说钢铁行业的，或其它行业的）

[w_rose]

大英博物馆里的猴子理论从形式上看它是一个真理。我们在追求真理的时候是否想过“真理也有不适合于我”的情况？

做设计，不但要 know-what，更要 know-how。前者让你善于发现虚假的东西，后者让你开始行动。有经验的人，强调后者优先于前者，自己不空谈也反感别人空谈。没有know-how，看到任何有创意的东西都会视为垃圾。顺便问一下，know-how 翻译为“技术诀窍”对么？

[waxberry]

我所说的是基于特定领域的构件化框架开发，而钢铁行业也无非是想找个具体的领域来说一下。

[waxberry]

什么叫时机未到呀？

[gjd111686]

基于构件的软件开发的发展方向


构件技术应运而生

在信息时代,新的技术革命正在改变我们日常生活的面貌，而这场技术革命的核心是计算机软件系统。在面向对象技术给解决软件危机带来曙光之时, 分布式网络计算的巨大压力又给软件开发提出了许多新的难题,使软件开发仍处于高风险状态。新的分布式网络计算要求软件实现跨空间、跨时间、跨设备、跨用户的共享，导致软件在规模、复杂度、功能上的极大增长，迫使软件要向异构协同工作、各层次上集成、可反复重用的工业化道路上前进。为适应软件的这种需求，新的软件开发模式必须支持分布式计算、浏览器/服务器结构、模块化和构件化集成，使软件类似于硬件一样，可用不同的标准构件拼装而成。具体地说可实现下列几点要求：
● 提供一种手段，使应用软件可用预先编好的、功能明确的产品部件定制而成, 并可用不同版本的部件实现应用的扩展和更新。
● 利用模块化方法，将复杂的难以维护的系统分解为互相独立、协同工作的部件，并努力使这些部件可反复重用。
● 突破时间、空间及不同硬件设备的限制，利用客户和软件之间统一的接口实现跨平台的互操作。
为满足上述要求，软件构件技术出现了。而构件重用的目标是达到需求、分析、设计、编码、测试的重用。从此，一种影响软件产业发展的新的软件开发方法诞生了。
从抽象程度来看，面向对象技术已达到了类级重用(代码重用)，它以类为封装的单位。这样的重用粒度还太小，不足以解决异构互操作和效率更高的重用。构件将抽象的程度提到一个更高的层次，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个构件隐藏了具体的实现，只用接口提供服务。这样，在不同层次上， 构件均可以将底层的多个逻辑组合成高层次上的粒度更大的新构件，甚至直接封装到一个系统，使模块的重用从代码级、对象级、架构级到系统级都可能实现，从而使软件像硬件一样，能任人装配定制而成的梦想得以实现。近几年来，构件技术的发展已证明了它的巨大威力，在这其中，CORBA标准和Java技术的突破，功不可没！
至今, 构件技术已形成三个流派:Sun的Java平台、Microsoft的COM+、IBM的CORBA。
构件发展自律当先
基于构件的软件开发技术近年来取得了突飞猛进的发展，这不仅对软件产业的技术革新影响深远，还将为许多其他领域带来巨大的效益。早在1998年4月，在日本京都召开的基于构件的软件开发(CBSD)国际专题学术会议上达成了两个共识：
1. 对于CBSD而言，对象技术并不是必需的，同时仅仅依靠对象技术也不能实现CBSD。
这似乎有些难以理解。对象技术仅仅是CBSD的开始，但是就对象技术本身而言，它并不能全面地表述CBSD所需的抽象概念，而且脱离对象技术，CBSD也完全可以实现。因此，对于CBSD而言，对象技术既不是必需的，仅有对象技术也是不够的。CBSD将导致使用对象技术的系统设计方法、项目管理方法和组织形式的实质性变革。
具体地说，将构件看做是一个可替换的单元时，单纯的对象技术就不够了。构件的各种定义中都或多或少地强调了构件的一个特性：对上下文的依赖性。这一特性能够通过在规范中定义一种“use”语句而实现，也就是对所需系统资源的一种声明。尽管对这种方式很多人持有异议，他们认为使用这种“use”语句,意味着接口描述就是一种实现机制，而不是一种对实现方法的抽象，但是,对象技术却根本不支持构件的这种特性，这样不利于进行设计层的抽象，特别是在试图使用已有的构件进行集成时,经常会遇到麻烦。
现在人们比较一致的观点是将分布式对象技术当做是一种基础设施，而把构件看做是能够应用于不同的基础设施的抽象和实现。 在实践中人们也体会到这一点，如长事务的处理不能靠对象技术来解决。由于事务的原子性、一致性、隔离性和持久性的特点，不能把长事务简单地看成一个对象,它是一连串处理步骤的序列。这也是企业应用软件中常遇到的问题,目前一些服务器上的软件提供的事务服务,就是为了解决这个复杂的疑难问题。
2．构件离不开体系结构
由于发展CBSD的一个初衷是通过一种集成的开发方式来增强系统的灵活性，因此自然要考虑这种集成方式的可行性。然而,通过抽象接口来描述,已经超出了对象技术的能力。但是，对“插件”式构件的重用程度，与构件对一套预先定义的限制和约定的依赖程度有直接的关系。
大多数构件技术如EJB、ActiveX、CORBA等对于构件都有一定的限制。例如，尽管构件基础设施对构件的接口有一定的访问能力，但这种能力要求构件必须能够实现一定的服务或遵循构件基础设施所定义的一些规范。
许多专家认为，构件应当实现两种接口：一种是功能性接口，能够反映构件在系统中的角色；另一种是非功能性接口，能够反映由底层的构件框架所定义的构件模型。非功能性接口描述了一种体系结构上的限制，这种限制允许CBS（components-based system）具有集成能力和其他的一些特性。所以，对构件概念的理解,必然与体系结构强加于构件的这些限制密切相关。
许多专家认为，尽管构件与其所属的体系结构密切相关，但是上述的两种接口仍然过于强调构件框架在软件体系结构中的地位。而实际上，很多人都曾极力地寻求软件体系结构和构件框架的区别。但是通过对体系结构的三种不同观点的定义,保留构件框架概念的二义性：
● 运行期间：包括为基于构件的系统提供运行时服务的框架和模型。
● 设计期间：包括对构件的特定观点，如功能性接口和构件依赖性。
● 集成期间：包括系统对各种构件进行集成时所需的各种因素，如生成器和一些构造期间的服务，一个构件框架可能就会提供这些服务。
在研讨中出现的这些关于构件的更多特性,表明构件是一种设计阶段的复杂实体，它包括抽象的概念和具体的实现。 因此，许多专家认为，使用现成构件的CBSD,把构件视为一种商业上的现成商品，在这种情况下，CBSD必须建立关于构件框架的行业规范。
构件影响不可小觑
要实现构件技术必须具备下列几个条件:
● 有标准软件体系结构,保证构件间通信协议统一, 实现同步和异步操作控制，突破本地空间限制,充分利用网络环境。
● 构件有标准接口, 保证系统可分解成多个功能独立的单元, 用构件组装而成。
● 构件独立于编程语言。
● 构件提供版本兼容, 来实现应用系统的扩展和更新。
总之，CBSD为软件开发技术带来了新的生机，其影响力正在显现。

[gjd111686]

基于构件开发的应用框架设计
--------------------------------------------------------------------------------

　　框架必须是健壮的、可扩展的、灵活的，且支持动态内容，它要求基于开放或共享标准。框架的设计要力求做到：完备性、灵活性、可扩展性、可理解性，同时抽象能用于不同的场合；用户能轻松地添加和修改功能，定制框架；用户和框架的交互清晰，文档齐全。框架设计的一个核心问题就是发现可重用的设计和“热点”，以保证框架具备充分的灵活性，使用户能在已有构件的基础上生成应用程序，实现“零代码编写”的理想目标。
一、如何设计应用框架？
　　目前在框架设计方面成熟的技术较少，大体可分为两类：实践法与系统法。
1. 实践法
　　许多专家甚至认为框架不可能是系统设计的结果，而只是在从底向上设计中的一个结果。实践法也可以说是实例(Example)驱动的设计方法,它是从若干个具体的典型应用中，抽象出相似点来构建框架，框架反过来又应用于不同的问题，并在解决不同问题的过程中得到更新，在框架的设计和实现的两步中，不断反复。等到框架逐渐成熟时，需要修改和反复的内容就会越来越少。
　　具体步骤为：
　　分析问题领域，确定所需框架。从一类应用而不是单个的程序去分析、比较各种不同的软件解决方案，寻求这些方案的共性和每个程序的唯一性特征。这些共性，尤其是那些经常被多个程序使用的部分将成为框架的基础。然后定义框架体系结构并设计，包括设计用户与框架间的交互、给用户提供的最终工具等。
　　框架的实现。包括框架核心类的实现、框架的测试、框架的试运行、框架的反复更新。
　　框架的部署。包括文档的提供、分发过程，为用户提供技术支持，维护和更新框架。
　　这种方法也就是先在具体类基础上进行泛化，提取出抽象类。抽象化也是框架开发的一个关键。不过，根据这种方法设计出的框架的可适用性很大程度上依赖于其基于的具体应用。
　　由于框架的开发具有反复性，且需要深入了解应用领域，因此框架的开发很难按进度表进行。框架的设计者也需要和应用开发者紧密合作，因为框架只有在使用它开发应用的过程中才能发现其哪些部分有待改进。
2. 系统法
　　由于有人认为框架的设计也可以通过系统的方法得到，因此人们提出了逐步泛化的框架设计方法。此时框架的设计分两步：
　　第一步是问题的泛化。它要求解决如下问题:问题领域中的哪些概念可以表现为变量，并且需要统一处理？是否可以发现一些具体的概念，它们能被泛化为一个更抽象的概念？
　　第二步是框架的设计。在这一步中，泛化是从反向考虑，以实现每一级的框架。换言之，最先实现最通用的框架，然后实现次通用的框架，以此类推。如图1所示, 其中，框架0就是最终要实现的框架。
　　这一步需要解决如下问题：系统的哪一部分可能需要改变？用户需要在什么地方向框架中加入自己的代码？
　　采用两步的设计方法可以避免在早期的开发过程中局限于应用专用的类和体系结构，并且有利于使用通用的设计模式。
　　框架的设计是一个反复的过程，在这个过程中需要领域和设计两方面的专家意见，框架用户和框架开发者之间的交流对框架的设计也很重要，因为框架是在不断反复的过程中逐步成熟的。
3. 框架设计与应用设计
　　框架的设计和应用的设计到底有何不同？一般而言，两者的侧重点不同。设计应用系统时，要求对专用领域的重要概念有深入的了解。这些概念通过建模演变成类，并作为实现整个应用的构建块。而设计框架时，重点在识别出必须具备灵活性的地方，也就是“热点”，这也是框架的关键所在。
　　构件库系统基于框架而不是具体的类，使得构件库系统的使用更具灵活性。但在框架基础上构建具体的应用时, 类的使用和开发总是随之而来，在框架上生成应用可以通过创建子类、配置各构件对象、调整实例等来获得。
4. 框架文档
　　文档必须包括如下内容:框架的目的，如何使用框架，框架的设计细节等。
二、框架采用哪些支持工具？
　　一般而言，没有支持工具的框架很难被使用。任何一个框架的提出总是配有一系列工具软件，这样基于框架的应用开发才切实可行。这些工具允许用户与应用框架交互、配置和构筑新的应用。下列工具通常被使用：
　　浏览工具 用户可以利用它浏览框架的类层次结构等信息。
　　编辑工具 用户用来调整和修改框架元素的属性等，如修改类或构件等。
　　帮助系统 为用户使用本框架系统提供向导功能，如可以采用HTML格式。
　　测试系统 用来测试生成的应用系统，通常支持仿真操作。
　　文档工具 帮助创建应用系统的文档，如Javadoc工具。理解并学会使用框架是一件费时的工作，这也是框架设计方法的唯一不足之处，因此要求框架的文档必须齐备。
　　配置管理工具 使用框架而不是具体的对象虽然提供了复用性，但它同时也带来了开发上的复杂性。框架内包含各种构件或构件库，一个框架可能需要和其他框架通信。一个框架也可能由其他子框架系统组成，这样一种组成结构必然提出配置管理的问题。例如，如何在多个框架内共享构件？如何由构件或子框架组装新框架？框架内的构件如何通信与协作？不同的框架间如何交互？
　　使用这些高级工具的最终目的就是减少编码和记忆的工作量,简化用户的操作。理想情况下，用户可以不用编一句代码而实现新系统的构建。例如，在一可视化界面上，通过选取一些图标就能生成可执行程序。目前已有一些类似的工具，如University of Geneva开发的Vista系统。
三、都有哪些著名的框架系统?
　　目前有许多框架系统，例如用户界面方面的框架有MVC、ET++等，其中ET++采用C++语言实现，运行于Unix等系统中；针对其他领域的则有FOIBLE、MacApp、FACE (Framework Adaptive Composition Environment)等。
　　早期一些框架系统多采用传统的面向过程语言实现，现在面向对象语言为软件和设计的重用提供了更强有力的支持。由于框架开发的学习曲线较复杂，因此框架开发的语言最好能对框架的文档建立提供有效的方法；框架的使用要求开发语言具备高可移植性;框架的设计其实也是一些高层的决策，很自然采用高级语言来实现。Java语言由于具有平台duli性以及轻量级的链接过程、自动垃圾回收、简单语言结构、标准软件包、面向对象等特性，因此可以说Java是进行框架构筑的合适语言。现在市场上已出现了许多采用Java语言编写的框架系统。
　　LEC India Software Centre Pvt. Ltd.公司研制了一个面向EJB 构件的应用框架系统。它主要面向基于EJB的应用程序，是一个服务器端的框架，能在EJB构件的开发中解决稳定性以及其他一些企业级的特性等问题。
　　现在又出现了许多采用J2EE编程环境的应用框架，如Pacific技术服务公司开发的一套多层框架，能用来开发Web应用服务器；Jcorporate公司开发的Expresso Framework是一使用java来建造分布式、重用、基于构件的安全的Web应用程序的应用框架。
四、 如何设计知识工程应用框架?
　　在知识爆炸的时代，如何从数据中提取信息，从信息中提取知识已成为一个重要的应用领域。越来越多的知识处理应用系统急待开发，若能有一个成熟可靠的知识处理框架系统，将大大加快此类应用系统的开发。针对这种情况，清华大学知识工程研究室结合自己的经验,目前提出了在知识工程应用领域的框架，主要针对网络计算模式下的知识获取、传输、管理和应用，基于Web的数据挖掘与知识发现等内容，所有的代码均采用Java实现。
　　将应用框架结构化为框架的框架，划分为如下三个子框架：
　　(1) 领域专用构件框架:提供领域专用的构件模型集合，并为分层的构件模型提供统一接口。
　　(2) 可视化组装框架:提供整个框架系统的图形化界面，并为可视化组装和操作构件提供工具。
　　(3) 连接框架:为构件间的交互、通信提供机制。
　　框架内各构件的分布如图2所示。
　　建立的基于框架的构件系统具有如下性能：
　　实现面向产品化、实用性的构件库系统，并具开放性、可扩展性；
　　支持异构环境中的框架、构件的互联和通信;
　　实现新旧系统的兼容性；
　　提供一致的接口分配；
　　遵循重要构件标准（如CORBA）；
　　构件具有透明本地化、平台无关性特点；
　　系统的配置、数据交换基于XML和Java的标准化格式；
　　支持个性化信息服务定制和可重构。
　　良好的用户学习曲线。
　　框架的设计本身也是一个循环迭代的过程，它在不断应用于实践的过程中，得到更新和提高。我们也在不断的完善这套系统。目前一些公用构件如电子表单自动生成系统、数据提取和文件转换系统等作为大粒度构件已得到广泛使用。
　　框架能使应用程序的开发简单，价格低廉，但是开发框架不是一件容易的事。它是一个需要领域和设计经验的反复过程。为了保证框架的灵活性，必须提取和发现热点。设计模式可以简化这个过程，因为它提供了对过去经验的抽象。应用框架能高度抽象同一领域内的问题，进而降低开发难度和强度。虽然框架和构件技术已经出现许多年了，开始走入实用,但还不成熟，有大量问题有待研究。

[gjd111686]

变革与突破—如何认识基于构件的软件开发方法


与传统的软件开发方式相比，基于构件的软件开发方法有什么突破呢？



一、体系结构



　　软件体系结构代表了系统公共的高层次的抽象，它是系统设计成败的关键。其设计的核心是能否使用重复的体系模式。传统的应用系统体系结构从基于主机的集中式框架，到在网络的客户端上通过网络访问服务器的框架，都不能适应目前企业所处的商业环境，原因是：



　　企业过分地依赖于某个供应商的软件和硬件产品。这种单一供应商使得企业难以利用计算供应商的免费市场，将计算基础设施的重要决定交给第三方处理，这显然不利于企业在合作伙伴之间共享信息。



　　不能适应远程访问的分布式、多层次异构系统。



　　封装的应用系统在出现某种组织需要时，难以用定制来维护系统，从而难以满足多变的需求。



　　不能实现分析、设计核心功能重用，最多只能实现代码重用。




　　如今，应用系统已经发展成为在Intranet和Internet上的各种客户端可远程访问的分布式、多层次异构系统。CBSD为开发这样的应用系统提供了新的系统体系结构。它是标准定义的、分布式、模块化结构，使应用系统可分成几个独立部分开发，可用增量方式开发。



　　这样的体系结构实现了CBSD的以下几点目标:



　　能够通过内部开发的、第三方提供的或市场上购买的现有构件，来集成和定制应用软件系统。



　　鼓励在各种应用系统中重用核心功能,努力实现分析、设计的重用。



　　系统都应具有灵活方便的升级和系统模块的更新维护能力。



　　封装最好的实践案例，并使其在商业条件改变的情况下，还能够被采用，并能保留已有资源。
由此看出,CDSD从系统高层次的抽象上解决了复用性与异构互操作性，这正是分布式网络系统所希望解决的难题。



二、开发过程



　　传统的软件开发过程在重用元素、开发方法上都与CBSD有很大的不同。虽然面向对象技术促进了软件重用，但是，只实现了类和类继承的重用。在整个系统和类之间还存在很大的缺口。为填补这个缺口，人们曾想了许多方法，如系统体系结构、框架、设计模式等。



　　自从构件出现以来，软件的重用才得到了根本改变。CBSD实现了分析、设计、类等多层次上的重用。图1显示了它的重用元素分层实现。在分析抽象层上，重用元素有子系统、类；在设计层上重用元素有系统体系结构、子系统体系结构、设计模式、框架、容器、构件、类库、模板、抽象类等。










　　在软件开发方法上，CBSD引导软件开发从应用系统开发转变为应用系统集成。建立一个应用系统需要重用很多已有的构件模块，这些构件模块可能是在不同的时间、由不同的人员开发的，并有各种不同的用途。在这种情况下，应用系统的开发过程就变成对构件接口、构件上下文以及框架环境一致性的逐渐探索过程。例如，在J2EE平台上，用EJB框架开发应用系统，主要工作是将应用逻辑,按session Bean、entity Bean设计开发,并利用JTS事务处理的服务实现应用系统。其主要难点是事务划分、构件的部署与开发环境配置。概括地说，传统的软件开发过程是串行瀑布式、流水线的过程;而CBSD是并发进化式，不断升级完善的过程。图2显示了它们的不同。










三、软件方法学



　　软件方法学是从各种不同角度、不同思路去认识软件的本质。传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流、面向对象等不断创新的观点反映问题的本质。整个软件的发展历程使人们越来越认识到应按客观世界规律去解决软件方法学问题。直到面向对象方法的出现，才使软件方法学迈进了一大步。但是，高层次上的重用、分布式异构互操作的难点还没有解决。CBSD发展到今天，才在软件方法学上为解决这个难题提供了机会。它把应用业务和实现分离，即逻辑与数据的分离，提供标准接口和框架，使软件开发方法变成构件的组合。因此，软件方法学是以接口为中心，面向行为的设计。图3是其开发过程。










　　归纳起来，CBSD的软件开发方法学应包括下面几方面：



　　对构件有明确的定义。



　　基于构件的概念需要有构件的描述技术和规范，如UML、JavaBean、EJB、Servlet规范等。



　　开发应用系统必须按构件裁剪划分组织，包括分配不同的角色。



　　有支持检验构件特性和生成文档的工具，确保构件规范的实现和质量测试。




　　总之，传统的软件方法学从草稿自顶向下进行，对重用没有提供更多的辅助。CBSD的软件方法学要丰富得多，它是即插即用，基于体系结构，以接口为中心，将构件有机组合，它把自顶向下和自底向上方法结合起来进行开发。



四、开发组织机构



　　传统软件的开发组织一般由分析员、设计员、程序员和测试员组成。对一个小的应用系统来说，一个熟练的开发人员，可能兼顾以上多个角色。但对CBSD来说,因为构件开发与应用系统集成往往是分开进行的，因此整个开发过程由六个角色来完成，他们是:



　　构件开发者 也是构件供货商，这些大多数是中间件构件提供者。



　　应用构件集成者 针对某应用领域将已有构件组合成更大的构件模块或容器， 作为系统部署的基本单元。



　　应用系统部署者 将系统部署基本单元放入选定的平台环境或基本框架中，完成软件定制的要求。



　　开发平台服务器供应商 提供服务器、操作系统和数据库等基本软件。



　　应用系统开发工具供应商 提供构件公共设施服务。



　　系统管理员 配置硬件、网络和操作系统，监督和维护应用系统者。




　　这六个角色的工作专业性很强，要兼顾成为多面手很不容易。目前已形成构件开放市场，而且还很火红。这也是当今软件人才大战所遇的一个困惑。因此，在CBSD中，如何组织好开发队伍尤为重要，必须按本企业所具备人才来组织。特别重要的是:开发初期必须选好标准框架，以及统一的开发指导方针，保证在整个开发过程中,各角色能随时互相沟通。一般来说，CBSD的人员素质决定了构件的重用率。



五、构造方法



　　传统应用软件的构造是用白盒子方法，应用系统的实现全在代码中，应用逻辑和数据粘结在一起。而CBSD 的构造是用白盒子和黑盒子相结合的方法。 基于构件的框架是用两个概念来支持演变：第一个概念是构件有很强的性能接口，使构件逻辑功能和构件模型的实现都隐藏起来。这样，只要接口相同，构件就可以被替换。



　　第二个概念是隐式调用，即在基于构件的框架中，从来不直接给构件的接口分配地址，只在识别构件用户后才分配地址。因此，构件用户只要了解接口要求和为构件接口提供的引用后的返回信息 (该引用可能是一个构件，也可能是一个构件代理。对构件用户来说，构件代理就是构件，不用区分) 。 构件接口的信息并不存入构件内，而是存入构件仓库或注册处。这样才能保证构件替换灵活，并很容易利用隐式调用去重新部署构件。由于构件的实现对用户透明，因此也使构件能适应各种不同的个性化要求。为此，构件提供自检和规范化两个机制。自检保证在不了解构件的具体实现时，就能获得构件接口信息。例如，JavaBean提供的自检机制是Reflection和BeanInfo， 通过Reflection 可直接获得Bean构件的全部方法，通过BeanInfo可直接获得构件的许多复杂信息。



　　规范化允许不访问构件就可以修改它，如JavaBean提供的规范化是property sheet和customizer(定制器)。 通过property sheet提供一组简单参数，修改Bean的属性。复杂的修改由用户通过定制器设置参数完成。

[wg007]

构件是架构上的，框架是开发设计上的。还没作应用的分析，作什么框架。
应用分析作出来了，自然框架就形成了。

[asj]

又来了一位不知所云的

[jeffyan77]

楼主这个问题本身不是很清楚。

首先弄清楚名次。构建如果是指component，基于构件的就是component based。通常认为构件是可以独立deploy的软件单元，譬如ActiveX就是独立构件。Java中的class或者package不一定符合构件的条件，除非它们可以相对独立的deploy。能够独立deploy的构建内部设计不一定是OO的，譬如VB6写出来的ActiveX构件。

真正商业化的构建模型就只有几种，包括ActiveX，JavaBean/EJB，CORBA等。每一种构件模型当然都有一个框架，即framework，对于COM来说就是楼上一位接触到的。对于EJB和CORBA可以在很多地方找到。如果楼主说的是这个框架，那就需要分清楚是哪一种构件模型。

如果楼主说的是在某一种构件模型下设计应用系统如何设计框架的话，那么这个框架就不是构件模型本身的框架，但是也必然与它有关系，因此也需要指明构件模型。譬如COM和CORBA的架构设计会有很大不同。

是不是这些构件模型都有共同的特点呢？肯定也会有的，那样你就需要告诉我们，你要讨论的是它们三者共同的特点。

[showerXP]

soap/web services也是构件模型吧！还有，corba是要花钱的，EJB不知道，估计也要。

[agiler_charming]

构件?组件？构件开发？组件开发？基于构件的开发？基于构件的框架开发？
大家先要有一个明确统一的概念才能讨论下去--到底你说的和你想说的是哪一个？

[ironicelee]

在我看来基于构件，现在其中一种趋势就是使用中间件技术。所谓中间件技术，像COM/DCOM、CORBA、EJB等。而Web 服务应该是更为松散的模型，不应归入此类。应用框架是具体的行业相关的模型，它与你的需求有关。

[Sustain]

component 构件
module 组件
element 元件
know-how 技术知识

为什么很少有人把模块叫做“组件”？“组件”又经常和“构件”混淆？
know-how为什么被叫做“技术诀窍”？

[zhouzh197895]

呵呵﹐學習一下。

[WorxHDream]

能说具体点吗？

[glooby]

How to design a framework? As far as I know, there is no any good methodology now. What’s the framework? Framework is a structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. Framework is a software architecture for reuse. So the process of designing a framework is to find a solid structure for reuse. The difficulty of designing a framework is to find what to reuse and how to build a solid structure for reuse not anything of software engineering or technology. To build a framework, we, software engineers, must be familiar with the specific domain we worked in; we must have very strong communication skill; we must work with domain experts; we must put reuse in our heart at any time; we must have the strong courage to pull down our prior work. I really don’t know how to design a framework; I have just done it again and again. Three or Four times I iterate, a framework will be built.

[dbigbear]

jeffyan77(jeffyan77) ，
留个QQ号？

[waxberry]

当然是指特定领域的框架了。肯定不是corba,ejb,com的构件模型

[lovestl]

有难度，学习学习

[zhongwanli]

studing