Tag Archive for 'ORM'

Linq queries with parameters for your ORM IRepository

Ricardo Cavalcanti has raised question on fluent passing of parameters into the queries encapsulated by the QueryFor (specification) pattern.

Let’s talk about the easiest option of passing parameters, first. It requires no new code at all and is just about chaining queries:

var list = customers
	.Find<ImportantCustomers>()
	.Where(c => c.City == "Ufa");

Where comes from the in line extension method provided by Linq.

However, in certain situations Linq might be not enough. This involves queries that encapsulate come complex business logic or require parameter pre-processing, that you want to hide away.

Continue reading ‘Linq queries with parameters for your ORM IRepository’

Options of separating queries from the ORM Repository

Let’s get back to the discussion from XPO+ORM+IOC series on Implementing ORM-independent Linq queries.

As you can see from the previous post, there are 3 options to abstract away queries in a testable manner (and we will add one theoretical one for the Boo):

1. Put queries right into some domain-specific repository implementation (i.e.: CustomerRepository.FindImportantCustomers) and ask the container about it.

  • Pro: Simple and looks as if there is no logical separation between the repository and queries
  • Con: Low scalability
  • Con: Coupled code that would take some effort to test

2. Put queries into the extensions that use Repository[T].Find method.

  • Pro: A bit more abstraction and testability, than in the previous option
  • Con: Does not make a lot of sense

Continue reading ‘Options of separating queries from the ORM Repository’

Implementing ORM-independent Linq queries

We’ll get back from the Boo + Business + DSL to the XPO + ORM + IOC series for a little bit.

Nicholas Blumhardt has just written an interesting and extremely thorough article on Implementing the Specification Pattern via Linq. Let’s try to play with the idea and take it a one step down the road. Here we can:

1. Add ORM abstraction by implementing generic IRepository (of T) interface:

public interface IRepository<T>
{
	IQueryable<T> Find(QueryFor<T> query);
	IQueryable<T> Find(string criteria);
	IQueryable<T> Find<K>() where K : QueryFor<T>, new();
	IQueryable<T> Query();

	// ...
}

Continue reading ‘Implementing ORM-independent Linq queries’

XPO hosted on a web site (remoting with binary encoding + http channel)

Below you will find an extremely simple prototype that uses XPO hosted within web application (http channel) with the binary encoding. You will need to have DevExpress components installed and Visual Studio 2008.

Now, before you continue, here is an important caveat - don’t use XPO in any complex project. It will just become bottle-neck there.

In my case complex project means:

  • 41 Visual Studio projects (74k LOC and 35k statements)
  • 3 integration projects on CC.NET
  • 417 revisions over 6 months
  • 2Gb+ FileStore in production system
  • All the features of the xLim 2 approach (and some more)

Here’s the Kiviat metrics graph:

xLim 2-2 Kiviat Graph

And these are some of the problems with the XPO:

  • Linq2XPO implementation is horrible (I’m not even talking about decent documentation)
  • Flexibility is extremely low (most of all I miss custom mapping routines and ability to specify custom queries)
  • Generated SQL is quite inefficient in complex requests
  • Remote communication is too chatty by default

As you can see, these problems of mine mostly come from the Lego scenario.

If I were able to start the project from scratch, then I’d probably (would have to do some prototyping first) use NHibernate. Half a year ago there was no chance of using it, since DX controls would not be able to work with NHibernate in server mode.

Ok, you have been warned. Now you finally can download sample of XPO hosted on a web site (remoting with binary encoding + http channel).

XPO-related changes that are needed to make the ORM+IoC samples work.

Below you will find the description of the minimal changes to XPO sources to make the ORM+IoC series samples work. Obviously, I’m quite limited with that, since these sources are commercial.

That’s the new method that we have to add to ReflectionDictionary to make it recognize out interfaces:

public void AddClassInfo(Type service, XPClassInfo implementation)
{
  classesByType.Add(service, implementation);
}

Or one could just add method that looks up existing type registration and re-registers it as service type, while hiding the ClassInfo specifics.

The changes, that differ FireSession (and logically linked classes) from normal Session, revolve around the delivery of the _resolver delegate from the FireSession Constructor to this method inside ObjectLoader:

void CreateTypedObject(object id, XPClassInfo classInfo) {
  theObject = null == _resolver ?
    classInfo.CreateObject(loader.Session) :
    _resolver(classInfo.ClassType);
  cache.Add(classObjects, theObject, id);
}

The _resolver delegate is a simple lambda passed down from the IoC:

private Func<Type, object> _resolver;
...
// register FireSession with the default data layer
builder.Register<Session>(
  c => new FireSession(type => c.Resolve(type))).ContainerScoped();

Note: these 30min hacks are neither stable nor intended for production. It would require at least XPO unit-test suite and IoC+ORM functionality/integration tests to stabilize them with all the required usage scenarios. And that’s out of the scope of the current research.

In my next article I’ll get to the topic of the efficient unit-testing of decoupled components with the MockContainer. That’s where we left the xLim 2 series.

How to implement unit-testable abstraction and reusable domain models with IoC + ORM?

In the previous post in ORM+IoC series we’ve managed to decouple away from the ORM-based collection and the literal-based syntax (which was bound to the logics of eXpress Persistent Objects ORM).

In this post we’ll try to get rid of all the remaining coupling (while making it unit-testable) and even add domain-based extensibility that is easy to implement.

Let’s modify the code:

public sealed class DisableAllAccounts : ICommand
{
  private readonly IOrderedQueryable<IAccount> _accounts;
  private readonly ILog _log;

  public DisableAllAccounts(IOrderedQueryable<IAccount> accounts, ILog log)
  {
    _accounts = accounts;
    _log = log;
  }

  public void Execute()
  {
    _log.Write("Disabling accounts:");

    var accounts = from c in _accounts
                   where (c.Disabled == false)
                   select c;

    foreach (var account in accounts)
    {
      IComment comment = account.CreateComment();
      comment.Text = string.Format("Account {0} was disabled on {1}",
        account.FirstName, DateTime.Now);
      comment.Save();
      account.Disabled = true;
      account.Save();
    }
  }
}

Continue reading ‘How to implement unit-testable abstraction and reusable domain models with IoC + ORM?’

How to use ORM (XPO), IoC, C# 3.5 syntax, Linq and .NET 2.0 together?

One of the most important features of any proper development architecture, environment or process, is that the synergy (network) effects accumulate, if you keep doing the right things. IoC/DI, unit testing and TDD, continuous integration - all these just form up the external side of how everything works. They simply help (or force) to shape the logics of the development to make everything fold smoothly and let your solutions accumulate the benefits.

Now, let us get back to the IoC+ORM series and take one more look at the ICommand implementation from the last post. It could be improved quite a bit:

public sealed class DisableAllAccounts : ICommand
{
  private readonly IRepository<Account> _accounts;
  private readonly ILog _log;

  public DisableAllAccounts(IRepository<Account> accounts, ILog log)
  {
    _accounts = accounts;
    _log = log;
  }

  public void Execute()
  {
    _log.Write("Disabling accounts:");
    _accounts.CriteriaString = "Disabled=0";
    foreach (var account in _accounts)
    {
      _log.Write(account.Name);
      account.Disabled = true;
      account.Save();
    }
  }
}

Things become better as we throw out things that do not fit well. So let us remove our custom IRepository<> from this picture (along with the FireCollection behind it) and get rid of the string literal in favor of something that is compiler-checked

Continue reading ‘How to use ORM (XPO), IoC, C# 3.5 syntax, Linq and .NET 2.0 together?’