什么是组件驱动开发？

Question

组件驱动开发 这个术语开始被广泛使用，尤其是。与控制反转有关。

1. 它是什么？
2. 它解决什么问题？
3. 什么时候合适，什么时候不合适？

Answer 1

它是什么？

我认为你的回答中的定义很好地涵盖了这个问题。尽管如此，我质疑为什么定义包括组件需要显式定义其依赖项。组件的一个典型示例是 ActiveX 控件 - 它们是否需要显式定义其依赖项？

它解决什么问题？

复杂性管理。它试图通过允许您只考虑组件的实现来解决这个问题。一个人应该只需要编写组件，一个人应该 不是 必须考虑如何组合或管理它们。这是由组件外部的某些框架或基础设施完成的，对于组件作者来说并不重要。

什么时候合适，什么时候不合适？

不一定适合琐碎或一次性的应用程序。组件架构中的坏味道是，如果您花时间思考或研究基础架构来管理和组合组件，而不是组件本身。

Answer 2

我不确定这是一个“广泛使用”的术语，但在 VCS（版本控制系统）中，我知道有两种方法来管理构建程序所需的一组文件：

• 基于系统的方法, ，其中所有集合具有共同的生命周期，并且必须标记为全部
• 基于组件的方法，其中单独的文件集有自己的生命周期，并且元标签引用组件的所有标签，以通过这些组件之间的组合和依赖关系来指定所有系统。

这 应用架构 用于识别这些组件：

• 功能域和应用
• 第三方库
• 构架

这就是 IoC 的用武之地，因为它是任何框架的基础。它解决的问题是让您更好地识别应用程序的部分：
假设您设计一个 PLR（损益）应用程序，负责计算交易者的损益（头寸）。
您很快就会意识到它不是单个应用程序，而是多个应用程序的组合：

• 图形用户界面
• 发射器
• 调度程序（在多个服务器之间调度计算，因为一台服务器没有足够的内存来计算所有服务器！）
• 等等

然后，您可以确定一个计算框架 (Ioc)，它使您能够插入不同的模块，然后由您的框架在正确的时间调用这些模块。

或者你可以纯粹识别 技术框架 （KPI、日志、异常管理），然后可供您的任何其他人员使用 功能性的 成分。

在项目管理方面，这还允许您独立开发每个部分，同时通过 VCS 确保全球协调。

Answer 3

基于组件的开发并不是什么新鲜事。我不知道组件驱动开发，但我假设它是 CBD。这就是 Unix 的设计方式，一堆可替代的小程序，每个程序都很好地完成一件事。在桌面领域，Delphi的VCL在使用具有丰富的可重用组件和第三方市场的组件方面取得了无与伦比的成功。随着一些技术的成熟，我们现在看到 CBD 的复兴。例如，简单的 Web 应用程序正在发展为 SOA 和 RESTful WS。所有 Java 人员一直在谈论的都是模块化和 IoC。

您正在寻找的答案可能会在 控制反转的原因和内容 作者：柯金.

此外，这些经典的OO编程语言的必要自然倾向于错过树木（低级逻辑控制程序代码）的森林（高级建筑/结构）。接管现有应用程序的开发和维护工程师必须依靠其过时的设计/架构文档和低级代码注释/模式。

基于组件的开发（CBD）范式通过将管道逻辑转移到操纵组件并根据用户/开发人员设置应用程序的框架来解决上述两个问题，提供了声明性描述。与常见的混乱相反，这种声明的描述并不是应用程序设置脚本。相反，他们的基本意图是在不规定其命令的管道程序的情况下明确表达应用程序体系结构/结构（即描述什么而不是如何描述）。CBD范式的目的是通过这些框架来支持有效且灵活的应用程序组成，并让应用程序开发人员专注于业务逻辑和域问题，而无需低级管道复杂性。

结合声明应用程序描述和IOC技术的CBD框架称为IOC框架。与他们的前任相反，IOC框架是 非侵入性 并使用 依赖/配置注入/设置场景.

根据维基百科，基于组件的开发是 基于组件的软件工程（CBSE）.

IT]是软件工程的分支，其优先级是 关注点分离 关于整个给定软件系统的广泛功能。

这有点模糊，所以让我们看看更多细节。

单个组件是包装一组相关功能（或数据）的软件包或模块。

所有系统过程都放在单独的组件中，以便每个组件中的所有数据和功能都与语义相关（就像类的内容一样）。由于这一原则，经常说组件是 模块化的 和 凝聚力.

因此，根据这个定义，组件可以是任何东西，只要它真正做好一件事并且只做一件事。

关于全系统范围的协调，组件通过 接口. 。...]该原则导致所谓的组成部分 封装的.

所以这听起来越来越像我们认为好的 API 或 SOA 应该是什么样子。

这 假如 接口由棒棒糖表示， 必需的 接口由 UML 中附加到组件外边缘的开放套接字符号表示。

_{（来源： 维基媒体网站)}

组件的另一个重要属性是它们是 可替代的, ，以便可以将组件替换为另一个（在设计时间或运行时），如果后继组件满足了初始组件（通过接口表示）的要求（通过接口表示）。

可重用性是高质量软件组件的重要特征。应该设计和实施软件组件，以便可以在许多不同的程序中重复使用。

可替换性和可重用性是组件之所以成为组件的原因。那么这和面向对象编程有什么区别呢？

面向对象的编程（OOP）中的想法是，应该根据其代表的实际或想象对象的心理模型编写软件。[...]

相比之下，基于组件的软件工程没有任何假设，而是指出应该通过将预制的组件粘合在一起，就像电子或力学领域一样。

Answer 4

这是我在做了一些研究后的定义。

组件驱动开发 是软件开发中的一种方法，其中代码被分割成可重用和可测试的组件，这些组件组合在一起形成用于提供业务功能的应用程序基础。组件的组合和管理通常委托给 控制反转 容器。

组件本身是一个类，它实现一些服务契约并显式定义履行该契约所需的依赖关系。实际的实现对组件之外的其他人都是隐藏的。

相关链接：

• 组件驱动开发和 IoC 容器

Answer 5

我将基于组件的软件工程视为一种通过使用可插入组件来开发软件系统的方法；其组件为“仅具有合同指定的接口和显式上下文依赖关系的组合单元“， 哪个 ”可独立部署，可由第三方组成”（克莱门斯·西波斯基，“组件软件：超越面向对象编程")

CBSE 促进代码重用和灵活/适应性强的软件系统的快速组装。

多年来，已有大量研究集中在这个主题上。旗舰活动（ACM SIGSOFT 基于组件的软件工程研讨会）现在已经是第14个年头了，并且出现了很多新的趋势。

另外，如果您想要一个当今行业广泛使用的可重用、可插拔和可扩展组件的好例子，请查看 微软企业库.

Answer 6

如果您有兴趣将组件（或其他可重用资产）组合到应用程序中，您还应该看看 软件产品线 方法。

在软件产品线中，组件（或较低级别的代码元素）之间的依赖关系在这些组件之外进行显式管理。这通常是使用 特征模型 其中包含诸如

• 这两个组件不得一起使用（互斥）
• 如果使用此组件，则必须使用其他组件或（相互依赖）
• 可以使用某些指定组件集的任意组合（可选）

根据您希望建模的依赖关系的复杂性，其他更复杂的规则也是可能的。

有时代替特征建模使用的另一种方法是使用代码生成器来配置要组装到最终应用程序中的不同组件。还可以将特征建模与代码生成结合起来。

除了代码生成之外，您可能还会搜索一些其他术语，例如特定领域建模、模型驱动软件开发、软件系列。

Answer 7

在您尝试使用 Unity 3D 之前，您永远不会理解什么是真正的组件驱动开发。它不是ActiveX或您以前见过的任何东西，您以前见过的东西有另一种组件含义。

组件驱动开发，最近每个人都在谈论，意味着，你有两件事：

1. 目的 - 这就像 OOP 编程中的对象或现实世界的对象。
2. 对象的组件 - 这就像对象功能的一部分或其能力之一。

因此： 组件 - 不是对象。它是——对象的功能.

因此，在标准的OOP编程中，当您需要使用新功能扩展基础对象时，您必须通过继承基础对象来创建新的派生对象。

在组件驱动开发中，当您需要扩展对象时，您只需创建空对象并用不同的组件填充它，无需任何继承。在组件驱动开发中没有类，只有 预制件 相反 - 这是带有预定义组件和子对象的预定义对象。

正如我所说，除非你尝试，否则你永远不会理解。通过组件驱动开发，您不必总是使用编程，您可以使用图形编辑器来代替，并且它还使您摆脱了典型 OOP 的继承地狱。组件本身是用通常的编程方式编写的，但更高层的系统，包括对象，大多只需要在编辑器中使用和组合组件并接收自定义的对象行为。

因此：组件驱动开发为您提供：

1. 只需使用编辑器即可创建程序逻辑的强大功能，无需编程。
2. 将您的思想从 OOP 继承地狱中解放出来。使开发更加简单、快速。
3. 使您的程序具有高度可定制性和可扩展性，甚至无需接触代码。更少的错误和错误。
4. 只需重新编程特定组件即可更轻松地维护程序代码，而不会过多影响其余系统。
5. ETC...

我还想补充一点，基于组件（驱动）的编程并不是 OOP 编程的替代品，它是 OOP 或通常编程的基础。CBP 中仍然使用通常的编程来实现低级组件。我认为这篇文章对 CBP 也有很好而简短的解释： http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf