使用 EBC 的架构的实际示例? [英] Practical example of architecture using EBC?

问题描述

罗伯特·马丁 (Robert Martin) 关于架构:失去的岁月".在其中，他讨论了 MVC 所基于的实体、边界、控制设计模式.我喜欢推迟架构决策的想法.他描述了在他自己的 wiki 应用程序 FitNesse 中推迟关于如何实现 DB 层的决定.我在自己的编码中有机地推迟了这样的决定，尽管没有先入为主的模块化设计带来了这一点.

I was intrigued by Robert Martin's talk about "Architecture: The Lost Years". In it he discusses the Entity, Boundary, Control design pattern on which MVC is based. I love the idea of deferring architectural decisions. He described deferring the decision about how to implement the DB layer in his own wiki app FitNesse. I have organically deferred decisions like this in my own coding, though there wasn't a preconceived modular design that brought this about.

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

I want to better understand this EBC architecture (which seems closely related to DCI) from a practical standpoint so that I can begin using in a small project. I want to capitalize on "deferring decisions" and the ability to swap out aspects of the design like the UI.

例如，Rails 使用 EBC (MVC) 的一种形式，但它非常成熟，无法轻易替代替代 UI，从而将 Rails 应用程序转换为控制台应用程序或桌面应用程序.对我来说，关于设计的有趣之处在于这种通过交换一个东西并插入另一个东西来转换应用程序的能力. 也就是说，我想知道设计一个架构的想法，这样人们就可以，从某种意义上说，换掉 UI或持久层.我觉得如果架构设计的好，耦合度会很低，这样的壮举是可以掌握的.

Rails, for example, uses a form of EBC (MVC) but it's so heavily baked in that one could not easily substitute an alternate UI thus converting a Rails app to a console app or a desktop app. The intriguing thing about design for me is this ability to transform applications by swapping one thing out and plugging another in. That is, I wonder at the idea of designing an architecture so that one can, in a manner of speaking, swap out the UI or the persistence layer. I feel that if the architecture is well designed, the coupling will be low, and such a feat will be within grasp.

我已经订购了 Ivar 的这本书鲍勃在演讲中提到的雅各布森.我在网上搜索了很多，但我发现的所有示例都显示了简单的图表.我说代码.通过查看一些演示概念的简单类，并展示如何通过使用边界类将一层(UI、DB)替换为其他一些实现，我会受益更多.

I've ordered the book by Ivar Jacobson that Bob mentioned in his talk. I've search online quite a bit but all of the examples I've found show simple diagrams. I speak code. I would benefit more from looking over a few simple classes that demonstrate the concept and show how one might swap out one layer (UI, DB) for some other implementation through the use of boundary classes.

如果有人不能给我指出一个很好的资源来说明这一点，这会很难吗?也许我们可以使用许多软件书籍中使用的待机示例:视频租赁店(现在几乎是一个遗物).请演示如何交换 UI 或 DB 层.让我感到困惑的一件事是观点.我无法从我看到的图表中分辨出视图是边界类本身还是它们只是与它们通信.此外，Bob 提到 EBC 的初衷是我们有很多微视图而不是单个宏视图(就像我们在典型的 MVC 中所做的那样)；我很好奇这会是什么样子.(我更喜欢 Ruby 或 JavaScript，但由于乞丐不能挑剔，任何例子都可以.)

If someone can't point me to a good resource illustrating this, would this be hard to whip up? Maybe we could use the standby example used in lots of software books: a video rental store (almost a relic these days). Please demonstrate how the UI or DB layer could be swapped. One thing that's confusing me is views. I can't tell from the diagrams I've seen if the views are the boundary classes themselves or if they just communicate with them. Also, Bob mentioned that the original intent of EBC was that we'd have lots of micro-views not a single macro-view (as we do in typical MVC); I'm curious what this might look like. (I prefer Ruby or JavaScript but, as beggars can't be choosers, any example would be fine.)

谢谢.

推荐答案

据我所知，Uncle Bob 使用EBI"(Entity，Boundary，和 Interactor) 您应该将您的业务行为/状态与框架/操作系统和服务完全分离.

As far as I understand the video by Uncle Bob using "EBI" (Entity, Boundary, and Interactor) you should completely decouple your business behavior/state from frameworks/OS and services.

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

So in case of an Rails app your business behavior/state is completly free of dependencies to the Rails framework and hence can be tested like with rspec without firing Rails!

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

So on the business side you have Boundary classes wich interact with the Rails side using request and response models (very simple dataholders, not to be exchanged with the usual models from Rails). Only the Boundary classes interact with the Interactor classes which implement the (business) use cases / scenarios. And only the Interactor classes interact with the Entity classes which encapsulate the business state.

在Rails 一侧，您会发现Controller 类与Boundary 类(使用请求模型)进行交互，并向后一个Boundarystrong> 类与 Presenter(使用响应模型)交互.只有 Presenters/Controllers 与 Views 交互(在模型的帮助下(同样是简单的数据持有者).请注意，在 Rails Presenters 领域很可能是控制者.

On the Rails side you find Controller classes interacting with Boundary classes (using Request models) and backwards a Boundary class interacts with a Presenter (using a Response model). Only Presenters/Controllers interact with Views (with the help of models (again simple data-holders). Note that in the realm of Rails Presenters are most likely Controllers.

这让 AR 何去何从?那么AR只是提供持久化服务.在与 Presenter/Controller 级别相同的级别上，您会找到向 Boundary 类提供服务的 Service 类.因此，它们提供所有必要的服务，这些服务依赖于框架/操作系统/技术，例如持久性、安全性、计时、通知等.

Where does this leave AR? Well AR just provides the persistant service. On the same level as the Presenter/Controller level you will find Service classes which provide their services to the Boundary classes. So they provide all the necessary services which are frameworks/OS/technology dependent like persistance, security, timing, notifaction, etc..

通过这种架构，您真的能够重用您的业务逻辑并完全取代 UI 或数据库技术.例如，移植到移动设备(iOS、Android、Windows)应该非常简单.

With this architecture you are really able to reuse your business logic and completely replace the UI or database technology. For example, porting to mobile (iOS, Android, Windows) should be pretty straight forward.

使用Rails，您的应用文件夹可能如下所示:

With Rails, your app folder could look like:

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"

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

With this architecture, you need to code a bit more but don't forget the benefits of a good architecture:

1. 良好的架构可以推迟重大更改
2. 好的架构可以最大限度地提高(主要)未进行的更改

最后一点:与MVC模式相比，它更像是将M替换为EBI，C可以在CP/resenter中拆分)，并添加了一个S(服务).所以这可以称为:VCPS/EBI，但这对我来说听起来很难看；-) BEPVICS 可能?

Last note: compared to the MVC pattern, its more like the M is replaced by EBI, the C can be splitted in CP/resenter), and an S(ervice) is added. So this could be called: VCPS/EBI but that sounds ugly to me ;-) BEPVICS maybe?

@Seralize，感谢您的反馈.

让我试着回答你的问题，到目前为止我理解它们:服务中的东西与 Rails 耦合.它们为 EBI 端的逻辑提供了实现.在安全用例中，你必须清楚你有什么(量化的)需求，所以你知道你可以在 EBI 端实现什么逻辑，例如关于用户(角色)何时可以访问什么内容的(业务)规则(并且需要进行身份验证).

Let me try to answer your questions, so far I understand them: the stuff in services are coupled to Rails. They provide the implementation for the logic in EBI side. In the usecase of security, you have to be clear what (quantified) requirements you have, so you know what logic you can implement on EBI side, for instance (business) rules about when a user(role) has access to what content(and needs to be authenticated).

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

This means to implement authentication will be implemented using Rails, this service will be used by EBI. This security related logic in EBI is then pretty easy to reuse in your Java GUI example. There you have only to reimplement the authentication service.

在安全示例中要清楚:

EBI 方面有一个逻辑:什么东西需要什么样的安全，何时以及如何.Rails 对此一无所知，它请求 EBI 端做什么，或者 EBI 端请求 Rails 端采取行动.

The EBI side has the logic: what stuff needs what kind of security and when and how. The Rails knows nothing about this, it request what to do from the EBI side and or the EBI side request the Rails side to act.

Rails 端只实现了如何确保安全的方式，例如要求用户进行身份验证(在需要时)并将结果传递给 EBI，以便逻辑可以决定下一步应该做什么.

The Rails side only implements the way how to do security like asking the user to authenticate (when needed) and passing the result of this to EBI so the logic can decide what should be done next.

EBI 要求双方解耦 &独立的.就像你一样正在将 EBI 开发为具有定义 API 的库.

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

这篇关于使用 EBC 的架构的实际示例?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！