应用程序分层和DataMapper
您好，我刚刚读了《企业应用程序架构模式》一书。他们说你应该分层地执行企业应用程序，并且你不应该让一层只使用上面的一层，只使用下一层......就像域层可以使用数据库层，但反之则不然。然后有一章关于创建域对象的 DataMappers。我有点想知道为什么他可以让DB层的DataMapper在Domain层创建一个对象，因为它不遵循底层不调用上层的规则。所以我的问题是实际上不应该是数据库层中的域对象，或者在不使数据库层使用域层的情况下制作域对象的好方法是什么
Hi I just read the book Patterns of Enterprise Application Architecture . They say about you should do enterprise applications in layers and that you are not supposed to make one layer use the above layer only the layer that is one down... Like domain layer can use DB layer but not vice-versa. Then there is a chapter about DataMappers that create Domain Objects. There I am a bit wondered why can he make a DataMapper in DB layer create an object in Domain Layer since it is not following the rule that the bottom doesnt call the upper. So my question is shouldn't be domain objects actually in DB layer , or what is a good way to make domain objects without making the DB layer use domain layer
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为这里的问题是您对域模型做出了一些假设。
根据书中提到的，数据映射器实际上只需要丰富的域模型，在这种情况下，最好不要使用实体 bean 作为域模型，而是使用 POJO。
现在，如果您这样做，我认为数据映射器和域模型类位于持久层（由 DAO 和实体组成）之上的同一层中。在这种情况下，数据映射器不会对数据库进行任何直接操作。
另一方面，如果域模型基于实体，那么我认为它也是持久层的一部分，并且数据映射器在这种情况下也履行了 DAO 的角色，因此它们都是（在至少部分）在同一层。
最好的解决方案是什么？根据这本书，我想说仅在非常简单的情况下才使用实体作为域模型才有意义，对于任何复杂的情况都分开（请参阅该书第 9 章中的域模型）
I think the problem here is that you make some assumptions about the Domain Model.
As per the book you mention a Data Mapper is really only required by a rich Domain Model, and in this case the best would be not to use entity beans as a Domain Model, but to use instead POJOs.
Now if you go this way, I'd argue that the Data Mapper and the Domain Model classes reside in the same layer, on top of the persistence layer (which is made out of DAOs and entities). The Data Mapper doesn't do any direct work with the database in this case.
If on the other hand, the Domain Model is based on entities, then I'd argue that it is also part of the persistence layer and the Data Mapper also fulfills the role of the DAO in this case, so again they are both (at least partially) in the same layer.
What's the best solution? As per the book I'd say it makes sense to use entities as Domain Model only in the very simple of the cases, go separate for anything complex (see Domain Model in Chapter 9 of that book)
解决您发现的问题的一种方法是在域对象和数据库之间使用抽象层。
简而言之，它是依赖倒置/注入。
您定义一个接口，定义数据提供者可以执行的所有操作，然后构建实现该接口的具体数据提供者，并且业务逻辑/域层与之对话。这样你就不会受到数据库的束缚。
然后，您可以在业务逻辑/数据对象和接口之间构建数据映射器（如果您想重用它），或者如果需要特定于数据提供者的详细信息，则将其作为数据访问的一部分。
One approach to solve the problem you spotted would be to use a layer of abstraction between the domain objects and the database.
In a nutshell its dependency inversion / injection.
You define an interface the defines all the actions that a data provider can perform, you then build concrete data providers that implement the interface, and the business logic / domain layer talks to that. That way you're not tied to the database.
You can then build the data mapper in between the business logic / data objects and the interface (if you want to reuse it), or as part of the data access if it needs detail that is specific to the data provider.
我个人不同意领域模型是与其他层相同的层，因为它不包含任何行为，它只是与领域相关的实体/数据对象。
也就是说，我们不能得出它只对业务层特殊的结论，如果您使用某些ORM组件，很明显Domain-Model直接在您的数据库层中使用，因为它是内部自动映射的。
I personally do not agree that domain-model is a layer same to other layers, because it does not contains any behaviors, it is just a domain related entity / data object.
That is to say, we can not make the conclusion that it is special only to Business Layer, if you use some ORM component, it is clear that Domain-Model is used direct in your Database Layer, because it is auto-mapped internally.