映射与服务层或业务逻辑位置
我得到了一个产品和一组付款人。付款人可以通过三种不同的方式支付产品费用，但可以通过付款人的收入或付款人各自持有的价值手动设置百分比。产品的支付方式由产品上的枚举确定。
在我的持久层中，我得到了三个类：Product、Payer 和 ProductManuallyPaid，如果产品是手动支付的，则这是 Product 和 Payer 之间的多对多类，指定每个付款人必须支付的百分比。
我应该如何将其映射到视图？我想要一个新的多对多类（其中包含对付款人的引用、对产品的引用以及付款人应支付的确切金额）？
我想计算应该在服务层中完成，但是服务层应该返回产品/付款人的 ViewModel/DTO 版本并附加一个新的多对多类，还是应该在之后处理？如果稍后处理，该实体是否应该包含该新多对多类的列表，但在持久层中被忽略？
I got a Product and a collection of Payers. The Payers can pay for the product in three different ways, either but manually set the percentage, by Payers income or by the value of the Payers respective holdings.How the product is paid is determined by an enum on the Product.
In my persistence layer i got three classes, Product, Payer, and ProductManuallyPaid which is a many-to-many class between Product and Payer if the Product is paid by manually, specifying the percentage each Payer will have to pay.
How should i map this to the view? I would like to have a new many-to-many class (which would consist of a reference to the Payer, a reference to the Product and the exact amount that payer should pay)?
I guess the calculation should be done in the Service Layer, but should the Service layer return a ViewModel/DTO version of the Product/Payer with a new many-to-many class attached, or should this be handled afterward? if it should be handled afterward, should the entity contain a list of that new Many-to-many class, but be ignored in the persistence layer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
DDD 可能建议您应该采用首先关注对象模型而不是 ER/数据模型的设计的思路。我看到您已经考虑过数据模型应该是什么样子（使用多对多表等），但也许您应该首先考虑对象模型应该是什么样子。然后，由于该对象模型反映了域（业务逻辑、业务行为），请考虑如何将该对象模型映射到数据库。
例如，退回包含付款集合的产品可能更有意义。每个付款都有一个到付款人实体的链接。根据您的设计，付款人链接可能具有您想要访问的付款人信息的副本，或者该链接可能知道如何使用必要的信息/值加载完整的付款人实体。
此外，每个 Payer 实例可能有一个 Payments 集合（甚至与上面相同的类类型？），它链接回产品。
这种设计比关系数据库更好地利用了 OO 原则并更好地描述了领域。此外，这些对象在服务和 UI 层中可能更容易处理，因为它们的本机对象结构已经在逻辑上为您提供了所需的东西。 IE。产品有付款方式，付款方式有付款人等。
我自己对 DDD 思维还算陌生。在 DDD 这个术语吓到您之前，先看看这个 Evan 的总结版本书。这是一本轻松读物，并且可以免费下载。它可能会给您一直在寻找的宝石。
DDD might suggest that you should adopt a line of thinking that focuses first and foremost on the design of the object model rather than the ER/data model. I see you have thought about how the data model should look (with the many-to-many table etc) but maybe you should consider how the object model might look first. Then as that object model reflects the domain (business logic, business behaviour), think about how you might map that object model to the database.
For example, it might make more sense to return a Product which has a collection of Payments. And each Payment have a link to the Payer entity. Depending on your design that Payer link may have copies of the Payer info you will want to access or perhaps that link knows how to load the full Payer entity with the necessary information/values.
Additionally, each Payer instance might have a collection of Payments (same class type as above even?) which link back to the Product.
This design makes better use of OO principals and describes the domain better than the ways a relational database might. Additionally, these objects may be easier to handle in the Services and UI layers as their native object structure already provides you logically with the things you need. ie. a Product has the Payments, which have the Payer, etc..
I'm reasonably new to DDD thinking myself. And before the term DDD scares you off, take a look at this summarised version of Evan's book. It's a light read and free to download. It may just give you the gems you have been looking for.