This is a design question and I am confused about how to design my user object. As in most systems, user is the central part of my application and a lot of information scattered around my database points back to the user for example a user can have multiple orders, mulitple Addresses, and he may have won multiple prizes. If we want to talk about ONLY user and his basic information we can be done with ID, firstnmae, lastname etc. So I have two clear choices
- Create a light weight user object which looks like following:
public Class User { public int Id {get;set;} public string FirstName {get;set;} public string LastName {get;set;} public string SomeMoreInformation {get;set;} }
and get all the infromation at the other information at the run time like orders and Prizes on need basis.
OR
Design a more contained object which carries all the required information with it but is little heavy:
public Class User
{
public int Id {get;set;}
public string FirstName {get;set;}
public string LastName {get;set;}
public string SomeMoreInformation {get;set;}
public Address HomeAddress {get;set;}
public List<Prizes> Prizes {get;set;}
}
Which Does any design model align to a good design philosophy? Are there any best practices in the kind of situation that can help me make a decision?
0
To answer this question you should distinguish between information analysis phase, and design phase; even though modern software engineering methods often combine them, the model (doesn’t have to be a 1073 page document, it can be in your mind or in the code as well) and level of detail differs:
- In the analysis phase, your model will closely match reality, meaning the is a single concept
userand some ideas about what data about a user is required. - In the design phase, it depends on what information about the user your application needs in various situations and how easy it is to retrieve the information.
For example, from looking at the user side of Stack Exchange we can deduct that:
- Often
<user name, avatar, reputation, gold medal count, silver medal count, bronze medal count>suffices (e.g. to display the author of a post or comment). - To display comments, only the
user nameis sufficient. - When someone views a user profile, much more information is required:
<user name, avatar, reputation, gold medal count, silver medal count, bronze medal count, all questions, all answers, all comments, all badges, reputation changes>. - When a user logs in, authentication information and browser session are required; but these should definitely not be shown in post author information.
So here we, conceptually, have four different User classes. We might opt to use the <user name, avatar, reputation, gold medal count, silver medal count, bronze medal count>-structure for the comment author as well, since its available anyway.
You could use inheritance to combine the different kinds of UserInfo, i.e.:
class BasicUserInfo
{
public string Name { get; }
public Image Avatar { get; }
public int Reputation { get; }
public int GoldBadgeCount { get; }
public int SilverBadgeCount { get; }
public int BronzeBadgeCount { get; }
}
class UserProfileInfo: BasicUserInfo
{
public List<Post> Questions { get; }
public List<Post> Answers { get; }
public List<Comment> Comments { get; }
public List<Badge> Badges { get; }
public List<ReputationChange> Reputation { get; }
}
class UserAuthentication: BasicUserInfo
{
public string PlainTextPassword { get; } // Not really, I hope everyone knows why and
// how to do this correctly
}
class UserSession: BasicUserInfo
{
public List<Cookey> Cookey { get; set; }
public UserAuthentication Authentication { get; }
}
And then use some kind of repository to find UserInfo objects, e.g.:
class UserRepository {
public UserProfileInfo FindUserProfile(BasicUserInfo user)
{
// …
}
public UserSession FindLoggedInUsers(BasicUserInfo user)
{
// …
}
}
The repository deliberately uses the common base class, BasicUserInfo, to find the extended UserInfo objects, since:
- it allows using any kind of
UserInfo-object (i.eBasicUserInfoand all extendedUserInfovariants) to lookup an extendedUserInfo-object; - I’m wary of using a string or int as user id, since forgetting the type info
means we can confuse a string or int that contains something completely different with one containing auser id(e.g. if(UserRepository r, BasicUserInfo u) => r.FindUserProfile(u.BronzeBadgeCount)where supported, would give surprising results.)
TL; DR
Depending on what your application requires use lightweight class User, heavyweight class User, or use several kinds of UserInfo. If using several kinds of UserInfo you can use a repository and the lightweight common base BasicUserInfo class to find the extended UserInfo.
1
The second design is almost certainly better than the first, unless SomeMoreInformation is both very expensive and entirely optional.
2
The problem you are faced with is that there are numerous descriptions of ‘User’, not all of which are applicable to all User clients.
The clients of User should not be forced to depend on methods or properties that they are not interested in. It is far better to split your User object up into smaller interfaces that each define concrete responsibilities.
I would start with your base object which contains what is true about all users, and then add additional functionality through optional interfaces.
For more information, see the “Interface Segregation” principle (http://en.wikipedia.org/wiki/Interface_segregation_principle), and even better, look up the “SOLID” principles, here: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Well, this is a question, answer to which heavily depends on what requirements should the model satisfy. But in a general case I would vote for solution 1 (lightweight objects) because of the following reasons:
- Of all application design rules there are in a world I consider the following of the uttermost importance: Lower the complexity of your code.
By complexity here I understand generic human-perceptible complexity. If you are building some puzzle for a six year old, it can contain quizzes like 2+2=?. You can, of course, make it 2+2+3-1+14/2+16 and it will still be ok. But when it becomes something like sqrt(4)+2*16^2 it tends to unnecessarily overcomplicate matters 😉
When you design a small application, putting everything into one model doesn’t matter much since the code is still easy to understand. But when application grows, putting everything into one bowl will strike you with unmaintainable code soon.
-
Performance-wise it’s faster to query/update small chunk of data
-
Usually you don’t need every single piece of model data for each and every operation so small chunks are ok. Of course, your persistence layer should be able to work with related data, but then again, every more or less mature ORM now can do that well.
What you ask relates to code complexity, time vs space tradeoffs, caching strategy (if any), and round-trips to the database.
In general, I tend to start with the first, simple approach. Then, when and where performance requirements dictate it, I’ll move toward the second approach.
Key point: Depending on usage and caching strategy, this move may never be required.
Finally, when moving in this direction, when you are querying a one-to-many relationship (like each user has a set of email addresses), it may be possible to fetch the user(s) and all associated email addresses in one round-trip to the database. This is where significant performance gains can come into play, especially when there is higher latency between application and database.
The answer depends on your domain and persistent framework.
For example, list of Prizes seems to be essential part of the user, however if a given user has a lot of Prizes, and if you are using eager loading this design would be an issue as it would affect the performance, However if you use lazy loading this would not be an issue, as it would not actually fetch these data if you just want to access user’s data such as FirstName and LastName.