I have an interface to a .NET service layer, which, in turn, will communicate with a third-party system via a web service. This handles a number of different tasks related to the third-party system's functionality (it is actually a bespoke CRM system, but as the context isn't relevant I will swap this out for something trivial).
The interface looks something like this:
public interface IMyService
{
CarModel GetCar(string registration);
CarModel AddCar(Car car);
PersonModel GetPerson(string personId);
PersonModel AddPerson(Person person);
}
Now, my models currently work as follows: I have a BaseResponseModel, from which each SomethingModel inherits. Each SomethingModel contains some basic properties and also wraps a Something - like so:
Base response model
public class BaseResponseModel
{
public List<string> Errors { get; set; }
public bool HasErrors
{
get
{
return (Errors != null && Errors.Count > 0);
}
}
}
Specific response models
public class CarModel : BaseResponseModel
{
public Car Car { get; set; }
}
public class PersonModel : BaseResponseModel
{
public Person Person { get; set; }
}
Here, Car and Person simply contain a bunch of public properties. Then, each method of my IMyService takes its arguments, formats a request to an .asmx web service, parses the response into its response model and returns it to the caller (an .ascx codebehind).
However, the number of different ...Model classes (not to mention that they all have different property names for their wrapped objects) is becoming ugly. I am of a mind to do something along the lines of the following:
public class Car
{
public string