Class Design question concerning adding a new “DRAFT” state to an object
We have some entities in our code:
-“View” and View has some attributes and also contains one or many “SubViews”
-And each “SubView” has some attributes and contains one or more “Tweet” entities.
So far so good. User edits Views/SubViews/Tweet (adding/removing tweets from subviews, adding/removing subviews fro views etc) in our UI and as everything is linked it updates fine. At the moment the user after editing, can decide to make her changes “Live” Or just discard them, there is no option to save and come later.
So now we want to introduce a “Draft” system. So user can edit a View/SubView/Tweet in a draft state (This is to be persisted) and eventually decide to make it “Live”. On making it “Live” the draft doesn’t die. User can continue to work on the draft and make it live again. So they both live side-by-side and have to be linked.
I’m not sure how to go about introducing this is code as the “Live” is just implicit in code/db atm. Some options I could think:
- Add a flag to each class with Live/Draft state indication. This will mean that I need to keep them in synch between the entities that are linked together
- Add another “Manager” like class that holds the objects related to Draft/Live versions of the views and manages the relationship between them. Using only the current types. The Manager is the only one that knows what is draft and what is live object
- Add a completely new type “DraftView”->”DraftSubView”->”DraftTweet” and manage the relationship between Draft and Live entities
At the DB level I’m thinking of just adding another column to the table to say Live/Draft.
More likely, there is a better way to do this and there are patterns to help with this, so i’m hoping I can get some opinions on my suggestions or better ways to do this. Hopefully I could make the question clear.
Go to Source