使用EBC的架构的实际例子？

Question

罗伯特马丁关于"建筑:失落的岁月"的谈话引起了我的兴趣.在其中,他讨论了MVC所基于的实体,边界,控制设计模式.我喜欢推迟建筑决策的想法.他描述了如何在他自己的wiki应用程序FitNesse中推迟实现数据库层的决定.我已经在我自己的编码中有机地推迟了这样的决定,尽管没有一个先入为主的模块化设计带来了这个.

我想从实际的角度更好地理解这个EBC架构(它似乎与DCI密切相关),以便我可以开始在一个小项目中使用.我想利用"推迟决定"以及交换UI等设计方面的能力.

例如,Rails使用了一种EBC(MVC)形式,但是它非常出色,以至于无法轻松替换备用UI,从而将Rails应用程序转换为控制台应用程序或桌面应用程序.关于设计的有趣之处在于,我可以通过交换一个东西并插入另一个来转换应用程序.也就是说,我想知道设计一个架构的想法,以便在某种程度上可以换掉UI或持久层.我觉得如果这个架构设计得很好,那么耦合会很低,而且这样的壮举将会被掌握.

我已经下令这本书由伊瓦尔·雅各布森说鲍勃在他的讲话中提到.我在网上搜索了不少,但我发现的所有例子都显示了简单的图表.我说代码.通过查看一些演示概念的简单类,并通过使用边界类展示如何将一个层(UI,DB)替换为其他实现,我将从中受益更多.

如果有人不能指出一个很好的资源说明这一点,那么难以鞭打吗？也许我们可以使用许多软件书中使用的备用示例:视频租赁商店(这些天几乎是遗物).请演示如何交换UI或DB层.令我困惑的一件事是观点.我无法从图中看出,如果视图本身就是边界类,或者它们只是与它们进行通信.此外,鲍勃提到EBC的初衷是我们有很多微视图而不是单一的宏视图(就像我们在典型的MVC中所做的那样); 我很好奇这可能是什么样子.(我更喜欢Ruby或JavaScript,但是,由于乞丐不能选择,任何一个例子都可以.)

谢谢.

Answer 1

据我所知,Bob叔叔使用"EBI"(实体,边界和交互器)的视频应该完全将您的业务行为/状态与框架/操作系统和服务分离.

因此,在Rails应用程序的情况下,您的业务行为/状态完全没有依赖于Rails框架,因此可以像rspec一样测试而不需要激活Rails!

因此,在业务方面,您使用请求和响应模型(非常简单的数据持有者,不与Rails的常用模型交换)使用边界类与Rails端进行交互.只有Boundary类与实现(业务)用例/场景的Interactor类交互.并且只有Interactor类与封装业务状态的Entity类交互.

在Rails端,您可以找到Controller类与Boundary类交互(使用Request模型),然后返回Boundary类与Presenter交互(使用Response模型).只有Presenters/Controllers与Views交互(在模型的帮助下(同样是简单的数据持有者).请注意,在Rails Presenters领域很可能是控制器.

AR会在哪里留下AR？那么AR只提供持久的服务.在与Presenter/Controller级别相同的级别上,您将找到为Boundary类提供服务的Service类.因此,他们提供所有必要的服务,这些服务是框架/ 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"

使用这种架构,您需要更多代码,但不要忘记良好架构的好处:

1. 良好的架构允许延迟重大更改
2. 一个好的架构可以最大化(主要)改变

最后一点:与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的库.

Answer 2

问你应接受.我一直睁着眼睛,发现Avdi Grimm的这个资源:

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

在其中,他介绍了Rails项目与框架和ActiveRecord紧密耦合的一些原因.他使用TDD来确保松耦合等技术

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

它以实用的方式为回答这个问题提供了良好的开端.(早期测试版售价5美元,但最终会免费.)事实上,这是我发现的第一个资源.请添加您找到的任何其他人.

这是解释问题核心的真正宝石:

有一天,经过多年的见证和解决由于ActiveRecord启发的紧密耦合而在各种成熟的Rails代码库中产生的技术债务,我有了一个顿悟.如果我们停止将ActiveRecord视为模型类的主干,那么编程就好像ActiveRecord只是私有实现细节一样？

Corey Haines用另一种方式说:

我将模型中的行为拉到包装模型的其他对象中.我更喜欢让AR对象围绕AR中的db-access内容简单包装.

我有一个相当严格的规则,即控制器动作不能使用AR查找器,或者实际上与AR交互.AR应该在模型内的api方法中访问,而不是从外部访问.