本文是小编为大家收集整理的关于为什么我应该将我的领域实体与我的表现层隔离？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
领域驱动设计中似乎没有太多细节的部分是，您应该如何以及为什么应该将您的领域模型与您的界面隔离开来.我试图说服我的同事这是一个很好的做法，但我似乎没有取得太大进展......
他们在表示层和界面层中随心所欲地使用域实体.当我向他们争辩说他们应该使用显示模型或 DTO 将域层与界面层隔离时，他们反驳说他们没有看到这样做的商业价值，因为现在你有一个 UI 对象要维护以及原始域对象.
所以我正在寻找一些具体的理由来支持这一点.具体来说:
- 为什么我们不应该在表示层中使用域对象?
(如果答案很明显，"解耦"，那么请解释为什么这在这种情况下很重要) - 我们是否应该使用额外的对象或构造来将我们的领域对象与接口隔离开来?
推荐答案
很简单，原因是执行和漂移之一.是的，您的表示层需要了解您的业务对象才能正确表示它们.是的，最初看起来这两种对象的实现之间有很多重叠.问题是，随着时间的推移，双方的事情都会增加.表示发生变化，表示层的需求演变为包括完全独立于业务层的事物(例如颜色).同时，您的域对象会随着时间而变化，如果您没有与接口进行适当的解耦，您可能会因对业务对象进行看似良性的更改而搞砸接口层.
就我个人而言，我认为处理事物的最佳方式是通过严格执行的接口范式；也就是说，您的业务对象层公开了一个接口，这是可以与之通信的唯一方式；没有公开有关接口的实现细节(即域对象).是的，这意味着您必须在两个位置实现域对象；你的接口层和你的BO层.但是这种重新实现，虽然最初看起来像是额外的工作，但有助于加强解耦，这将在未来的某个时候节省大量的工作.
问题描述
One part of domain-driven design that there doesn't seem to be a lot of detail on, is how and why you should isolate your domain model from your interface. I'm trying to convince my colleagues that this is a good practice, but I don't seem to be making much headway...
They use domain entities where ever they please in the presentation and interface layers. When I argue to them that they should be using display models or DTOs to insulate the Domain layer from the interface layer, they counter that they don't see the business value in doing something like that, because now you have a UI object to maintain as well as the original domain object.
So I'm looking for some concrete reasons I can use to back this up. Specifically:
- Why should we not use domain objects in our presentation layer?
(if the answer is the obvious one, 'decoupling', then please explain why this is important in this context) - Should we use additional objects or constructs to isolate our domain objects from the interface?
推荐答案
Quite simply, the reason is one of implementation and drift. Yes, your presentation layer needs to know about your business objects to be able to represent them properly. Yes, initially it looks like there is a lot of overlap between the implementation of the two types of objects. The problem is, as time goes on, things get added on both sides. Presentation changes, and the needs of the presentation layer evolve to include things that are completely independent of your business layer (color, for example). Meanwhile, your domain objects change over time, and if you don't have appropriate decoupling from your interface, you run the risk of screwing up your interface layer by making seemingly benign changes to your business objects.
Personally, I believe the best way to approach things is through the strictly enforced interface paradigm; that is, your business object layer exposes an interface that is the only way that it can be communicated with; no implementation details (i.e. domain objects) about the interface are exposed. Yes, this means that you have to implement your domain objects in two locations; your interface layer and in your BO layer. But that reimplementation, while it may initially seem like extra work, helps enforce the decoupling that will save TONS of work at some point in the future.
更多相关问答
联系站长