Question

The one thing that can still get me is what to return from methods? I know that you should be as specific as possible(ie don’t return object if you need to return an int)

However it’s cases like this

I have a service layer that contains business logic. Say I have a method called CreateAnEvent()

Basically it saves an event to the database and if successful it will return a string with “saved to database”

Now what happens if I first need to check if this event meets some business rules.

1. Can’t be less than today’s date.
2. Can’t be greater than one week from today.
3. Can’t be created on a Friday.

Something like that where I need to first do some business checks that could either lead to validation errors or maybe some sort of other error(maybe even an exception) or a success message still gets me what I should be returning.

So lets go first with validation. Say the user fails all these validation rules what now? I am returning a string so this won’t be pretty I going to have to use csv to return all the errors and parse them out.

So that just seems very bad.

I could first have a separate method called Validate() but now I have to remember to call this before I call CreateAnEvent(). So I don’t think this is that great.

I am using ViewModels in my mvc project so maybe I should pass the entire viewModel to the service layer and then return this ViewModel.

In this view model I could have a collection of Errors that I could add all these errors to as well as a string to contain a success message.

Once it gets returned just do a check first for errors if count is zero then assume success msg is filled.

I am not returning the most specific type back but it would solve my problem. However I don’t think the service layer should know anything about a viewModel.

I know some people do the validation in the viewmodel but I consider that more for basic non business logic rules like is a field blank or not. I don’t think I should be doing testing like I described above in a viewmodel.

So the last option I can think of is send in the Domain Model(that would be in a viewmModel since there is a good chance I would be using it in the view) and in this Domain Model I would add a string for success messages and a collection for errors.

I would then return this domain model.

So it basically same idea as using ViewModels but this time extracting out the domain model and using it.

So is this the best way to do it or are there better ways?

Answer 1

I prefer to separate my validation logic into classes of their own. The reason for this is entities can have various layers of validation. My validator classes implement the following interface:

public interface IValidator<T>
{
    bool IsValid(T entity);
    IEnumerable<string> BrokenRules(T entity);
}

I then inject this validator into my service. The service can then return a boolean if the method succeeds / fails. On failures the additional information contained in the ‘BrokenRules’ enumerable is available. I have documented this in a blog post:

http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/

Let me know if you have any questions. Hope this helps.

Bob