关于ruby on rails：使用EBC的架构的实际例子？


Practical example of architecture using EBC?

我对罗伯特·马丁关于"建筑：逝去的岁月"的谈论很感兴趣。在本文中，他讨论了MVC所基于的实体、边界、控制设计模式。我喜欢推迟体系结构决策的想法。他描述了推迟如何在自己的wiki应用程序fitness中实现db层的决定。我在自己的代码中有组织地推迟了这样的决定，尽管没有一个预想的模块化设计能实现这一点。

我想从实践的角度更好地理解这个EBC架构(它似乎与DCI密切相关)，以便我可以开始在一个小项目中使用。我想利用"延迟决策"和交换诸如UI等设计方面的能力。

例如，Rails使用了EBC(MVC)的形式，但是它是如此的严格，以至于人们无法轻易地替换一个可选的UI，从而将Rails应用程序转换为控制台应用程序或桌面应用程序。对我来说，设计的有趣之处在于，它能够通过交换一件东西和插入另一件东西来转换应用程序。也就是说，我想知道设计一个架构的想法，这样人们就可以以某种方式交换UI或持久层。我觉得如果架构设计得很好，耦合度就会很低，这样的一个壮举就在掌握之中。

我已经订购了鲍勃在谈话中提到的伊瓦尔·雅各布森的那本书。我在网上搜索了不少，但我找到的所有示例都显示了简单的图表。我会说代码。我将从一些简单的类中获益更多，这些类演示了这个概念，并展示了如何通过使用边界类将一个层(UI、DB)替换为其他一些实现。

如果有人不能给我指出一个很好的资源来说明这一点，这会很难振作起来吗？也许我们可以使用许多软件书籍中使用的备用示例：视频租赁商店(现在几乎是一个遗迹)。请演示如何交换UI或DB层。让我困惑的一件事是观点。我无法从我看到的图表中分辨出视图是边界类本身还是它们只是与它们通信。此外，Bob提到，EBC的最初目的是拥有大量的微观视图，而不是单一的宏观视图(就像在典型的MVC中那样)；我很好奇这会是什么样子。(我喜欢Ruby或Javascript，但因为乞丐不能挑三拣四，所以任何例子都可以。)

谢谢您。

相关讨论

据我了解，Bob叔叔使用"ebi"(实体、边界和交互方)的视频，您应该将业务行为/状态与框架/操作系统和服务完全分离。

因此，对于Rails应用程序，您的业务行为/状态完全不依赖于Rails框架，因此可以像使用rspec一样进行测试，而无需触发Rails！

因此，在业务方面，您有使用请求和响应模型(非常简单的数据持有者，不需要与来自Rails的常规模型交换)与Rails端交互的边界类。只有边界类与实现(业务)用例/场景的交互程序类交互。并且只有交互类与封装业务状态的实体类交互。

在Rails一侧，您发现控制器类与边界类交互(使用请求模型)，而边界类向后与演示者交互(使用响应模型)。只有演示者/控制器与视图交互(借助于模型(同样是简单的数据持有者)。请注意，在Rails领域中，演示者最有可能是控制器。

这把枪放哪儿了？嗯，AR只是提供持久的服务。在与演示者/控制器级别相同的级别上，您将找到为边界类提供服务的服务类。因此，它们提供所有必要的服务，这些服务依赖于框架/操作系统/技术，如持久性、安全性、时间安排、notifaction等。

使用这个体系结构，您真正能够重用业务逻辑，并完全取代UI或数据库技术。例如，移植到移动设备(iOS、Android、Windows)应该是非常直接的。

有了Rails，您的应用程序文件夹可能看起来像：

1
2
3
4
5
6
7
8
9
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/Reseter中拆分，并添加了一个S(服务)。所以这可以称为：VCPS/EBI，但这听起来很难听；-)也许是BEPVIC？

    @Seralize，谢谢你的反馈。

    让我试着回答您的问题，到目前为止，我理解它们：服务中的内容与Rails耦合在一起。它们提供了EBI端逻辑的实现。在使用安全性的情况下，您必须清楚您有哪些(量化的)需求，这样您就知道可以在EBI端实现什么逻辑，例如(业务)规则，关于用户(角色)何时可以访问哪些内容(并且需要进行身份验证)。

    这意味着实现身份验证将使用Rails实现，EBI将使用此服务。在您的Java GUI示例中，安全相关的EBI逻辑很容易重用。在那里，您只需要重新实现身份验证服务。

    在安全示例中要明确：

    EBI方面的逻辑是：什么东西需要什么样的安全性，什么时候需要什么，如何需要。Rails对此一无所知，它请求从EBI端执行什么操作，或者EBI端请求Rails端执行操作。

    Rails端只实现了如何进行安全性的方法，比如请求用户(在需要时)进行身份验证，并将结果传递给EBI，这样逻辑就可以决定接下来应该做什么。

    EBI demands both sides to be decoupled & independent. It were as you
    are developing the EBI as a library with a defined API.

    相关讨论

    问问你就会收到。我睁大了眼睛，发现了这个资源，作者是艾维迪·格林：

    http://avdi.org/devblog/2011/11/15/early-access-beta-of-objects-on-rails-now-available-2/

    在本文中，他介绍了Rails项目与框架和ActiveRecord紧密耦合的一些原因。他使用TDD来确保与诸如

    • 依赖注入
    • 主持人
    • 战略模式
    • DCI

    它为以实际的方式回答这个问题提供了一个良好的开端。(早期测试版的费用是5美元，但最终将是免费的。)事实上，这是我发现的第一种资源。请加上你找到的其他。

    这是一块真正的宝石，它阐明了问题的核心：

    One day, after years of witnessing and addressing the technical debt incurred in various maturing Rails codebases as a result of ActiveRecord-inspired tight coupling, I had an epiphany. What if we stopped treating ActiveRecord as the backbone of our model classes, and instead, programmed as if ActiveRecord were merely a private implementation detail?

    科里·海恩斯换了一种说法：

    I pull the behavior out of my models into other objects that wrap the models.
    I prefer to make the AR objects simple wrappers around the db-access stuff in AR.

    I have a fairly strict rule that controller actions cannot use AR finders or,
    in fact, interact with AR at all. AR should be accessed within api methods
    inside your model, not from the outside.

    相关讨论

    这也应该引起人们的兴趣。这是另一本书，在《建筑：逝去的岁月》中没有提到它的名字。

    "敏捷软件开发：原则、模式和实践"，作者"Bob叔叔"Martin。

    摘自本SE问答。其他答案也请阅读。