“深”结构的 FluentNH 映射关系模型到“扁平”模型域对象
故事是这样的：一个站点（感兴趣的物理位置）有零个或多个联系人。这些联系人是与公司相关的人员，他们被授权处理与网站相关的事务。
该架构如下所示：
Person -< CompanyContact -< CompanySiteContact >- Site
||
| -< PersonPhone
|
-< PersonAddress
我的入口点是站点。我需要联系人列表。在到达 Person 之前，您感兴趣的现场数据非常少。因此，我想将 Person、CompanyContact 和 CompanySiteContact 折叠到一个域类中。
我提出的选项：
创建一个域类并在 FluentNH 映射中使用联接来在检索数据时展平图层 。这听起来从来都不简单，而且我遇到了多级联接的问题（如果 A 联接 B 联接 C，则不能在联接 B 中指定联接 C）。然而，我认为，如果可以指定联接，那只是一次性的事情，因此这最终将成为最可维护的解决方案。
在一组“DTO”中复制深度模型，这些“DTO”以 1:1 的比例映射到表，并且可以传递给“平面”域模型的构造函数。它有效，但感觉就像作弊（没有问题不能用另一层抽象来解决，除非有太多抽象层），我的直觉告诉我，这最终会以某种方式导致比它解决的问题更多的问题。< /p>
使用架构以 1:1 的比例复制域模型，并使用 CompanySiteContact 上的传递属性来访问人员记录深处的属性。同样，现在可以工作，但它并没有真正解决问题，并且每个感兴趣的新属性都需要更改映射、实际域类和顶级域类。不是很可靠。
那么，问题是，我将如何构建映射？就像我说的，我无法在连接中指定连接。我认为我必须做的方法是映射每个表的 PK，并在顶层的下一个连接中使用它，但我不太确定如何设置它（还没有使用 FluentNH 来设置之前任何接近这个复合体的东西）。
Here's the story: a Site (physical location of interest) has zero or more Contacts. Those Contacts are people associated with a Company who are authorized to deal with matters regarding the Site.
The schema looks like:
Person -< CompanyContact -< CompanySiteContact >- Site
||
| -< PersonPhone
|
-< PersonAddress
My entry point is Site. I need the list of Contacts. There is very little field data of interest until you get to Person. So, I'd like to collapse Person, CompanyContact and CompanySiteContact into one domain class.
The options I've come up with:
Create one domain class and use joins in the FluentNH map to flatten the layers as it retrieves the data
. It never sounded simple, and I'm running into problems with the multi-level join (if A joins B joins C, you can't specify the join to C within the join to B). I think, however, that if it's possible to specify the joins, that's just a one-time thing and so this will end up being the most maintainable solution.Replicate the deep model in a set of "DTOs" that map 1:1 to the tables and can be passed to the constructor of a "flat" domain model. It works, but it feels like cheating (there is no problem that cannot be solved with another layer of abstraction, EXCEPT for having too many layers of abstraction), and my instinct tells me this will somehow eventually cause more problems than it solves.
Replicate the domain model 1:1 with the schema and use pass-through properties on CompanySiteContact to access properties down in the depths of a Person record. Again, works now, but it doesn't really solve the problem, and every new property that becomes of interest will require changes to the mapping, the actual domain class, AND the top-level domain class. Not very SOLID.
So, the Q is, how would I structure the mapping? Like I said, I'm not able to specify a join in a join. I think the way I have to do it is map the PK of each table, and use it in the next join from the top level, but I'm not exactly sure how to set that up (haven't used FluentNH to set up anything close to this complex before).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议创建域模型以紧密匹配您的数据库。从那里我将创建 DTO 并使用 AutoMapper 进行扁平化。简单的。
I'd recommend creating your domain model to closely match your database. From there I'd create DTOs and use AutoMapper to do the flattening. Easy.
感谢詹姆斯的回答； +1，但我不认为 AutoMapper 在这个时刻是必要的，而且我对包含一些“自动”完成这项工作的东西感到有点不安。我想到了更多选项：
在数据库中设置一个视图。这是可行的，因为由于业务规则，联系信息是只读的；我正在开发的应用程序绝不能直接更新联系人，因为不同的部门维护此名片夹。
按照 James 的建议，将我的域 1:1 映射，然后使用 Linq 查询将模型扁平化为 DTO。该查询可以封装在存储库的帮助程序中，允许开发人员使用存储库上与其他类相同的方法直接查询 DTO。它比具有相同结果的视图更复杂，但不需要架构更改。
我可能会选择第一个选项，如有必要，我会采取第二个选项。
Thanks to James for his answer; +1, but I don't think AutoMapper is necessary at this juncture, and I'm a little uneasy at including something that does the job quite that "automagically". I thought of a few more options:
Set up a view in the DB. This will work because due to business rules, the contact information is read-only; the app I'm developing must never update a contact directly because a different department maintains this rolodex.
Map my domain 1:1 as James suggested, but then use a Linq query to flatten the model into a DTO. This query can be encapsulated within a helper of the Repository, allowing developers to query the DTO directly using the same methods on the Repository as for other classes. It's more complex than the view with the same result, but it doesn't require schema changes.
I'll probably go with the first option, and resort to the second if necessary.