views:

23

answers:

2

Hello,

I am new to ASP.NET MVC and I am trying to implement best practices for a small-to-mid size application that uses a web service as its data source. The web service exposes the following methods to support the application:

  1. AuthenticateCustomer - returns the customer ID if valid email/password
  2. GetCustomer - returns a serialized object containing customer information
  3. Etc

My question is, all of these services return Success (bool) and Message (string) values depending on the result of the operation. The message contains descriptive information if an error occurred. I'm not sure if the invocation of the web services belongs in the Repository layer, but I think it is important to be able to pass the Success and Message values up through the Repository -> Service -> Controller layers. The only way I can think of doing this is by either littering the Repository methods with out arguments:

public int AuthenticateCustomer(string Email, string Password, out bool Success, out bool Message);

or create some sort of wrapper that contains the intended return value (integer) and the Success and Message values. However, each web service method returns different values so a one-size-fits-all wrapper would not work. Also, these values would need to be passed up through the Service layer, and it just seems like validation of some sort is happening at the Repository level.

Any thoughts on how to accomplish: 1. Separation of concerns (validation, data access via web service) while ... 2. Having the ability to maintain the feedback received from the web service and pass it through all the way to the View?

P.S. - Sorry for the terse question. It is a bit difficult to explain with any kind of brevity.

A: 

Do you need a repository? From what you described, I am viewing the Web Service as the repository. I would then use the Services (Business Layer) to call to the Web Service, and have the logic in there handle errors or success.

Have the Business Layer convert the Customer object from the Web Service into a Business object, and pass that on to the Controllers.

Repository (Web Services) -> Services (Business Layer) -> Presentation Layer (Controllers)

Martin
Martin,Your response makes sense. As I thought about it, my application does not "own" the data nor is it responsible for maintaing the data to the persistent storage (the web service handles this), therefore eliminating the need for an explicit repository.Thanks for your input.
Ariel
A: 

Martin's answer is good.

I could possibly see a case for a thin layer around the web services to facilitate testing.

If you do go that route and Success = false is not a common condition you could throw an Exception of your own type with Success and Message wrapped into it. I would only do this if it really was an exceptional condition. If you find your business layer catching the exception just to return an error code to the presentation layer, then it's the wrong approach.

Rob
Rob,That is the issue I came across when designing this. I am able to perform some validation on the service layer, but there are business rules built in to the web service that I am unable to handle in my business layer. For example, there is a service allowing the customer to change his login (email). The web service validates that the new login is not already in use by another customer. It is important for this feedback to be caught by the service layer and then presented to the user. It "feels" very wrong, but I am struggling to figure out a better way to handle it.
Ariel