使用EBC架构的实际例子吗？ [英] Practical example of architecture using EBC?
问题描述
我是由罗伯特·马丁的谈<一好奇href=\"http://confreaks.net/videos/759-rubymidwest2011-keynote-architecture-the-lost-years\">\"Architecture:失去的岁月。他在文中探讨了实体，边界，其上MVC是基于控制的设计模式。我喜欢推迟架构决定的想法。他描述推迟有关如何在执行DB层决定他自己的wiki应用FitNesse的。我已经推迟有机这样的决定在我自己的编码，虽然不是那么把这个约preconceived模块化设计。
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.
我已经下令由伊瓦雅各布森书鲍勃在他的讲话中提到。我在网上搜索了不少，但所有的我发现显示简单的图表中的例子。我讲code。我就从找过几个简单的类演示概念，并展示一个人如何可以通过使用边界类的其他一些实施换出一个层（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层，可以交换。一件事是困惑我的看法。我无法从我所看到的图或判断的意见是边界类本身，如果他们只是与他们沟通。此外，鲍勃提到，EBC的本意是，我们就会有大量的微观点不是一个单一的宏观视图（如我们在典型的MVC做）;我很好奇，这可能是什么样子。 （我preFER红宝石或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.)
感谢您。
推荐答案
据我了解使用EBI（由Bob大叔视频的实体 边界和交互器），你应该完全脱钩框架/ OS和服务的经营行为/状态。
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!
因此，在业务方面有边界类至极与Rails端使用的请求和响应模型（非常简单dataholders互动，而不是从的的Rails ）。只有在边界教学班，在交互器类实现了这个（业务）进行交互用例/场景。而且，只有在交互器教学班，在实体类其中封装业务状态进行互动。
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 的一面，你找到的控制器类与交互的边界类（使用请求模型）和倒退的边界类与 presenter （使用响应模型）进行交互。只有 presenters /控制器与视图（与模型的帮助（再简单的数据持有人）进行交互。请注意，在的Rails 的 $ p的境界$ psenters 最有可能的控制器
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 /控制器你会发现级别的服务要在边界类提供服务的类。因此，他们提供所有这是框架/ OS /技术依赖像持久性，安全性，定时，notifaction等。
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中）应该是pretty直线前进。
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 的，您的 app文件夹可能看起来像：
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"
在此架构下，你需要code多一点，但不要忘了一个良好的体系结构的优点：
With this architecture, you need to code a bit more but don't forget the benefits of a good architecture:
- 一个很好的架构允许大的变化
- 一个好的架构最大化（主要）的变化没有取得
要推迟
最后注：相对于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 ，感谢您的反馈意见。
@Seralize, thanks for your feedback.
让我试着回答你的问题，到目前为止，我理解他们：在服务的东西耦合到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此安全相关的逻辑是那么pretty容易在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屋！
