Question

In my mvc3 application, I have things setup like:

1. repositories for each entity
2. service class for each entity that wraps the bare nhibernate db calls with business logic

Now for example, a class that registers a user, I want the service class to return something more than a boolean or user object if the user can register successfully.

Is this good practise?

Reason being, a person may fail to register correctly for reasons like:

1. duplicate email address in the system
2. duplicate username
3. etc.

So my method may look like:

public User Register(User newUser)
{
   // check for a user with the same email
   // check for a user with the same username

   // validation checks etc.

   return user;
}

I am thinking of creating a UserRegistrationResponse object so I can return back a much richer return value.

So something like:

public UserRegistrationResponse Register(User user)
{
  ..

  return userRegistrationResponse;
}

This way I can return back a user frienly response I can propogate to the UI layer, and still get the user object and other information etc.

Comments on this approach?

I guess the only other way would be to throw exceptions, but is that really a good idea? The idea is for me to able to re-use these service classes, like say in a Restful service layer I will need in the future.

Answer 1

This is very common. 10 out of 10 WCF projects I’ve worked on in the past 3 years used this pattern. This includes legacy projects at three different companies, green field development and mvc/webforms projects.