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 user开发者_如何学JAVARegistrationResponse;
}
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.
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.
精彩评论