Use Get by Type or Get by ID

I have a method called GetObjectsRela开发者_JAVA百科tedToAType, e.g. GetCarsRelatedToDealership. Which approach is better from a web services or general method signature standpoint:

List<Cars> GetCarsRelatedToDealership( Dealership dealership );

or

List<Cars> GetCarsRelatedToDealership( id dealership );

I tend to like the object approach because it is a little more forceful about making sure the source input to the method is valid. Thoughts/advice?

---

Is the ID the only piece of information the method requires to function? If so I'd leave it at that.

---

The object approach has problems.

Dealership dealership;
GetCarsRelatedToDealership(dealership); // dealership is null

var dealership = new Dealership();
GetCarsRelatedToDealership(dealership); // dealership has no id

In these cases the object isn't giving you any advantage over just the id. The id might be wrong, but you can validate that. The object makes things a bit more complicated.

When dealing with services, I would create a Request / Response pair of classes. This allows you to ensure your signature never needs to change. Your Request or Response objects might change, but the method signature does not.

Now I can pass the dealership id, as well as who is requesting the information and ensure that the user asking is allowed to see the inventory of that dealership. Something just passing the dealership or id would not allow.

public class CarsRequest
{
  public int DealershipId { get; set; }
  public int RequesterId { get; set; }
}

public class CarsResponse
{
  public Car[] Cars { get; set; }
}

CarsResponse GetCarsRelatedToDealership(CarsRequest request);

---

For the web services I try to minimize how much data is being sent over the wire. If you also need a method I would probably make member method "GetRelatedCars" for the "Dealership" class/interface. When the web service call comes you could validate it is a real "Dealership" (and the caller has rights to it) by getting that object based on the id and for the call the "GetRelatedCars" method on the object.

---

Can you have the method take an interface? This would make it much more flexible and perhaps easier to test.

List<Cars> GetCarsRelatedToDealership( IDealership dealership );

---

I'd go with the Id approach, and validate that the Id is valid. You could potentially get an invalid Dealership object, in which case there would be no advantage gained to using the Dealership

---

Using just an ID is usually sufficient, and is far easier because you can simply pass an ID around from one place to another. This is especially important with web services, where you want to minimize the amount of data being transferred.

However, if you often have large method signatures where the input is not specified very well by the name of the method:

List<Cars> GetCars(int makeId, int modelId, int year, int dealershipId);

... it can become very easy to pass the wrong ID in to the wrong place. That's the point where I would begin trying to find a different strategy. Strongly typing your inputs as domain objects is one solution, but it will generally cause you a lot more hassle than simply using a special options POCO:

public class GetCarsOptions
{
    public int MakeId {get;set;}
    public int ModelId {get;set;}
    public int Year {get;set;}
    public int DealershipId {get;set;}
}

List<Cars> GetCars(GetCarsOptions options)
{
    ValidateOptions(options); // make sure the values all make sense.
}

The fact is, you won't be able to catch every possible error at run time, so it's a good idea to combine automated tests with "fail-fast" techniques to try to catch as many bugs as possible after compilation and before deployment.