inversion-of-control - 什么是组件驱动开发？

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。

您正在寻找的答案可能会在Ke Jin的Why and what of Control of Control中找到。

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

基于组件的开发 (CBD) 范式通过将管道逻辑转移到框架中来解决上述两个问题，这些框架根据用户/开发人员提供的声明性描述来操作组件和设置应用程序。与常见的混淆相反，这种声明性描述并不意味着是应用程序设置脚本。相反，它们的基本意图是明确表达应用程序体系结构/结构，而不强制要求它们的命令式管道过程（即描述什么而不是如何）。CBD 范式的目标是通过这些框架支持有效和灵活的应用程序组合，并让应用程序开发人员专注于业务逻辑和领域问题，而无需考虑低级管道复杂性。

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

根据 Wikipedia，基于组件的开发是基于组件的软件工程 (CBSE)的别名。

[它] 是软件工程的一个分支，其优先级是在给定软件系统中可用的广泛功能方面的关注点分离。

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

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

所有系统进程都放置在单独的组件中，因此每个组件内的所有数据和函数在语义上都是相关的（就像类的内容一样）。因为这个原则，人们常说组件是 模块化的和内聚的。

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

关于系统范围的协调，组件通过接口相互通信。[...] 这个原则导致组件被称为封装。

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

提供的接口由棒棒糖表示，所需的接口由连接到 UML 中组件外边缘的打开套接字符号表示。

_{（来源：wikimedia.org）}

组件的另一个重要属性是它们是可 替换的，因此如果后续组件满足初始组件的要求（通过接口表示），那么一个组件可以被另一个组件替换（在设计时或运行时）。

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

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

面向对象编程 (OOP) 的理念是软件应该根据它所代表的实际或想象对象的心智模型来编写。[...]

相比之下，基于组件的软件工程没有做出这样的假设，而是指出应该通过将预制组件粘合在一起来开发软件，就像在电子或机械领域一样。

Answer 4

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

组件驱动开发是软件开发中的一种方法，其中代码被分割成可重用和可测试的组件，这些组件组合在一起形成用于交付业务功能的应用程序基础。组件的组合和管理通常委托给Inversion of Control Container。

组件本身是一个类，它实现了一些服务契约，并明确定义了它为了履行这个契约而需要的依赖关系。实际的实现对组件之外的其他人是隐藏的。

相关链接：

• 组件驱动开发和 IoC 容器

Answer 5

我认为基于组件的软件工程是一种通过使用可插拔组件来开发软件系统的方法；组件是“仅具有合同指定的接口和明确的上下文依赖关系的组合单元”，“可以独立部署并受第三方组合的约束”。（Clemens Szyperski，“组件软件：超越面向对象编程”）

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

多年来，有大量研究集中在这个主题上。旗舰活动（ACM SIGSOFT Symposium on Component Based Software Engineering）现在已经是第 14 年了，并且出现了很多新趋势。

此外，如果您想要一个很好的可重用、可插拔和可扩展组件示例，这些组件在当今工业界大量使用，请查看MS Enterprise Library。

Answer 6

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

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

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

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

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

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

Answer 7

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

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

1. 对象- 就像 OOP 编程中的对象或现实世界的对象。
2. 对象的组件——类似于对象功能的一部分或其中一项能力。

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

因此，在标准的 OOP 编程中，当您需要扩展 Base Object 的新功能时，您必须通过继承 Base Object 来创建新的 Derived Object。

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

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

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

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

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