I went for the LoadingBehaviour option as well. It’s an unnecessary overload in some respects but it is obvious what its for.

There are cases where you specifically want to use proxies for performance reasons, so yes, the calling code should care

The difference in behavior is not something i’d want to configure through an IOC container, since the choice of using a proxy instead of fetching the real reference should in most cases be an explicit one IMO

As for where we stand on the name of the method… we’re currently leaning towards the overloaded Get method with the enum as mentioned by Dylan. It seems to be the only option that nobody objects to

///<summary>Return the cached object if it exists, otherwise
///create and return a proxy that may later raise an exception
///when it's used</summary>
Defer
}


and then add an overload like .Get(int id, LoadingBehaviour behaviour), with the default .Get(int id) calling the new overload with the appropriate default loading behaviour?

It means when you’re reading the code, you’ll see

customerRepository.Get(customerId, LoadingBehaviour.Defer)

- which indicates pretty clearly what’s going on, without polluting your repository interface with potentially confusing method names.

Just an idea

-D-

I’m gonna go with that for our team, so hopefully soon enough I’ll have input from people who have never used NH about this naming convention.

GetInstanceOrProxy: might be a good one, though i’d probably go for GetProxyOrInstance then, since it’s often more likely that you’ll end up with a proxy than with the actual instance

@Rob: public methods with a boolean parameter that modify the behavior of the method are a bit of a no-no. It’s far better to come up with a meaningful name which clearly explains the different behavior… not always easy if you can’t come up with a good name though

@Ken: i kinda like the reasoning behind that, but unfortunately we’ve already had the Get method in the base class for months now and it’s already being used all over the place, so i can’t just change it like that.

another possibility i came up with is DeferredGet… the name is not entirely accurate though since the actual retrieval may never happen… thoughts?

My (not final) take is to map NH.Load to repo.Get, and NH.Get to repo.FindById

reasoning:
The NH.Load method is supposed to be used when you know that the ID is present in the data store. Otherwise, an exception will be thrown. the .Get behaviour adhere to search mechanism – that is: if it’s there then bring it back, otherwise return null. It behaves exactly like “from Whadever o where o.Id == Id”.List().FirstOrDefault() + first look in Session cache.

If you already have what you imagine, then you have it. If you don’t already have what you imagine, you get to play with a make-believe one.

_repo.GetFromCache(id);
Using “from cache” indicates that you may not get the actual object and doesn’t necessarily breaks persistance ignorance) an alternatived name could be: _repo.GetCached(id).
Now, if you use another cache for other purposes like memcached this method name may be misleading.

_repo.TryToGet(id);
Again this is not perfect, but indicates that you may not actually get the instance.

A more verbose (but precise) naming approach.

_repo.GetInstanceOrProxy(id); //I may personaly get this one.

FutureGet