The Repository pattern should decouple data access from the domain

[AnthonyMastrean]

Writing the hypotheses of the "hate" articles as issues and defending them should help us improve as professionals, but also to get to the bottom of all this hate! ;)

Let me start with Rob Conery's article. He starts

It's generally believed that by using the Repository pattern, you can (in summary) "decouple" your data access from your domain and "expose the data in a consistent way".

And refutes it with an MSDN code sample.

If you look at any of the implementations of a Repository working with a UnitOfWork (EF) – you'll see there's not all that much "decoupling":

... (code snippet)...

This class can't exist without the SchoolContext – so what exactly did we decouple here? Nothing.

He makes the following claim for named command/query classes over Repository.

Less Abstraction == Clarity. We've lost our Repositories which didn't have a reason to exist other than to abstract an existing abstraction. Our Command/QueryObject approach is cleaner and the intent of each one is clearer.

A few questions...

• Do we accept the Repository decoupling premise?
• Do we accept the sample as a prototypical implementation of Repository over EF?
• What is the definition of decoupling?
• Do we agree that decoupling is a "good thing"?
• Does the CQS pattern decouple? How?

---

Let's pull in Jimmy Bogard's argument about Repository being an unnecessary abstraction.

I don’t think creating an abstraction over your ORM provides much value... Instead of bloating a data access god class, why not just create an isolated class that encapsulates our query?

His solution, named command/query classes, invokes the terms "encapsulation", "isolation", and "dependency injection".

Are these related to coupling?

[alanstevens]

Ayende and Jimmy both oppose over abstraction. I'm sympathetic to this to some degree, but I refuse to take a direct dependency on DbContext.

I understand the arguments against bloating repositories. The interface keeps growing as the app matures and we need to talk to the DB in more and more ways. I think the MSDN article is fairly representative. It's not much different than what I've been doing.

It's interesting that, to me, my command and query objects are more abstract than the former IRepository<T> I used to use. That doesn't mean I don't like them, but they are farther removed from calling the DB directly.

The thing that I really like about this approach is the explicit unit of work and how few methods live on the Dispatcher. Everything else is in the command and query objects which, thanks to their decoupling from DbContext, can live close to the code that uses them.

[jasonmacdee]

I was working my way through the "hate" list, and preparing a response to the first one as I was of a like mind with Alan et al. While reading Rob Conery's article, it seemed easy enough to reject what he actually "hated" was a repo that violated the contract of accepting a Unit of Work, not that a repo was using one. That is, nothing that accepts a Unit of Work should ever start/stop it, abstracting the transaction is kind of its whole purpose for being. I thought he was right be to against that usage, but misplaced the root cause of the issue.

But then I came across something that just made no sense to me. I couldn't for the life of me figure out where he got the idea that a repository "should be atomic". So I decided to go back to the source, PoEAA. And I mean the physical book, not the summary on Fowler's website.

Wow. I don't think my memory of the specifics of a Repository could be that far off.

As best as I can tell, my memory of the Repository pattern is tainted from simplified examples in Evan's DDD book and some of the DDDExample projects that surfaced after it. Continuing my reading, I found that Jimmy Bogard's second article touched on this. In fact, almost every repo I've seen in the wild followed this same pattern, which naturally leads to an IRepository<T>, because DRY.

As a recap, the PoEAA chapter on the Repository pattern clearly shows it as only accepting variations on the Query Object and/or Specification patterns. (Ironically, the example code actually used a base repository class). The concept of having Add/Update/Delete just weren't there. Though I saw nothing that would preclude it getting a Unit of Work either. The Repo's purpose is to abstract the execution of the Query Object instead of the Query Object doing that itself. The Repo does the actual execution by swapping out RepositoryStrategies. The strategies would be the things actually connected to EF, NH, ADO.NET, or some Web API.

As everything begins to come together in that Repository chapter, I find myself thinking that the ultimate culmination of that section of the book is an ORM, and using the abstractions over them for purposes other than DRY for reused queries/commands really is just an accidental implementation of the inner platform effect. That begins to align me to Ayende, Bogard, Smith, et al.

That is, if you're using an ORM, then you already have super powerful mature implementations of generic Specification (ICriteria, ISession.Query, IQueryable<T>), Unit of Work (ISession, DbContext), and Metadata Mapping (DbContext), and the Repository pattern is redundant. However, introducing the Query Object (or Command and Query Objects, or extension methods like suggested in some of the "hate" list) can help with reuse of common queries and/or complex queries.

The crux of the issue then becomes whether or not your architecture will allow composing Queries and Commands into a single Unit of Work or whether each one starts and stops its own.

I'm still not sure I'm comfortable letting my domain know about my ORM though. Having actually swapped out an ORM mid-project, I know it can happen, but for most projects I know it doesn't happen. But something about my domain having access to run db queries or manually manipulate the Unit of Work implementation just feels dirty. Given that 80% of the devs on any one project do not have the rigor of the other 20%, I feel that over time the project would just end up collapsing under the ignorance of the 80% and start looking a lot like ActiveRecord + Transaction Script. Even Microsoft's P&P Group managed to recommend an anemic domain model antipattern as the reference implementation even with the Repository pattern. I have little faith in the commons. I don't want to "protect the developer", but I do at least want to make it easier to do the right thing than it is to do the wrong thing.

[alanstevens]

Jason, thanks for the terrific commentary. I have always felt that I was missing something essential in the arguments against repositories. From your comments, it looks like I was fundamentally mistaken on what a repository actually is. If I follow your comments correctly, it looks like the IDispatcher in my code is a Fowler repository.

Once I get over being butt hurt over people criticizing the way I've been writing code, I've started to like the approach in my code sample. I still don't know if it holds up to criticism because nobody has commented directly about the code. I do like that it has an explicit unit of work in the IDataContext.

I have tried to make the abstraction around DbContext as thin as possible without taking a direct dependency on EF. This wouldn't allow for switching ORMs but, as you said, that is an edge case. All in all, your comments make me feel better about this approach. I think I will continue to pursue it and see if I can make it more production ready.

[panesofglass]

I have a hunch the reason "anemic domain model anti-pattern" becomes a common implementation is b/c OO is hard and data access is really very conducive to a function style of list processing and data structures.

The domain model, repository, and other related patterns are an attempt to model things according to OO. However, I have come to find those approaches more of a burden than a help. You won't really reuse any of those things. Why then bother with an OO approach? On the contrary, what you generally want is to retrieve some data structure from a data store. Data access queries typically the process of retrieving a stream / list of data and mapping those into desired data structures. When viewed this way, you are just discussing standard functional programming techniques, not an anemic domain model or transaction script OO patterns.

It's probably worth thinking about use of OO for the boundaries of modules where encapsulation actually matters. Within a module, encapsulation is much less useful. Across modules, you will typically expose only methods for those things that cross boundaries. I tend to think of OO as a paradigm that best fits scenarios where the Actor Model would be a good fit.

I usually tie my domain modules to their data access at a very high level so that the majority of the domain module is just processing lists of data structures provided from elsewhere. These functions are very easy to test. The modules expose an interface of behaviors only, so I still get good encapsulation without having to resort to weird tricks for testing. I also don't rely on or require dependency injection. Data access happens at the same top-level where I first start calling into my domain module functions to produce results.

On Twitter, you noted that this reminded you of how you used to do things, @alanstevens. I started in .NET around the time LINQ to SQL and EF were on the scene, so I never really did a lot of ADO.NET, but I found the micro-ORMs really eased a lot of the problems I had with some of the L2S and EF code I had used earlier. Perhaps it is a return to earlier styles, but I'm not convinced that's a bad thing. It may require a paradigm shift away from the "anti-pattern" noise from OO documents of the past, but the approach is really quite reasonable, simple, and very easy to follow, test, and reason about.

[alanstevens]

Ryan, thanks for your comments. I'm sympathetic to your arguments. I've made similar ones in the past. For years, I would take a data reader and convert it into a list of objects.

A couple of things motivate my pursuit of the approach under discussion here. First, EF is the elephant in the room. People make that their default data access approach without actually exploring others. That said, I do think there's some value to Identity Map (http://martinfowler.com/eaaCatalog/identityMap.html).

The arguments you make are arguments against ORMs in general. I don't hear nearly enough of those. In the spirit of strong opinions held lightly, I wish there were more debate on that topic. As it stands, I'm left trying to deal with EF in a sane manner. That's my narrow goal here. I don't think this is a complete solution, but it's a start.

[panesofglass]

I apologize for not making myself more clear. I didn't intend to say anything for or against EF. I should have clarified that

found the micro-ORMs really eased a lot of the problems I had with some of the L2S and EF code I had used earlier

was related to the various abstractions I tried to apply around EF / L2S to follow the OO paradigm, including repositories, repository strategies, units of work, etc. I think the larger problem is in trying to make ORMs do far more work for you than they probably should. I disliked EF 1.0 b/c, being new to .NET, I read the vote of no confidence written by people I looked to for guidance. I find I now disagree with that "vote." Mapping data into data structures and providing a direct query abstraction directly in the language is actually a very, very useful tool. Just don't let it go too far.

The same may be said for the size of most models I've seen. At a previous company, we had our entire database loaded into a single .edmx. This caused all sorts of problems for us, especially when we wanted to update it. We eventually started using little, targeted .edmx and .dbml files to create bounded contexts and modeled what we needed for a specific domain module.

In short, I don't think the data access tool you use is as important as how you use it. EF is a perfectly valid option. You just have to think about it more as a tool for getting the data you want for the purposes of your module, including direction of relationships, etc., than as a single representation of your database. This of course assumes you follow a modular architecture with bounded contexts.

[panesofglass]

I would also like to point out I don't "hate" repositories. I find them a less useful pattern for satisfying my data access requirements. Data is the slave of my domain, not the ruling overlord.

[alanstevens]

I hadn't heard the idea of making a bounded context by creating a DbContext with a small subset of the data. I find this idea attractive. Modeling a large, complex DB in one DbContext is part of why I hate DbContext. A smaller, targeted DbContext would function well as a repository.

[panesofglass]

@alanstevens, yes, I was surprised the first time I saw it, as well. We had about 5-7 such DbContexts when I left. Most had some representation of a User that typically varied based on need. We found it worked really well.

[jasonmacdee]

You guys have hit on some pain my main project has been feeling. We have a single massive domain model with some 200+ "logical aggregates" in it and poised to continue growing (it's a legacy migration). It's just too big for the tools, much less our heads. We've been looking at Bounded Contexts and Core Domain as solutions but been procrastinating in actually attempting them. We've actually had massive success in the basics of DDD allowing us to get where we are with little pain. Our previous attempts with BO/DO, ActiveRecord, and DataSet as ORM fell apart long before this point.

Something I've found is all of those patterns work so long as you have a "small" context. Small being a context that a single person can grok in about a week on their own. Perhaps the better solution is to focus on keeping things small, and what you do inside there doesn't really matter? Maybe that's why Microservices and Evan's push for Bounded Context seem to be taking off as of late.

[alanstevens]

Check out this feedback from @ashic:

Part 1: http://www.heartysoft.com/ashic/blog/2015/2/command-query-example-part1

Part 2: http://www.heartysoft.com/ashic/blog/2015/2/command-query-example-part2

[jasonmacdee]

Useful feedback. Curious to see where it goes when a Domain model gets added to the mix.

Moving the abstraction of the query/command up a level was unexpected, but I see the benefit. Could be especially useful in a situation where your services component might have polyglot persistence or partial BaaS. Services component at that point would almost act like a mashup layer and the query/command could coordinate across them if needed without building a shared infrastructure all over the place. Helps put the focus on reusable libraries instead of framework integrations.

Current state of it lends itself to having a single command per transaction as well, which I like as it more naturally ends up on a parallel with dispatching events afterward, forces the abstraction of "subcommands" into your domain and/or decouples events from those "subcommands" instead of ending up in the endless event loop, or dealing with unintentional sagas thanks to events being too fine grained for the business domain once you go past basic CRUD.

[bsimser]

Going to resurrect this after its three year hiatus. I'm wondering a few things:

• Where are we at, as a community, now with CQS vs. Repositories (or Repositories in general) specifically around dealing with DbContext
• Have we learned anything new that someone has some concrete examples on where things have evolved to
• Testing DbContext seems to have got better (with things like In-Memory databases) so is removing the dependency on DbContext with an interface the answer for that?
• Have we just swapped out a single IRepositoryX with a bunch of command and query objects instead?
• How do we test command and query objects?

[alanstevens]

I don't know what others are doing, but I've adopted Jimmy Bogard's MediatR library for message passing. In the handler, I use a small targeted interface for data access. It's an old school DAO, I suppose, but it works well. It may be on a full repository, but I only see what is specific to my handler. This gives me all the convenience of a repository but without the bloat. This is hardly CQRS, but it meets my needs.

I don't agree with all of Jimmy's conventions, but the core ideas that I use are there: https://github.com/jbogard/ContosoUniversityDotNetCore