3

I was wondering if building a repository on the top LLBLGen (adapter) is a good idea. I don't want to overengineer and reinvent the wheel again. The DataAccessAdapter class could be some kind of a generic repository.It has all the CRUD methods you need.

But on the other side for a larger project it could be good to have a layer between your ORM and service layer.

I'd like to hear your opinions, if your using the repository pattern with LLBLGen,if yes why if no why not.

If you have some implementation, post it please.

user137348
  • 10,166
  • 18
  • 69
  • 89

2 Answers2

2

The immediate benefit is preventing lock-in to a particular technology, giving you the flexibility to choose the appropriate technology later on.

IMHO, a more important reason is to enforce the Ubiquitous Language. As your application/system evolves, you'll need to query data in multiple ways. The Repository can help you encapsulate complex queries.

With a generic implementation, your consumer code might look like this:

customerRepo = ServiceLocator.Current.Resolve<IRepository<Customer>>();
var matchingCustomers = customerRepo.GetAll().Where(c => <some complex condition here>);

Using a repository, it would look like this:

customerRepo = ServiceLocator.Current.Resolve<ICustomerRepository>();
var matchingCustomers = myRepo.GetCustomersWithOrdersPendingFor(new DateTime(2010, 12, 31));
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The second example explictly states the intent of the query, making it easier/quicker to identify in the future.

However (just to complicate matters), you could use Query Specifications to isolate complex query logic, and use then with a generic Repository to get the job done. See this post to see how it's done.

I usually do the following:

  1. Create a generic repository (i.e. IRepository<TAggregateRoot>)
  2. Create repositories for each Aggregate Root, implementing IRepository<TAggregateRoot>
  3. Add query methods as needed to the appropriate repository
  4. When the repository gets too bloated, refactor the queries into separate Query Specifications

A final note: I once designed an app that worked in both on-line and off-line mode. The easiest solution was to implement two concrete Repositories (using a common interface), and switch between them when the client was connected/disconnected (another example of switching the persistence technology).

Vijay Patel
  • 17,094
  • 6
  • 31
  • 35
  • The latter I feel now is more a service layer but both should be sepearte, the idea of mixing pure repository stuff (Get(), GetAll(),GetByQuery etc..) with query specific stuff GetCustomersWithBlah feels messing, you have your query logic in various levels then. There no harm in nesting a generic repository inside CustomerQueryService etc.. –  Dec 30 '10 at 13:03
1

We are using the repository with LLBLGen, but with self-servicing. We are using the repository pattern for easing our unit tests. For simple insert/updates, the repository is simply calling the save method of the passed in entity. What we are eventually aiming for is passing domain objects (NOT LLBLGEN entities) back and forth between the repository and the business logic, and only have the ORM (LLBLEN, LINQ-To-SQL, etc) dependencies in the implemented repository.

Dan Appleyard
  • 7,405
  • 14
  • 49
  • 80
  • Interesting. Your domian object are separate object to entyties ? I guess you have to do some mapping between them. – user137348 Dec 23 '10 at 23:48
  • Well not yet, but eventually. With the separate domain objects, you could easily switch your data implementation from llblgen to something else (Linq to SQL, XML, whatever) and nothing else has to be touched (Bll layer, etc.). – Dan Appleyard Dec 24 '10 at 14:31