我对罗伯特·马丁关于"Architecture: The Lost Years"的谈话很感兴趣。在其中，他讨论了MVC所基于的实体，边界，控制设计模式。我喜欢推迟建筑决策的想法。他描述了如何在自己的wiki应用程序FitNesse中推迟实现数据库层的决定。我已经在我自己的编码中有机地推迟了这样的决定，尽管没有一个先入为主的模块化设计带来了这个。
我想从实际的角度更好地理解这个EBC架构（它似乎与DCI密切相关），以便我可以开始在一个小项目中使用。我想利用＆＃34;推迟决定＆＃34;以及像UI一样交换设计方面的能力。
例如，Rails使用EBC（MVC）的一种形式，但它非常难以理解，因为它无法轻易替换备用UI，从而将Rails应用程序转换为控制台应用程序或桌面应用程序。关于设计的有趣之处在于，我可以通过交换一个东西并插入另一个来转换应用程序。也就是说，我想知道设计一个架构的想法，以便在某种程度上可以换掉UI或持久层。我觉得如果这个架构设计得很好，那么耦合会很低，而且这样的壮举将会被掌握。我已经在他的演讲中提到过Ivar Jacobson的the book。我在网上搜索了不少，但我发现的所有例子都显示了简单的图表。我说代码。通过查看一些演示概念的简单类，并通过使用边界类展示如何将一个层（UI，DB）替换为其他实现，我将从中受益更多。
如果有人无法向我指出一个说明这一点的好资源，那么这很难鞭打吗？也许我们可以使用许多软件书中使用的备用示例：视频租赁商店（这些天几乎是遗物）。请演示如何交换UI或DB层。令我困惑的一件事是观点。我无法从图中看出，我看到的是视图是边界类本身还是只是与它们进行通信。此外，鲍勃提到EBC的初衷是我们有很多微视图而不是单一的宏观视图（就像我们在典型的MVC中所做的那样）;我很好奇这可能是什么样子。 （我更喜欢Ruby或JavaScript，但是，因为乞丐不能选择，所以任何例子都可以。）
谢谢。
答案 0 :(得分：23)
据我所知，Bob叔叔使用“EBI”（实体，边界和 Interactor ）的视频应该完全解耦来自框架/操作系统和服务的业务行为/状态。
因此，在Rails应用程序的情况下，您的业务行为/状态完全没有依赖于 Rails 框架，因此可以像使用rspec一样进行测试而不需要激活Rails！
所以在业务方面，你有 Boundary 类，它们使用请求和响应模型与Rails端进行交互（非常简单的数据持有者，不能与 Rails中的常用模型交换）。只有边界类与实现（业务）用例/方案的 Interactor 类进行交互。并且只有 Interactor 类与封装业务状态的 Entity 类进行交互。
在 Rails 一侧，您会找到与边界类（使用请求模型）交互的控制器类，并向后转移边界 class与 Presenter 交互（使用Response模型）。只有演示者/控制器与视图交互（借助模型（再次简单的数据持有者）。请注意，在 Rails 演示者领域很可能控制器。
这在哪里留下AR？那么AR只提供持久的服务。在与 Presenter / Controller 级别相同的级别上，您会找到服务类，这些类为边界类提供服务。因此，他们提供所有必要的服务，这些服务是框架/ OS /技术依赖，如持久性，安全性，时间安排，通知等。
使用此架构，您可以重用业务逻辑并完全替换UI或数据库技术。例如，移植到移动设备（iOS，Android，Windows）应该非常简单。
使用 Rails ， app文件夹可能如下所示：
app/
controllers/ Only these interact with Boundary classes
models/ simple data-holders, no AR here! (see services)
views/
services/ AR-stuff
boundaries/ To be tested without Rails
models/ Request & Response
interactors/ use cases / scenarios, to be tested without Rails
entities/ "the real business model without technical dependencies"
使用这种架构，您需要更多代码，但不要忘记良好架构的好处：
最后注意：与MVC模式相比，它更像是M被EBI取代，C可以在CP / resenter中分割，并且添加了S（服务）。所以这可以被称为：VCPS / EBI，但这对我来说听起来很丑陋;-) BEPVICS可能吗？
@Seralize ，感谢您的反馈。
让我试着回答你的问题，到目前为止我理解它们：服务中的东西与Rails相关联。它们为EBI方面的逻辑提供了实现。在安全性的使用中，您必须明确您拥有的（量化的）需求，因此您知道可以在EBI方面实现的逻辑，例如（业务）规则关于用户（角色）何时可以访问哪些内容（并需要进行身份验证）。
这意味着实现身份验证将使用Rails实现，此服务将由EBI使用。 EBI中的这种安全相关逻辑很容易在Java GUI示例中重用。在那里，您只需要重新实现身份验证服务。
在安全示例中要明确：
EBI方面有逻辑：什么东西需要什么样的安全性以及何时以及如何。 Rails对此一无所知，它要求EBI方面做什么，或者EBI方要求Rails方采取行动。
Rails方面只实现了如何执行安全性的方式，例如要求用户进行身份验证（在需要时）并将结果传递给EBI，以便逻辑可以决定接下来应该做什么。
EBI要求双方脱钩。独立。就像你一样 正在开发EBI作为具有已定义API的库。
答案 1 :(得分：5)
问你，你会收到。我一直睁着眼睛，发现了Avdi Grimm的资源：
http://avdi.org/devblog/2011/11/15/early-access-beta-of-objects-on-rails-now-available-2/
在其中，他介绍了Rails项目与框架和ActiveRecord紧密耦合的一些原因。他使用TDD来确保与
等技术的松散耦合它以实用的方式回答这个问题提供了良好的开端。 （早期测试版售价5美元，但最终会免费。）事实上，这是我发现的第一个资源。请添加您找到的任何其他人。
这是揭示问题核心的真正宝石：
有一天，经过多年的见证和解决各种成熟的Rails代码库中由于ActiveRecord启发的紧密耦合而产生的技术债务，我有了一个顿悟。如果我们不再将ActiveRecord视为模型类的主干，而是将ActiveRecord编程为仅仅是私有实现细节，那该怎么办？
Corey Haines用另一种方式说明：
我将我的模型中的行为拉到包装模型的其他对象中。 我更喜欢让AR对象围绕数据库中的db-access内容进行简单的包装。
我有一个相当严格的规则，即控制器动作不能使用AR查找器，或者 事实上，根本就与AR互动。应该在api方法中访问AR 在你的模特里面，而不是从外面。
答案 2 :(得分：2)
这也应该引起关注。这是另一本书，"Architecture: The Lost Years"
中未提及名称“敏捷软件开发：原则，模式和实践”，“鲍勃叔叔”马丁。