I have what will hopefully be a quick question about my entity design. Keep in mind, this was backwards engineered from my old database.
Currently I have a Post entity that maps to the Posts table. This table houses entries that represent either a thread or a reply (you can reply to a reply as well).
The thing is, not all the fields are used by either situation. If a post is a thread, it uses the Enabled field to determine if replies are accepted. This field isn’t used if the record is reply. Likewise, a reply won’t use the title field. And so on.
Should I drop the Post entity and create both a Thread and Reply entity to replace it?
I understand what view model is, and does, but this is strictly a domain concern right now.
What I’m asking is, should I split the monolithic Post entity into smaller Thread and Reply classes. As it is now, it works, but when a Post represents the first in a thread (aka Thread), there are properties that aren’t used. Likewise, when it is used as a reply (aka Reply), there are other fields that aren’t used. So what I was thinking was to split it up, and have only the fields that particular entity will use in it.
As a side note, late last night, I did just this. I put the database out of my mind and thought about the entities only and how things should fit together. A code example should demonstrate this:
// somebody starts a thread
forum.AddPost(initialPost);
// later somebody replies to it
post.AddPost(anotherPost);
The above is a tad generic and the properties aren’t being fully utilized.
// somebody starts a thread
forum.AddThread(thread);
// later somebody replies to it
thread.AddReply(reply);
This is a lot more clear as to what is going on, and neither entity contains wasted properties.
That’s what I’m asking: is this a better solution than using a single entity (just because there is one table doesn’t mean I have to use a single entity to represent it).
By the looks of your other post you’re using MVC, if so, your view model should represent what is on the screen and then passed back and transformed in to the relevant entity.
So if you have a Post view object you could easily spawn the following for example;
You are on the right track now Serena, that is a much better solution than the previous one.
It takes a bit of a mind shift to break the misconception that some people have about the domain just being a verbatim code representation of your database.
Your domain should represent the logical portions of your system.
Taking the approach you’re taking now should greatly aid you in building a more scalable system, especially if you wanted to start caching certain things more aggressively.