MVC Repository Pattern/Web Services SoC Question

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 valu开发者_开发知识库es 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.

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'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.