Re: Repositories Global only or contextual?

"the interface of the repository is in terms of the model"

I wholeheartedly agree with this.

In my environment, though, I go further.  My repository *implementation* is
in the domain.  This is possible, however, only because of some very clever
frameworks and techniques: NHIbernate (.NET port of Hibernate), LINQ, and
our own implementation of a Jimmy Nilsson's NWorkspace concept.

So imagine your repository interface has a method like this:

    IList<Cusotmers> GetRecentCustomers(TimeSpan maximumAge);

Normally you'd leave the implementation of that to some custom querying
mechanism specific to your persistence layer.

However, LINQ allows .NET programmers to have a query-like language in the
.NET framework (it's just a bunch of interfaces specifying querying
constructs).  And NHibernate implements LINQ such that you can query for
entities using LINQ but really uses HQL\SQL underneath.

And the Nilsson Workspace pattern obscure the fact that NHIbernate exists.
 The code using the workspace just knows that it has a Workspace where it
can ask for LINQ-queryable collections of objects (that really are
NHibernate-LINQ'ed deferred querying collections that are ultimately
fetched by SQL queries).

So the implementation of that method might look like this:


IList<Cusotmers> GetRecentCustomers(TimeSpan maximumAge)
{
DateTime cutoff = DateTime.Now.Subtrace(maximumAge);
IList<Customer> customers = GetCurrentWorkspace().Find<Customer>
.Where(customer => customer.CreationDate > cutoff)
.OrderBy(customer => customer.CreationDate)
.ToList();
return customers;
}

While that ultimately will execute some SQL (e.g. "SELECT * from
tblCustomers WHERE CreationDate > '2014-01-20' ORDER BY CreationDate"), any
concept of SQL or NHibernate are entirely missing.  It is built entirely
from .NET collections and agnostic querying constructs.

In fact, I could write a unit test that has a Workspace which delivers an
in-memory list of stubbed customers, and the code would then execute
against an in-memory list.  This is actually how we unit test our
repository *logic*.



On Wed, Jan 22, 2014 at 6:15 AM, Thomas Presthus <[email protected]> wrote:

>
>
> On Tue, 2014-01-21 at 16:35 -0800, [email protected] wrote:
> > Repository is not really a concept from your domain. That's an
> > infrastructure concept [so that domain can make side effects ;)]
>
> I beg to differ. According to Eric Evans in chapter 6 of the blue book:
> «A REPOSITORY lifts a huge burden from the client, which can now talk to
> a simple, intention-revealing interface, and aks for what it needs *in
> terms of the model*. To support all this requires a lot of complex
> technical infrastructure, but *the interface is simple and conceptually
> connected to the domain model*.» (my emphasis).
>
> The implementation of a repository is thus an infrastructure concern,
> but the interface of the repository is in terms of the model. I think
> leaving repositories alone in the infrastructure might disconnect the
> language of the repository's interface from the one of your domain over
> time. I therefor consider it a best practice to model the interface of
> the required repositories in the domain, and implement those interfaces
> in the infrastructure.
>
> > Having said that, lazy load is another story. While you could use
> > signature to implement lazy load. since you are using Java, your
> > signature would not look too nice (in .NET you could leverage
> > IQueryable from LINQ - which looks much better).
>
> Lazy loading is an optimization mechanism that should only be used if
> required. And if it's required, it should not be a part of the
> repository's published signature, but rather an infrastructure concern
> that is encapsulated and hidden from the calling client.
>
> Thomas.
>
>  
>



-- 
Regards,
Brian.