Rinat Abdullin

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.

Tags: DevExpress, ORM, XPO

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

Tags: autofac, DevExpress, IoC, Linq, ORM, XPO

You can build a house with big LEGO blocks. Can you add a nice porch?

Company buys some business framework that seems to match their needs in the short-term perspective. It is easy and fun to use it initially - you just need to work with some big building blocks and the framework will do the rest for you.

As the time goes, company gets to met new requirements that steer to them from the probable future that they’ve never considered (this always happens). Every encounter will be like a gamble. You’ve got 80% that you can deliver solution that meets this requirement using just the provided building blocks.

And there is 20% chance that you will just will not have LEGOs for a trivial task of simply adding a nice porch to the house (and if you keep on gambling, you will always lose, unless you control the game).

› Continue reading

Tags: management, thoughts

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

Tags: autofac, DevExpress, IoC, Linq, ORM, R#, XPO

Some side thoughts on the development

Empirical observation from the Project Management field of knowledge tells us that planning ahead of time saves a lot of resources down the road (entire PMBoK thing is basically just about this and the common dictionary thing).

As the level of complexity increases, projects require more planning in order to be efficient and succeed. Large-scale construction projects is one of the most vivid examples of that.

So, why do not people use similar principles in the development widely? Then, we could improve our success rate and save the resources by implementing certain functionality just with the component interactions (vertical solution architecture) instead of hard coding it. And I’m not even talking about constant quality, efficiency and risk management.

Reasons like “you just do not have the crystal ball to know about all the requirements” or “development is an art, and you can neither plan or control this” just do not seem to be valid.

• A. You can know about all the requirements that matter or that could matter (you just need to concentrate on these). All the information is available. You just have to work hard with it.
• B. Development is purely about logics (although efficient logical compositions are beautiful, just like it is with the math equations). If the same unit-test being run three times could fail once due to some unpredictable magic, then this would be art to develop something stable in such environment.

PS: the answer to the “Why” question is simple - the development looks too easy to start these days, while planning requires some effort. However, as the project goes - they swap places.

PPS: There actually are development situations where non-deterministic test results are possible (i.e.: sampling performance of neural network “learning” speed or the capability of evolution algorithms to avoid local extrema). Dealing with these could be considered an art. Fortunately, every-day development projects rarely have to deal with these.

Tags: management, thoughts

How to inject ORM with some IoC?

This post continues ORM+IoC series, namely - the discussion initiated by “How to decouple your code from ORM (XPO) while granting it the power to IoC?” and comments that followed.

Let us try to inject ORM itself with some IoC and see what happens. Take a look at the following exaggerated command example:

public sealed class CreateRandomAccount : ICommand
{
  private readonly Account _account;
  private readonly ILog _log;

  public CreateRandomAccount(Account account, ILog log)
  {
    _account = account;
    _log = log;
  }

  public void Execute()
  {
    _log.Write("Creating new random account");
    _account.Name = Guid.NewGuid().ToString();
    _account.Disabled = true;
    _account.Save();
  }
}

I like to use some ICommand implementations as examples since they help to crystallize the effects of IoC in one single piece.

The code above, being resolved in some container, just does what it says: it asks for the class (registered as Factory instance) and saves it to some repository. IoC uses Session from the current scope to create the instance and so it will use UoW, session in transaction or whatever session descendant is available in the container. Additionally it writes a note to the logger.

› Continue reading

Tags: autofac, DevExpress, IoC, XPO

Developer Express has announced DXperience 2008 vol 1 beta

There are quire a few breaking changes for this one, although they seem to be just minor things.

List of changes in this version is available as well.

A couple of remarks on the changes:

• Rich Text Editor for ASP.NET 2.0 (Desktop version is probably lurking around somewhere as well)
• TreeView-Grid Hybrid for ASP.NET 2.0
• Some unit tests have been made available. That’s the step towards improving development experience of customers. One can feel himself more safe while making changes in the code with test coverage.
• Desktop UI has got cute apple skin. Additionally ASP.NET controls have got consistent theming support.
  
• Linq Server Mode has been mentioned a few times.
• eXpress Application Framework changes are surprisingly limited. It feels like the development team has been assigned away from the project.

Tags: DevExpress, XAF