使用 NHibernate是个好主意吗？来自部分多对多类？
我有一个 Shop 表、一个 StaffRole 表和一个 ShopStaffRole 表，该表用作多对多，但具有 StaffRole 等附加字段code>IsRequired 等。
Shop
ShopId
ShopName
ShopAddress
StaffRole
StaffRoleId
StaffRoleName
ShopStaffRole
ShopStaffRoleId
ShopId
StaffRoleId
IsRequired
所以我的选择似乎是 Shop 类和带有 NHibernate many-to-many 的 StaffRole 类> 之间的映射它们，但这不会在我的对象模型中很好地映射 IsRequired ，因此也有一个 ShopStaffRole 类和一对多 它与 Shop 和 StaffRole 之间的映射。
然而，经过仔细检查，StaffRole 表只有一个 Id 和一个 Name。仅使用 NHibernate join 来放置 StaffRoleName 是否有意义 直接作为字符串放入 ShopStaffRole 类中，并完全取消将 StaffRole 表表示为一个类？
我预计 StaffRoleName 不会在此应用程序中发生变化，因此我应该能够摆脱只读映射，以防止一个 ShopStaffRole 影响其他具有相同角色的角色员工角色名称。
这有意义吗，还是我错过了什么？感觉就像我的对象模型只是逐个表地模仿我的关系模型。
I have a Shop table, a StaffRole table, and a ShopStaffRole table that serves as many-to-many, but with additional fields like IsRequired, etc.
Shop
ShopId
ShopName
ShopAddress
StaffRole
StaffRoleId
StaffRoleName
ShopStaffRole
ShopStaffRoleId
ShopId
StaffRoleId
IsRequired
So my choices seem to be a Shop class and a StaffRole class with NHibernate many-to-many mapping between them, but that won't map IsRequired well in my object model, so it makes sense to have a ShopStaffRole class as well, and one-to-many mappings between it and both Shop and StaffRole.
However, upon closer inspection, the StaffRole table has only an Id and a Name. Would it make sense to just use an NHibernate join to put the StaffRoleName directly into the ShopStaffRole class as a string, and do away with representing the StaffRole table as a class altogether?
I don't anticipate the StaffRoleName changing within this application, so I should be able to get away with a read-only mapping that prevents one ShopStaffRole from affecting others with the same StaffRoleName.
Does this make sense, or am I missing something? It feels like my object model is just aping my relational model, table by table.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，我有点回答了我自己的问题。我不能说这样做从来都不是一个好主意，但我现在觉得有太多潜在的问题，所以它极不可能值得。
就我而言，我意识到虽然此应用程序不必担心
StaffRole更改，但稍后会有另一个表进入引用的StaffRole范围> 同样，如果我们想要查找商店的 StaffRole，然后查找该 StaffRole 所需的所有培训材料，那么在 StaffRole-ShopStaffRole 之间使用双向访问器将是一个好方法，并且员工角色-培训员工角色。As it turns out, I sort of answered my own question. I can't say it's never a good idea to do this, but I feel now like there are so many potential gotchas that it's extremely unlikely to be worthwhile.
In my case, I realised that although this application wouldn't have to worry about
StaffRolechanging, there would be another table that found its way into the scope later on that referencedStaffRoleas well, so if we ever wanted to look up a StaffRole of a Shop, then look up all the training material required by this StaffRole, then it would be a good way to have two-way accessors between StaffRole-ShopStaffRole, and StaffRole-TrainingStaffRole.只要冗余不是您最关心的问题，并且您以后不打算添加任何界面来管理角色，那么您就可以采用
Join方法。As long as the redundancy isn't your biggest concern and you're not going to add any interface to manage roles later then you're good to go with the
Joinapproach.