I have a design where I want to be able to assign one or more command objects to an entity, which will then use these commands as part of its workflow. Something like assigning add-on features to a user's account, for argument's sake.
I understand the Command pattern and how this fits, but my question is one of persistence. If I have a list of commands, where each user account can have its own list of commands, and let's assume for argument's sake that the only thing important about the command is its system Type, and/or they all have the same properties. What's the best way to persist that when it comes time to implement my data layer?
I was considering doing it as a many to many relationship between the accounts table and the commands/features table, where the latter table follows a TPH strategy (i.e. all commands persisted in the same table). That seems to be the most clean way of doing it, but I wanted to see if anyone else follows a different strategy?
Do you instead make it a 1: many relationship, where any two accounts that have the same feature added have a different instance of that feature? Or is there a better way that I'm not thinking of at all?
Many-to-many with TPH looks ok to me.
Though I wonder your design decision to attach commands to different users, seems like you are trying to use them for authorization | permission purposes, instead of implementing normal authorization system using Role Based Security, or ACL. If it as the case then I would probably use role based security at internal level and for UI commands that are created dynamically based on internal security rather then statically stored in DB.