Repository pattern vs. “smart” business objects [closed]

Question

I see two main "schools of thoughts" when it comes to creating larger-scale enterprise-wide apps on .NET (Winforms, WPF, ASP.NET).

Some folks use the "repository pattern" which uses a repository that knows how to fetch, insert, update and delete objects. Those objects are rather "dumb" in that they don't necessarily contain a whole lot of logic - e.g. they're more or less data-transfer objects.

The other camp uses what I call "smart" business objects that know how to load themselves, and they typically have a Save(), possibly Update() or even Delete() method. Here you really don't need any repository - the objects themselves know how to load and save themselves.

Big question is: which do you use or prefer? And why?

Do you use the same approach in all your apps, or do you have any particular criteria when to choose one approach over the other? If so - what are those criteria?

I'm not trying to start a flame-war here - just trying to find out what everyone thinks about this and what your opinion is, and why you use one (or both) patterns over the other.

Thanks for any constructive input!

Answer 1

I use the repository pattern because of the Single Responsibility Principle. I don't want each individual object to have to know how to save, update, delete itself, when this can be handled by one single generic repository

Answer 2

The repository pattern doesn't necessary lead to dumb objects. If the objects have no logic outside Save/Update, you're probably doing too much outside the object.

Idealy, you should never use properties to get data from your object, compute things, and put data back in the object. This is a break of encapsulation.

So the objects should not be anemic except if you use simple DTO objects with CRUD operations.

Then separating the persistence concerns from your object concerns is a good way to have Single Responsibility.

Answer 3

Here are two interesting articles I came across

Repository-is-the-new-singleton

The DAL should go all the way to UI

Answer 4

I think the most important side-effect of using the Repository pattern vs. the ActiveRecord pattern is testing and extensibility.

Without having your ActiveRecord object contain a repository itself how would you isolate data retrieval in your test cases? You can't really fake or mock it easily.

Besides testing it would also be much more difficult to swap out data access technologies, for example from Linq-to-SQL to NHibernate or EntityFramework (though this doesn't happen often admittedly).

Answer 5

It really depends on the needs of the application, but when dealing with a complex business model, I prefer ActiveRecord. I can encapsulate (and test) the business logic all in one place.

Most ORM's (EF, nHibernate, etc...) serve as your Repository. Many people consider a layer on top of an ORM that encapsulates all data interaction as a Repository, which I believe to be incorrect. According to Martin Fowler, a Repository encapsulates data access as a collection. So having individual methods for all data retrieval/mutation might be using a Data Mapper or a Data Access Object.

Using ActiveRecord, I like to have an "Entity" base class. I typically use an ORM (repository) with this base class, so all of my entities have a GetById, AsQueryable, Save and Delete methods.

If I'm using more of a Service Oriented Architecture, I'll use a repository (one that masks direct data access or an ORM) and call it directly in my services.