C# classes and methods

Question

I find it difficult to determine the responsiblity of classes: do i have to put this method in this class or should I put this method in another class? For example, imagine a simple User class with an id, forname, lastname and password. Now you have an userId and you want the forname and lastname, so you create a method like: public User GetUserById(int id){}. Next you want to show list of all the users, so you create another method: public List GetAllUsers(){}. And offcourse you want to update, delete and save a user. This gives us 5 methods:

public bool SaveUser(User user);
public bool UpdateUser(User user);
public bool DeleteUser(User user);
public User GetUserById(int id);
public List<User> GetAllUsers();

So my question is: do you put all these methods in the User class? Or do you create another data class (UserData class) which may connect to the database and contain all these methods?

Answer 1

With all else being equal either way is fine. Which to choose, though, usually depends on the overall architecture of the application or class library in which you find the User class. If the data access code seems tangled with the User object code, then it might make more sense to split it into two classes as you've considered. If the CRUD methods are one-line delegations to a DAL with maybe application-specific logic, then leaving them in the User class should be okay.

The complexity is more or less the same in both cases—it's a trade-off between a low-maintenace assembly with few high-maintenance classes or a high-maintenance assembly with a larger number of low-maintenance classes.

I'm also assuming that the CRUD methods should be static.

Do what's easiest to get the code written right now but consider possible refactorings in the future should you find that it'll be better that way.

Answer 2

I would not put those specific methods into the 'User' class.

There are 2 common approaches for this 'problem':

• You put those method in the User class, and then this means you 're using the Active Record pattern
• You put those methods in a separate class (UserRepository) for instance, and then you're using the Repository pattern.

I prefer the repository-approach, since that keeps my 'User' class clean, and doesn't clutter it with data access code.

Answer 3

Barring additional complexity specific to a group of users (or really elaborate database access mechanics) I might make those methods static on the User class.

Answer 4

What you are describing here is basically a choice between the Active Record Pattern or the Repository Pattern. I'd advise you to read up on those patterns and choose whichever one fits your application / experience / toolset.

Answer 5

Those methods sound more like a UserManager (or something like that) to me. The user class should correspond to and represent only a single user, not many.

Answer 6

If I understand your question correctly the User class deals with a single user. Hence the user class does not have a clue about how many users there are or anything about them. The structure holding this information is somewhere else and the methods you mention seem to belong to that structure / class.

Answer 7

If we look at Enterprise Application design patterns, then the methods for fetching Users i.e. GetUserByID and GetAllUsers would be in separate class - you can name it UserData or UserDAO (DAO - Data Access Object).

Infact you should design an interface for UserDAO with appropriate methods for handling User Objects - such as CreateUser, UpdateUser, DeleterUser, GetUserXXX and so on.

There should be an implementation of UserDAO as per the data source, for example if your users are stored in database then you can implement the logic of accessing database in the implementation of UserDAO.

Following are the advantages of keeping the access methods in separate class:

1) User object should be plain object with just getter setter methods, this would facilitate passing object across tiers - from data access tier, to business tier to web tier. This would also help keep User Object serializable

2) The data access logic is loosely coupled from the User object - that means if the datasource changes, then you need not change the User object itself. This also assists in Test Driven Development where you might need to have mock objects during testing phase

3) If User object is complex object with relations with other objects such as Address or Department or Role etc. then the complexity of relationships will be encapsulated in UserDAO rather than leaking in the User Object.

4) Porting to frameworks like NHibernate or Spring.NET or .NET LINQ would become easier if the patterns are followed

Answer 8

Lets us see you scenario as this.

There are 'N' number of people working in assembly division of you company.

It is okay to go to a person and ask about his information BUT you cant expect him to tell you details of all persons working in assembly division. Reason why shud he remember all the details and if you do expect then his effeciency will go down(work on assembly and also remember details of others).

So ..... perhaps we can appoint a manager who can do this ppl maanagement activities (get details, add new person, edit ,delete etc etc )

Therefore you have two entities

1) User/Person working in your assembly deivision 2) a Manager

Thus two classes. Hopes this will help you.

Thanks