One thing that I have avoided touching
on so far is what kind of parameters to use when fetching single objects.
The main reason for avoiding this was the ..AndRefresh() style of interface
used last time. Now, when I have changed to, say, SaveCustomer()/FetchCustomer() instead, I have to decide on the parameter
type for FetchCustomer() and FetchOrder() and so on.
My first idea was to use ordinary
objects here too, such as Customer objects with present key values.
Note, for example, that FetchCustomers()
uses a query object as its parameter and the query object has all the
important information (criteria) needed for the query to be executed. By sending
a customer object as parameter to FetchCustomer(), the same pattern is used again and
the customer object will have all the criteria information (the primary key
value) that is needed.
first thought I could argue for sending ordinary objects (such as Customer
instances) by pointing to the Introduce Parameter Object refactoring ,
but I changed my mind about that. That refactoring is more about creating
classes of related values that are used as parameters. The Customer class is not created just because of the parameter
requirement. It’s already there and is designed to do other things than
just be used as a parameter containing the key value.
So, what’s the problem with the
object approach then? Well, it feels a bit wasteful to send a full fledged
object, when there’s actually only one single property that is interesting.
This is especially the feeling if there is an AppDomain boundary to be passed
so that the whole object will be serialized and deserialized.
I could solve this by providing
yet another form of unexpanded state of the object, having only the key value,
but this adds to the complexity and it means a lot of work for a minor benefit.
Another thing is that remoting creates a problem here because the object you
get back is not the same as the one you sent.
mentioned the problem with remoting a couple of times and I’m still not
done with it. As you’ve probably guessed already, this bothers me.
So, what is it that I’m really
after? Well, the most important thing is that I don’t want to spread information
about the key structure everywhere, especially not in the consumer tier. On
the other hand, if all the keys are GUIDs, then it’s not that much of a problem
to let the consumer know about the datatype. It’s not very likely that you
will outgrow the GUID datatype, for example, and have to change it as a result
Even so, it’s nice to encapsulate the information about the key datatype from
the consumer if you have to change it, especially if you start with a smaller
datatype. Remember, one of the main reasons for the new architecture was to
provide a higher degree of encapsulation of the database so that it can evolve
more easily without affecting the rest of the application