LINQ to SQL using SoC

June 23, 2010 09:55 by bryan

I have had a few people saying that LINQ to SQL is hard to use for Separation of Concerns, so I've created a small project that show how to do it.  I have used the MEF as my SoC framework.

Project is using .Net 3.5

SoCLINQ2SQL.zip (905.61 kb)

To enhance this it is worth look at Mike Hadlow post of Repository.GetById using LINQ Expression Syntax


MEF not supporting open generic types

June 23, 2010 09:32 by bryan

If you are trying to use MEF with open generic types like:

[Export(typeof(IRepository<>))]
public class itial; padding: 0px; margin: 0px; border: 0px initial initial;">Repository<T> : IRepository<al; background-color: transparent; color: black; background-position: initial initial; background-repeat: initial initial; padding: 0px; margin: 0px; border: 0px initial initial;">T>
   
where T : class
{

With an import of

[Import(typeof(IRepository<>))]
private IRepository<Contact> repository;

You'll come stuck, as the current implementation MEF does not support Open Generic Types.

For more information take a look at Glenn Block article Why doesn’t MEF support open-generics for exports? Because MEF is not type based

Also there is Open-generic support in the MEF Contrib, which can be found on codeplex.

The reasoning is this, MEF parts relate on contracts which are strings, not types. To illustrate, see the code below.

namespace Orders {

  public interface IOrderRepository {}

  [Export(typeof(IOrderRespository))]

  public class OrderRepository : IOrderRepository {

  }

}

Although I have passed typeof(IOrderRepsitory) to the export, that is just a convenience that gets converted to a contract name of "Orders.IOrderRepository". The same applies to the importer...

[Export]

public class OrderService(

  [Import]

  public IOrderRepository Repository {gets;set;} 

)

The import on IOrderRepository also gets converted to a contract name of "Orders.IOrderRepository". This way the container is able to satisfy the import as the 2 contracts match. In the same way we support closed generics, so....

public interface IRepository<T> {}

namespace Orders {

  [Export(typeof(IRepository<Order>))]

  public class OrderRepository : IRepository<Order> {

  }

}

[Export]

public class OrderService(

  [Import]

  public IRepository<Order> Repository {gets;set;} 

)

Will work because the OrderRepository is exporting the contractname "Orders.IRepository<Order>" and the OrderService is importing the same contract.

However, this is what it looks like if we try the same with open generics.

public interface IRepository<T> {}

namespace Utils {

  [Export(typeof(IRepository<>))]

  public class Repository : IRepository<T> {

  }

}

[Export]

public class OrderService(

  [Import]

  public IRepository<Order> Repository {gets;set;} 

Now the contract names will be different. The exporter will have a contract of  "Utils.IRepository<>" and the importer will have a contract of "Utils.IRepository<Order>".

It is a simple match up, that breaks down in the open-generics case. This is because fundamentally, MEF is not matching on type.

Original article form codeplex


How to get MEF to load all Assemblies in a directory

June 4, 2010 11:17 by bryan

The nice thing about MEF is the ability to dynamically load additional modules in to an application with very little effort.

To make it even easier, I've generated a small MEF Compose which will load up all DLL in a directory automatically.

1
2
3
4
5
6
7
8
private void Compose()
        {
            var catalog = new AggregateCatalog(
                new AssemblyCatalog(System.Reflection.Assembly.GetExecutingAssembly()),
                new DirectoryCatalog(@".\Extensions"));
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
        }

The above code works well for .NET, however for some reason .NET 3.5 version, which is available from CodePlex just comes back with nulls, so here is a solution for MEF for .NET 3.5

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
private void Compose()
        {
            var key = Assembly.GetExecutingAssembly().GetName().GetPublicKey();
            var catalog = new AggregateCatalog();
            catalog.Catalogs.Add(new AssemblyCatalog(Assembly.GetExecutingAssembly()));
            var dir = new DirectoryInfo(@".\Extensions");
            Assembly assembly;


            foreach (var file in dir.GetFiles("*.dll"))
            {
                assembly = Assembly.LoadFile(file.FullName);
                byte[] assemblykey = assembly.GetName().GetPublicKey();
                catalog.Catalogs.Add(new AssemblyCatalog(assembly));
            }


            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
        }

 

 


Using MEF to provide PlugIns

May 27, 2010 14:54 by bryan

MEF has now been released, a Plug-In Framework, for .Net 4.0

After reading up on CodePlex, I have generated a small application that provides a plug-in framework, see attached below.

http://mef.codeplex.com/wikipage?title=Guide&referringTitle=Overview

MEF.zip (70.88 kb)

I've also produced a .NET 3.5 version too:

MEF in 3.5.zip (427.41 kb)

Few MEF links:

Glenn Block

Nicholas Blumhardt

MEF on CodePlex

Channel 9 Silverlight 4 MEF Screencasts

MEF 101