Tag Archive for 'autofac'

What is common between Autofac, Castle and MEF?

Published on July 17, 2008 in Uncategorized. 2 Comments

Ok, now it is official. The father of Autofac .NET IoC Container, Nicholas Blumhardt, has joined the team of Krzysztof Cwalina at Microsoft.

He will be the Program Manager in a team that’s building the Managed Extensibility Framework

Additionally Hamilton Verissimo (founder of the Castle project) will be joining the same team.

Congratulations and good luck, Nick! You can make the difference out there))

PS: Nick and Hamilton will still be able to spend as much time as they want on their pet projects. There’s the permission from Microsoft for that.

SubscribeTechnoratiDiggdel.icio.usFacebookReddit

Implementing ORM-independent Linq queries

Published on July 6, 2008 in Snippets. 7 Comments

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’

SubscribeTechnoratiDiggdel.icio.usFacebookReddit

Fluent interface from Autofac IoC in DSL configuration

Published on July 4, 2008 in Snippets. 0 Comments

Fluent registration API from the Autofac inversion of control container is really addictive.

I’ve just found myself writing the code for the DSL prototype project, that has nothing to do with the IoC (yet), but has feel similar to the Autofac component registrations:

/// <summary>  Default compiler pipeline for this project  </summary>
public sealed class MyPipeline : CompileToFile
{
  public MyPipeline()
  {
    var provider = new BaseClassProviderOnRules();

    // compile all *.boo from Requests folder against BaseRequestWorkflow
    provider.Register<BaseRequestWorkflow>(“Requests”, “InitWorkflow”)
      .Importing(“Request.Core”);

    // compile all *.boo from Requests folder against BaseRequestDocumenter
    // and add “_Documenter” suffix to class names
    provider.Register<BaseRequestDocumenter>(“Requests”, “DescribeWorkflow”)
      .Naming(file => file + “_Documenter”)
      .Importing(“Request.Core”);

    provider.Register<BaseClass>(“Samples”, “InitializeMethod”);

    // customize the compiler pipeline
    Insert(1, new UseSymbolsStep());
    Insert(2, new MultiBaseClassCompilerStep(provider));
  }
}
SubscribeTechnoratiDiggdel.icio.usFacebookReddit

Some notes on XPO and continuous validation testing

Published on May 21, 2008 in Articles and Lifehacks. 0 Comments

I’m really “deep in the trenches” right now due to two concurrent projects running. Nonetheless, here are just some quick notes:

  • Avoid using DevExpress XPO for large-scale projects where the future requirements could change. It is extremely easy to get started with that, but in the long term your DAL could become a bottleneck in the process of the project evolution (flexibility is too limited).
  • Do not use XPO 2 Linq! It supports only basic queries and has absolutely no documentation/matrix/test suite to validate and tell what’s working and what is not. Test suite of NHibernate 2 Linq is something I would expect to find in such a product.
  • There is another option for the single gateway interface (as in DevExpress XPO) utilized by xLim projects. That’s the WCF 2 Linq project or any other analogue (there surely be more of these as the technology gets adopted).
  • Some say that the combination of Final Builder and TeamCity is the most flexible for the integration purposes. Well, this could be true - FB even has tasks to deal with VMs.

Inspired by the abovementioned NHibernate 2 Linq test suite (it utilizes the power of MBUnit) I recently implemented a nice business test suite for the xLim2-2 application. Basically this is the test suite that re-uses connectivity and logic modules implemented with the help of Autofac IoC container (simple config is used to get them setup and running). The initialization happens in the global setup routine (supported by MBUnit). And then the actual tests just resolve some components/services from the main container (every test is running within its own container scope) and run simple assertions around these.

Example of an assert could be - “make sure that there are no critical errors in the system log”, “make sure that loose object references in the database point to each other” or “make sure that file store is in consistent state with the DB”.

So, provided you have the proper config and the compiled unit test, you just can point it to any production system and check its status in simple manner.

If we take the idea further, then these tests could be uploaded to the CruiseControl.NET to let them run against production on a schedule. And if something breaks - you’ll get the notification immediately (CC.NET will handle that).

Additionally it is easy to set up continuous statistics capturing via the same tech. So we get continuous system validation here and continuous system monitoring at the expense of writing just some validation tests and doing one-time setups.

SubscribeTechnoratiDiggdel.icio.usFacebookReddit

News bits: Microsoft Empower for ISV, Autofac article and some WPF patterns.

Published on April 19, 2008 in Uncategorized. 0 Comments

Bit 1: I’ve recently stumbled upon Microsoft Empower for ISV program. Now, that’s a deal - if you are an ISV developing for Microsoft technologies (or commit to deliver such a solution in 2 years) then for $400 per year you can get one MSDN Premium Subscription and for user licenses, up to five licenses to Vista, XP, Office 2003/2007, one server and up to for CALs to servers. The goodness lasts for up to 2 years. I wonder, what’s the catch?

Bit 2: Nicholas Blumhardt has published extremely thorough article on Dependency Injection with Autofac. The article is worth checking even if you think yourself to be familiar with this wonderful tool.

Bit 3: This blog post by Bryant Likes is an interesting collection of references to WPF-specific development patterns.

SubscribeTechnoratiDiggdel.icio.usFacebookReddit

What do you do when the IoC container grows big?

Published on March 19, 2008 in Uncategorized. 0 Comments

Nicholas Blumhardt has just released version 1.1 of his wonderful Autofac IoC container. The details are available at autofac community forum. You can download both .NET 2.0 version and .NET 3.5 version. Note, that .NET 3.5 version is much more powerful because of extension methods and lambda expressions.

And after this milestone there’s some logical transformation of the project on the way.

Autofac users have expressed their concerns of the core IoC growing too heavy because of all the extensions and integrations being developed. Additionally, there’s always some tendency for the core to be tweaked in order to accomplish something with some extensions.

I believe that’s what has happened with the Castle project. It got heavy.

Nick has agreed to isolate the core from the non-BCL integrations and extras and move them to a separate autofac-contrib project. This separate project will have the same continuous integration support and openness to the contributions.

Additionally there is some consideration to streamline and solidify the framework experience around autofac-contrib while keeping up with the principles of efficient development and D.R.Y.

Think of solution structure that has been designed with the framework extensibility in mind. For example, with the ability to get single integration library by just firing of the build script with the required switches. Something like:

go net2 –D:include=”nmock2,nhibernate,startable,coreutils” integrate distrib

Another opportunity being considered is to design integrations/extras with the replace-ability in mind (so that, for example, it would be much easier to replace one ORM with another, while keeping the interfaces the same).

What do you think?

SubscribeTechnoratiDiggdel.icio.usFacebookReddit

Know thy dependencies and control them efficiently

Published on March 9, 2008 in Lifehacks. 2 Comments

Nick has upgraded the MVC extension of Autofac to support the latest drop of ASP.NET MVC.

Unfortunately, this broke the integration server, since (as deduced from looking at the license) we can not redistribute the MVC binaries in the trunk\Resources\MVC folder, as it is with other build dependencies.

Fixing that was a trivial thing - install the latest and drop the assemblies into the cache. However, that was still some manual operation that could’ve been avoided.

In any proper and efficient development environment Don’t Repeat Yourself (DRY) principle is not limited by the code, it goes beyond and makes everything related to the project delivery more efficient (where appropriate and efficient).

We can’t do this in this situation due to the legal restriction. And every user trying to build autofac extension from the sources will have to repeat these actions of mine - find the proper redistributable, download it, install and make sure the assemblies are in the GAC.

Now, how efficient is that?

In any big project one could have more of this small and repetitive operations that stack up to take away your time, distract you or cause problems. This could be a bottleneck in critical situations.

Here’s simple efficiency test for you: “How much time would it take you to release your solution on a fresh development machine?”

Current xLim implementation has approx 36. projects and 11 external dependencies, but requires only install of .NET SDK 3.5 and DXperience 7.3.5 to release and configure it (Web UI, Desktop Smart Client, Server, Automation engine and tools) from the sources (and TortoiseSVN to get the sources). These two can be downloaded from the web storage (it is better even to have dedicated ftp to store them in one place as well).

Given that, hot fix becomes “no-problem” even if you are far away from the office and only have notebook with Windows XP, Internet connection and one hour.

Update: there are more details on this atomic solution structure in: Organization of xLim solutions: development, svn and integration

SubscribeTechnoratiDiggdel.icio.usFacebookReddit
« Older Entries