如何正确模拟这种多态性关联？
给定以下实体：
容器
用户
客户端
机构
容器实体通过属性AssignedToParties 与一个或多个参与方建立关联。
Container.AssignedToParties 可以包含用户、客户端和机构的组合。
这种关系的推荐域模型是什么？
我考虑过以下选项：
1）为每种类型创建单独的属性：
Container.AssignedToUsers
Container.AssignedToClients
Container.AssignedToInstitutions
这看起来相当不优雅，但不需要业务逻辑来检查类型或执行任何向下转换。
2) 为用户/客户端/机构创建一个公共基类“Party”
Container.AssignedToParties 将是 Party 实体的集合。这似乎是一个尴尬的解决方案，因为 Party 基类没有任何方法或属性。我也不确定我是否喜欢在这里添加一层继承的想法。
该解决方案与#3 一样，需要系统在运行时检查类型以做出决策，然后向下转换为用户/客户端/机构来处理它们。
3) 创建用户/客户端/机构实现的标记接口 IContainerAssignable
这至少会提供某种类型安全性，但需要类型检查和向下转型。
现在，我倾向于#3。这似乎是最简单的，但我在一些地方读到，如果您的代码正在运行必须测试给定类型的逻辑，那么您可能有一个糟糕的设计。
任何建议表示赞赏。
Given the following Entities:
Container
User
Client
Institution
The Container entity has an association to one or more parties through the property AssignedToParties.
Container.AssignedToParties can contain a mix of Users, Clients, and Institutions.
What is the recommened domain model for this relationship.
I had considered the following options:
1) Create separate properties for each type:
Container.AssignedToUsers
Container.AssignedToClients
Container.AssignedToInstitutions
This seems pretty inelegant, but does not require business logic to check the types or do any downcasting.
2) Create a common base class "Party" for User/Client/Institution
Container.AssignedToParties would then be a collection of Party entities. This seems like an akward solution since the Party base class wouldn't have any methods or properties. I'm also not sure I like the idea of adding one more layer of inheritance here.
This solution, like #3, would require the system to check the types at runtime to make decisions and then downcast to either User/Client/Institution to process them.
3) Create a Marker Interface IContainerAssignable that User/Client/Institution implement
This would at least provide some type safety, but would require type checking and downcasting.
Right now, I'm leaning towards #3. It seems the simplest, but I've read in quit a few places that if your code is running logic that has to test for a given type and downcast that you probably have a bad design.
Any advice appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据您对我的问题的评论，我根本不会让容器处理分配。举个例子，文件不知道也不关心谁在观看它。
相反，我要么让观察者实现某种方法（或集合属性）来开始观察容器（在这种情况下，使它们成为 IContainerWatcher 等才有意义），要么将观察功能完全卸载到专门用于维护关联的服务，就像发布/订阅机制一样。这在概念上类似于数据库模式中的多对多连接表。
Based on your comment in response to my question, I would not have the assignment handled by the container at all. To use your example, a file doesn't know or care who's watching it.
Instead, I'd either have the watcher implement some method (or collection property) to start watching a container (and in that case, making them an IContainerWatcher or the like would make sense), or else have that watching functionality offloaded entirely into a service that's dedicated to maintaining the associations, like a publish/subscribe mechanism does. This is conceptually analogous to a many-to-many join table in a database schema.