What should my user object know?

Question

I have an architecture problem/doubt and I'd like some insight on this.

Context :

We're in a mobile app that solely relies on webservice calls to be used. There can only be one user logged in at any given time and all calls require a user. We're talking about (for the sake of examples and clarity) meetings (one user has a meeting) and visitors (a visitor is a contact, not another user).

The debate :

We've been arguing for about an hour. One side wants to have several "Managers" or "Services" that handle, say, the meetings and take a user in parameter. This service/manager is called when needed to get a list of meetings, and is given the current user. This looks clean, not coupled (well separated), and pretty clear without being cluttered and complicated.

The other side say that there are no actions that a user can make without being logged in, and all those services will need a user as parameter. So we might as well have all those services called by the user itself, and simply use user.GetMeetings(); when we want those meetings. This user would be able to check all that by itself, .isLoggedIn, or .logIn, and much more.

One one hand, this looks "simpler" on the outside, we always call a user method and our viewmodels don't know about anything but a user. On the other hand this really just looks like a giant wrapper that pretty much covers the whole application (which extends further than meetigns and visitors).

There would be that user layer that does everything through the current user, and all those services would still exist but only the user would call it, and we're just turning in circle because " the user is everywhere anyway, and the services would be called everywhere anyway ". But the user doing everything looks so tightly coupled to the services that it feels wrong, even though only him uses it and ever will.

Anyway, I'd like to know what you guys think, is there something better? Is there a standard? Is there a wrong answer in my two situations? Note (and that's important) that we're only debating in the context of our app, not in general. Obviously if users had to interact with each other, if you had anonymous users or many more situations, this wouldn't work. But we know that this will always stay the same, the user will always be needed for the webservice calls, and there will always be only one user. I've been sitting there and listening to them and I'm just confused, and curious to have an external feedback on this.

I'm not talking about a massive big god-class for the User. In both cases all the calls are made in separate services/manager classes. The big difference are the following :

• Case 1 : My model knows the current user and the service it needs (eg: MeetingService ), and simply asks the meeting service to get all the meetings and gives it the current user as a parameter.

• Case 2 : My model only knows the current user and asks him to get all the meetings ( .GetMyMeetings();), without caring how he does it. The user itself simply knows all the different services he might need and, in that case, being calls the MeetingService and returns whatever was asked.

We're really just adding a layer into our hierarchy, so that they all combine in the user.

But code-wise, the user won't get that big, it'll probably end up being about 100 lines long, including properties and all the methods we'll need.

Answer 1

Unless User must have a Service to do user things, do not make the user pretend to be the application context/ overall state.

"Convenience" and "LOC per class" are not design principles.

Focus your classes sharply. Fanatically adhere to single responsibility principle.

the user won't get that big

Irrelevant.

it'll probably end up being about 100 lines long

Irrelevant.

including properties and all the methods we'll need.

SRP violations in progress.

There can only be one user logged in at any given time and all calls require a user.

This is state that neither the User nor Service can possibly know by themselves, in isolation so to speak. This state is particular to the broader application context. So you need one or more other classes - ApplicationContext let's say, that knows this context and queries the participating objects for what they know (I, the user, am logged in for example) thus doing ApplicationContext things.

---

We're really just adding a layer into our hierarchy, so that they all combine in the user.

"combine in the user" is categorically not "adding a layer into our hierarchy". Adding a layer would be something like the above.

Answer 2

I would go with the Service.GetMeetings(user u) approach.

Here's my reasoning.

In my experience the only difference between these two approaches once you add DTOs and hosting projects for your services is naming.

If you keep the logic out of User, then User is equivalent to your what your UserDTO would have been

Your new Service Class seems like an extra 'Helper' function until you expose User.GetMeetings() through IUser and a hosting rest/wcf/own project in which case you end up with a bunch of extra classes anyway.

So overall, the Service.GetMeetings(user u) means less code and easier code reuse. you can stick your user and meeting classes in a portable class lib and share them with your app.

Answer 3

Each service should be self-contained.

Most devs know that when something is "set in stone", it will change on you when you least expect it, forcing you to re-architect your solution.

You should always design your solutions to be correct from a technological stance even if it makes things a little more complicated in the beginning.

Separation of concerns is your greatest tool to preventing you from coding yourself into a corner.

Two years from now the requirements might change and suddenly you need to allow anonymous users to create a meeting (say you move to a freemium model). Now you have to re-architect your User class to either have a anonymous User object or you have to move all those meeting function calls out of the User object, into the proper location in the Meeting service.

Or you setup continuous meetings where no one person is the creator of the meeting, now the User object is completely decoupled from the creation of a meeting. The creator of a meeting may be a Company object or tied to a Room object.

You can always expect requirements to become more complex and convoluted, you should plan for that now.