组件驱动开发术语开始被广泛使用,尤其是 与控制反转有关.
它是什么？
它解决了什么问题？
什么时候适当,什么时候不适合？
aryeh.. 13
它是什么？
我认为你答案中的定义很好地涵盖了这个问题.虽然,我质疑为什么定义包含组件需要明确定义其依赖项.组件的规范示例是ActiveX控件 - 他们是否需要显式定义其依赖项？
它解决了什么问题？
管理复杂性.它试图通过允许您只考虑组件的实现来解决这个问题.人们应该只需要创作组件,不应该考虑如何组合或管理它们.这是由组件外部的某些框架或基础结构完成的,对组件作者来说并不重要.
什么时候适当,什么时候不适合？
在trival或throw-away应用程序中不一定合适.组件体系结构中的难闻气味是,如果您花时间思考或使用基础结构来管理和组合组件,而不是组件本身.
它是什么？
我认为你答案中的定义很好地涵盖了这个问题.虽然,我质疑为什么定义包含组件需要明确定义其依赖项.组件的规范示例是ActiveX控件 - 他们是否需要显式定义其依赖项？
它解决了什么问题？
管理复杂性.它试图通过允许您只考虑组件的实现来解决这个问题.人们应该只需要创作组件,不应该考虑如何组合或管理它们.这是由组件外部的某些框架或基础结构完成的,对组件作者来说并不重要.
什么时候适当,什么时候不适合？
在trival或throw-away应用程序中不一定合适.组件体系结构中的难闻气味是,如果您花时间思考或使用基础结构来管理和组合组件,而不是组件本身.
我不确定它是一个"广泛"的术语,但在VCS(版本控制系统)中,我知道有两种方法来管理构建程序所需的一组文件:
基于系统的方法,其中所有集合具有共同的生命周期,并且必须标记为全部
基于组件的方法,其中单个文件集具有其自己的生命周期,并且元标签引用组件的所有标签,以通过这些组件之间的组合和依赖性来指定所有系统.
的应用性架构被用于识别这些组件:
功能域和应用程序
第三方图书馆
构架
这就是IoC的用武之地,因为它是任何框架的基础.它解决的问题是允许您更好地识别应用程序的一部分:
假设您设计了一个PLR(损益)应用程序,负责计算交易者的收益和损失(头寸).
您很快就会意识到它不是一个单独的应用程序,而是由几个组成:
GUI
发射台
调度程序(在几个服务器上调度计算,因为没有足够的内存来计算所有!)
等等
然后,您可以确定一个计算框架(Ioc),它可以使您插入不同的模块,然后由框架在适当的时间调用.
或者,您可以识别纯技术框架(KPI,日志,异常管理),然后可以由任何其他功能组件使用.
在项目管理方面,这也允许您独立开发每个部分,同时确保通过VCS进行全球协调.
基于组件的开发并不是什么新鲜事.我不知道组件驱动开发,但我会假设它是CBD.这就是Unix的设计方式,一堆可替代的小程序,每个程序都做得很好.在桌面领域,Delphi的VCL成功地使用了具有丰富的可重用组件和第三方市场的组件.随着一些技术日趋成熟,我们现在看到了CBD的复兴.例如,简单的Web应用程序正在发展为SOA和RESTful WS.所有Java人员都在谈论的是模块化和IoC.
您正在寻找的答案可能会出现在为什么以及柯金的"控制倒置"中.
此外,这些经典的OO编程语言的必然性往往会错过树的森林(高级架构/结构)(低级逻辑控制程序代码).接管现有应用程序的开发和维护工程师必须依赖其过时的设计/体系结构文档和低级代码注释/模式.
基于组件的开发(CBD)范例通过将管道逻辑转换为基于用户/开发人员提供声明性描述来操纵组件和设置应用程序的框架来解决上述两个问题.与常见的混淆相反,这种声明性描述并不意味着应用程序设置脚本.相反,它们的基本意图是明确表达应用程序体系结构/结构,而不强制其命令性管道程序(即描述什么而不是如何).CBD范例的目标是通过这些框架支持有效且灵活的应用程序组合,并使应用程序开发人员专注于业务逻辑和域问题,而不涉及低级管道复杂性.
结合声明性应用程序描述和IoC技术的CBD框架称为IoC框架.与其前身相反,IoC框架 是非侵入式的,并使用 依赖/配置注入/设置方案.
根据Wikipedia,基于组件的开发是基于组件的软件工程(CBSE)的别名.
[它]是软件工程的一个分支,其优先级是关于整个给定软件系统中可用的广泛功能的关注点的分离.
这有点模糊,让我们来看看更多细节.
单个组件是封装一组相关功能(或数据)的软件包或模块.
所有系统进程都放在单独的组件中,以便每个组件内的所有数据和函数在语义上相关(就像类的内容一样).由于这个原理,人们常说组件是 模块化和内聚的.
因此,根据这个定义,组件可以是任何东西,只要它做的一件事情真的很好而且只有一件事.
关于系统范围的协调,组件通过接口相互通信.[...]这个原则导致被称为封装的组件.
所以这听起来越来越像我们认为好的API或SOA应该是什么样子.
的提供接口由棒棒糖表示,并且需要接口由附连到在UML组件的外边缘开放的插座符号表示.
alt text http://upload.wikimedia.org/wikipedia/en/2/25/Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif
组件的另一个重要属性是它们是可 替代的,因此如果后续组件满足初始组件的要求(通过接口表示),则组件可以被另一个组件(在设计时或运行时)替换.
可重用性是高质量软件组件的重要特征.应该设计和实现软件组件,以便可以在许多不同的程序中重用它.
可替代性和可重用性是使组件成为组件的原因.那么这与面向对象编程有什么区别？
面向对象编程(OOP)中的思想是软件应该根据它所代表的实际或想象对象的心理模型来编写.[...]
相比之下,基于组件的软件工程没有做出这样的假设,而是声明应该通过将预制组件粘合在一起来开发软件,就像在电子或机械领域一样.
这是我做一些研究后的定义.
组件驱动开发是一种软件开发方法,其中将代码分段为可重用且可测试的组件,这些组件组合在一起以形成用于提供业务功能的应用程序基础.组件的组合和管理通常委托给控制容器的反转.
组件本身是一个实现某个服务契约的类,并明确定义它为完成此契约所需的依赖项.实际的实现对组件外的所有其他人都是隐藏的.
相关链接:
组件驱动开发和IoC容器
我将基于组件的软件工程视为通过使用可插拔组件开发软件系统的方法; 组件是" 具有合同指定的接口和仅显式上下文依赖关系的组合单元 "," 可以独立部署,并受第三方组合的约束 ".(Clemens Szyperski," 组件软件:超越面向对象的编程 ")
CBSE有助于代码重用和灵活/适应性软件系统的快速组装.
多年来一直关注这一主题的实质性研究.旗舰活动(ACM SIGSOFT基于组件的软件工程研讨会)现已进入第14个年头,并且出现了不少新趋势.
此外,如果您想要一个可重用,可插拔和可扩展组件的良好示例,这些组件已被业界广泛使用,请查看MS Enterprise Library.
京公网安备 11010802040832号 | 京ICP备19059560号-6 