高度可扩展项目的设计问题 - 牢记最佳实践
开发环境是C# 3.5，带有SQL Server 2008数据库和实体框架。
想象一下，您有一个类和一个名为 Sign 的表，它代表由第三方创建的物理电子标牌，您的软件需要控制该标牌。您还有一个名为 SignDriver 的类，它负责与标志进行实际通信。标志的属性/列表示标志驱动程序正确与标志对话所需的可配置信息。
一切都很棒，你已经彻底地称赞了自己。然后就需要与不同的星座交谈。但是，此标志的工作方式与前一个标志不同，并且需要您的 Sign 类和表来存储附加信息。假设需要存储 5 个新事物（列/属性），但不幸的是，第一种类型的符号不需要这 5 个事物。然后你会发现，当你想要控制每种类型的 10 个符号时，你的表中有很多 NULL 值。
您的领域模型会不断增长，直到您拥有更多像 Sign 这样的类，每个类代表问题域的不同部分，并且每个类在数据库中都有相应的表。每个类别都面临着同样的问题，即很好地收集其类型的共同信息，但根本无法很好地满足每种类型的专业性。
您意识到问题的本质意味着将有更多类型的标志需要控制，以及更多类型的其他实体需要满足。您需要一个更具可扩展性的模型。
对于这样的系统来说，最好的前进方式是什么？
我已经与我的同事详细讨论了这个问题，并且非常想知道解决此类问题的最佳方法是什么。特别是因为这似乎是许多人过去都会遇到的问题。
以下是我们提出的选项以及关于每个选项的一些要点：
- 为每个实体创建 n 个“类型”类和表，以与其共享 1 对 1 关系。
- 非常继承。
- 扩展时最耗时。
- 很多桌子。
- 为每个实体创建一个“扩展属性”表来保存键值对。
- 参照完整性。
- 可扩展。
- 创建一个全局“扩展属性”表来存储任何实体的属性。 （架构：entityType、entityId、key、value、dataType）
- 超级可扩展。
- 现有表无法实现引用完整性。
- 实体框架似乎无法很好地处理这个问题。
你会做什么，为什么？
非常感谢任何帮助。 干杯。
Development environment is C# 3.5 with a SQL Server 2008 database and Entity Framework.
Imagine you have a class and a table called Sign which represents a physical electronic sign created by a third party which your software needs to control. You also have a class called SignDriver which takes care of actually communicating with the signs. The properties/columns of Sign represent configurable information needed by the Sign Driver to properly talk to the signs.
Everything is great and you’ve patted yourself on the back quite thoroughly. Then the need arises to talk to a different sign. However this sign works differently to the previous one and requires your Sign class and table to store additional information. Let’s say 5 new things (columns/properties) need to be stored, but, unfortunately the first type of sign does not need these 5 things. You then find when you want to control 10 of each type of sign, you have many NULL values in your table.
Your domain model grows until you have more classes like Sign, each representing a different part of your problem domain and each with a corresponding table in your database. Each class suffers the same issue of collecting the common information of its type well, but NOT catering for the specialisations of each type well at all.
You realise that the nature of your problem means that there are going to be more types of signs to control, as well as more types of your other entities to cater for. You need a more extensible model.
What would be the best way forward for a system like this??
I have discussed this at length with my collegues and would really like to know what the best way to approach a problem like this is. Especially because it seems like a problem MANY people would have faced in the past.
Below are the options we’ve come up with and some points about each:
- Create n number of ‘type’ classes and table for each entity to share a 1 to 1 relationship with.
- Very inheritance-y.
- Most time consuming when extending.
- Many tables.
- Create one ‘extended properties’ table for each entity to hold key-value pairs.
- Referential integrity.
- Extensible.
- Create one global ‘extended properties’ table to store properties for ANY entity. (schema: entityType, entityId, key, value, dataType)
- Super extensible.
- Cannot have referential integrity with existing tables.
- Doesn’t look like Entity Framework will be able to handle this well.
What would you do and why??
Any help greatly appreciated.
Cheers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题涉及软件设计的多个问题。
您的主要问题似乎是将继承层次结构映射到数据库表。这已经得到了广泛的分析 - 请参阅 Martin Fowler 在他的著作《企业架构模式》中的工作。您可以在此处获得一些简要概述，但这本书更好，应该放在每个 OO 开发人员的书架上。比较“每个子类的表”和“每个类层次结构的表”模式。
一些一般建议：小心过多的继承 - 优先选择组合而不是继承。您几乎总是可以重构以避免继承。基本上，您最终会得到与 Sign 类分离的“专业化”，这为您提供了创建表层次结构的前进方向。如前所述，《Head First Design Patterns》一书是一个很好的起点。
另外，不要害怕有大量的课程和大量的桌子。一般来说，灵活的设计有利于大量的类和表（当然这样做也有缺点 - 由您决定最佳的折衷方案）。
This question touches on multiple issues of software design.
Your main issue seems to be with mapping an inheritance hierarchy to your database tables. This has been extensively analysed - see the work of Martin Fowler in his book "Patterns of Enterprise Architecture". You can get some brief overviews here, but the book is better and should be on every OO developers shelf. Compare the "Table per subclass" and "Table per class hierarchy" patterns.
Some general advice: be careful of too much inheritance - favour composition over inheritance. You can almost always refactor to avoid inheritance. Basically you end up with your 'specialisations' decoupled from the Sign class, which then gives you a way forward in terms of creating a table hierarchy. As mentioned, the Head First Design Patterns book is a good place to start.
Also, don't be afraid to have heaps of classes and heaps of tables. Generally flexible designs favour lots of classes and tables (although of course there are downsides to doing this too - it's up to you to decide the best compromise).