LLBLGen Pro 2.6 Available

Jeremy Skinner — Sun, 08 Jun 2008 12:05:53 +0000

Version 2.6 of my favourite Object Relational Mapper, LLBLGen Pro, is now available.

The main addition to V2.6 is support for a full Linq provider, so writing queries in LLBLGen just became a lot easier. V2.6 also includes a new Prefetching API which I wrote during the 2.6 beta period, which Frans then included in the product.

For example, to eagerly load a Customer -> Orders relationship prior to v2.6, you’d have to do something like this:

EntityCollection<CustomerEntity> customers = new EntityCollection<CustomerEntity>(new CustomerEntityFactory());
 
PrefetchPath2 prefetcher = new PrefetchPath2(EntityType.Customer);
prefetcher.Add(CustomerEntity.PrefetchPathOrders);
 
using(DataAccessAdapter adapter = new DataAccessAdapter()) {
	adapter.FetchEntityCollection(customers, null, prefetcher);
}

Now, with the lambda prefetching API you can do this:

using(var adapter = new DataAccessAdapter()) {
	var linq = new LinqMetaData(adapter);
 
	var customers = (from c in linq.Customers select c)
				.WithPath(path => path.Prefetch(c => c.Orders));
 
}

Likewise, if you wanted to filter the prefetched orders (eg, only return orders costing more than £10) and prefetch each order’s OrderDetail, you’d need to do something like this:

EntityCollection<CustomerEntity> customers = new EntityCollection<CustomerEntity>(new CustomerEntityFactory());
 
PrefetchPath2 prefetcher = new PrefetchPath2(EntityType.Customer);
prefetcher.Add(CustomerEntity.PrefetchPathOrders, 0, new PredicateExpression(OrderFields.TotalCost > 10))
	.SubPath.Add(OrderEntity.PrefetchPathOrderDetail);
 
using(DataAccessAdapter adapter = new DataAccessAdapter()) {
	adapter.FetchEntityCollection(customers, null, prefetcher);
}

…while now you can do this:

using(var adapter = new DataAccessAdapter()) {
	var linq = new LinqMetaData(adapter);
 
	var customers = (from c in linq.Customers select c)
				.WithPath(path =>
					path.Prefetch<OrderEntity>(c => c.Orders)
						.FilterOn(o => o.TotalCost > 10)
						.SubPath(orderPath => orderPath.Prefetch(o => o.OrderDetail))
				);
 
}

Lambdas rock

Linq Repositories

Jeremy Skinner — Mon, 24 Mar 2008 19:49:22 +0000

Recently, the beta of Linq to LLBLGen Pro was announced, which adds linq-querying capabilities to LLBLGen, the Object Relational Mapper that I use in most of my projects.

LLBLGen’s querying API is very powerful, but also somewhat complex. For example, to retrieve a list of orders from all customers in the Northwind database for customers in the UK, you would write something like this:

EntityCollection<OrderEntity> orders = new EntityCollection<OrderEntity>(new OrderEntityFactory());
RelationPredicateBucket bucket = new RelationPredicateBucket(CustomerFields.Country == "UK")
bucket.Relations.Add(OrderEntity.Relations.CustomerEntityUsingCustomerId)
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
	adapter.FetchEntityCollection(orders, bucket)
}

Linq support maintains the type safety, whilst also allowing this query to be expressed in a more SQL-like fashion (which I personally find to be more intuitive):

using(DataAccessAdapter adapter = new DataAccessAdapter())
{
	var meta = new LinqMetaData(adapter);
	var query = from o in meta.Order
			where o.Customer.Country == "UK"
			select o;
 
	var results = query.ToList();
}

This got me thinking…now that there are several ORMs that have linq support, wouldn’t it be nice if there was a consistent method for performing linq-based queries, independent of the underlying ORM implementation. And thus the linq-repository was born.

The majority of the work is done by the BaseRepository class which acts as a wrapper around the underlying linq provider. There’s also an IRepository interface which the BaseRepository implements:

public interface IRepository<T> : IQueryable<T> where T : class
{
	void Save(T toSave);
	void Save(T toSave, bool isNew);
	void Delete(T toDelete);
}
 
public abstract class BaseRepository<T> : IRepository<T> where T : class
{
	private IQueryable<T> source;
 
	protected IQueryable<T> Source
	{
		get { return source; }
		set { source = value; }
	}
 
	protected BaseRepository(IQueryable<T> source)
	{
		this.source = source;
	}
 
	IEnumerator<T> IEnumerable<T>.GetEnumerator()
	{
		return source.GetEnumerator();
	}
 
	public IEnumerator GetEnumerator()
	{
		return source.GetEnumerator();
	}
 
	public Expression Expression
	{
		get { return source.Expression; }
	}
 
	public Type ElementType
	{
		get { return source.ElementType; }
	}
 
	public IQueryProvider Provider
	{
		get { return source.Provider; }
	}
 
	public abstract void Save(T toSave);
	public abstract void Delete(T toDelete);
	public abstract void Save(T toSave, bool isNew);

Note that the constructor for BaseRepository takes an IQueryable representing the underlying linq provider. Now, the LLBLGen-specific subclass:

public class LLBLGenRepository<T> : BaseRepository<T> where T : EntityBase2, IEntity2, new()
{
	public IDataAccessAdapter Adapter { get; private set; }
 
	public LLBLGenRepository(IDataAccessAdapter adapter, IElementCreator2 elementCreator)
			: base(CreateQuery(adapter, elementCreator))
	{
		this.Adapter = adapter;
	}
 
	private static IQueryable CreateQuery(IDataAccessAdapter adapter, IElementCreator2 elementCreator)
	{
		return new DataSource2(adapter, elementCreator, functionMappings, null);
	}
 
	public override void Save(T toSave)
	{
		if (toSave == null)
			throw new ArgumentNullException("toSave");
 
		Adapter.SaveEntity(toSave);
	}
 
	public override void Save(T toSave, bool isNew)
	{
		if (toSave == null)
			throw new ArgumentNullException("toSave");
 
		if (isNew) toSave.IsNew = true;
 
		Adapter.SaveEntity(toSave);
	}
 
	public override void Delete(T toDelete)
	{
		Adapter.DeleteEntity(entity);
	}

Note that the constructor for the LLBLGenRepository takes instances of an IDataAccessAdapter and an IElementCreator (the two objects necessary for running linq-queries against LLBLGen) and creates a DataSource2 object (the LLBLGen query provider) which is then passed to the BaseRepository’s constructor.

So, I can now write code like this:

IRepository<OrderEntity> orders = new LLBLGenRepository<OrderEntity>(new DataAccessAdapter(), new ElementCreator());
 
var query = from o in orders
		where o.Customer.Country == "UK"
		select o;

To remove the calls to new DataAccessAdapter() and new ElementCreator(), I moved the responsibility for instantiating the repository over to an IoC container:

//in my application startup routine:
IoC.Initialise(new WindsorContainer());
IoC.Container.AddComponent<IDataAccessAdapter, DataAccessAdapter>();
IoC.Container.AddComponent<IElementCreator2, ElementCreator>();
IoC.Container.AddComponent("Repository", typeof(IRepository<>), typeof(LLBLGenRepository<>));

The IoC static class is simply a wrapper for the Windsor container.

Now I can instantiate repositories like this:

IRepository<OrderEntity> orders = IoC.Resolve<IRepository<OrderEntity>>();

I don’t really like this, so I wrap it in a static gateway:

public static class Repository
{
	public static IRepository<T&t; For<T>() where T : class, new()
	{
		return IoC.Resolve<IRepository<T>>();
	}
}

…and now I can write queries like this:

var query = from o in Repository.For<OrderEntity>
		where o.Customer.Country == "UK"
		select o;

Alternatively, now that the repository is registered with Windsor, I can inject the repository directly into my ASPNET MVC Controllers:

public class OrdersController : ConventionController
{
	private IRepository<OrderEntity> ordersRepository;
 
	public OrdersController(IRepository<OrderEntity> repository)
	{
		this.ordersRepository = repository;
	}
 
	public void OrdersFromCustomersInTheUk()
	{
		ViewData["orders"] = from o in ordersRepository
						where o.Customer.Country == "UK"
						select o;
	}
}

Technical Jargon » LLBLGen Pro

LLBLGen Pro 2.6 Available

Linq Repositories