Design question for highly extensible project - Bearing in mind best practises.

Question

Hi there.

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.

Answer 1

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).