MEFGrid

January 15th, 2009

Daniel managed to create a sample that goes over virtually all features of MEF. Mind blowing, I know. That’s why he’s know as “da man” in the team.

If you’re following MEF you should check it. Make sure you also subscribe to his blog.

Categories: MEF | Top Of Page | No Comments » |

A small excerpt from the IoC Container doc

January 7th, 2009

Twitter followers probably know that I’ve been working on an IoC Container document for my team. It goes over several aspects – including why in my view “DI” is a wrong term and should be banished – from history to features and scenarios. I got permission to release some bits of it in the future. The following however is an excerpt I thought I should share.

Another important aspect of common use of IoC Containers lies on the fact that the components that make up an application play no role in defining or constraining the implementation that can satisfy a dependency. The minimal safety is provided by strongly typed contracts, but it ends there. All binding is left for an external entity – the application host.

Given that the ultimate goal is to reduce coupling and promote reuse, this approach makes a lot of sense as it allows components to be used anywhere, with or without a container.

The component can express what is required or optional using natural OOP idioms. For example, multiple constructors will allow the IoC Container to call the one it can satisfy the most arguments. Also public writable properties are considered optional dependencies for most containers. Note that the container is just playing the role of a user of the class, checking constructor overloads and properties that they can provide values for, absolutely no different from a human interacting with the same class.

By sticking with these natural idioms a class will be naturally decoupled, easy to be reused and easy to be tested. The fact that it also plays well with IoC Containers is a consequence of the decoupling exercise, and should not be misunderstood as the main driver.

Categories: IoC, MS | Top Of Page | 7 Comments » |

Some Castle related news

January 5th, 2009

During the holiday – and between Wow quests and dungeons – I’ve managed to apply a bunch of patches and to fix some outstanding bugs on the Components and Windsor projects.

Another interesting accomplishment is some contributions finally made in and Castle.Core, Castle.MicroKernel and Castle.Windsor are now Silverlight ready.

Last but not least, I recently applied a patch that made Castle.DynamicProxy 2 also available for Silverlight.

The pending items now are:

- Fix the build so the bits targeting SL will be correctly build and made available through our build server

- Change Windsor to use the SL version of DynProxy.

Thanks for all the patches, people. Keep them coming! :-)

Again on internals

December 9th, 2008

Dave (he’s a dev on our team) outlines how some things work here, and how difficult it is to decide in favor of openness by default.

Categories: MS | Top Of Page | 2 Comments » |

Castle Windsor and the WCF Facility

December 2nd, 2008

If I recall correctly, Ayende started the WCF Facility several months ago and Craig took over and have been improving it almost daily since then. As a completely ignorant on WCF, I have no idea on how it works and how to use it.. so Mike’s post sure came handy :-)

Given the amount of changes in Craig’s last commit there’s a lot to blog about..

On internals

November 13th, 2008

I hate internals and privates and lack of extension points. Really! Many times I’ve wondered ‘what’s wrong with these people that hide all this stuff from me? are they concerned I wouldn’t know how to use it?’

Being on the other side now, and trying to slowly change the culture, I have to say that I understand why MS is so reluctant to make things more open by default. And all comes down to the fact that we don’t make breaking changes.

If we were to open a poll and ask developers what they would prefer: more open and extensible API vs no breaking changes, I’d guess you would go with open/extensible. And later act surprised when a new version of the framework broke your app, forced you to make changes on your code in order to get it compiling, and so on.

That doesn’t mean that openness is forbidden and extension points are evil. Just that we think very – and I mean _very_ – carefully about those. Once we ship it, we can’t remove it. We can’t change it. Ever!

That being said, I think we are going slowly but surely in the direction of open-closed principle and composition over inheritance, at least on my team, and this is enough to make me happy (for now).

Categories: MEF, MS | Top Of Page | 9 Comments » |

MEF/Lifetime: NonShared support

November 10th, 2008

MEF currently support two creation policies: Singleton and Factory. You can think of them as Singleton and Transient or even better: Shared and NonShared. Supporting NonShared is very convenient to users, but comes with costs. So we are considering supporting only Singletons in V1.

In the end, all these control your choice of how state should be shared or not between consumers. If you expose an IEmailSender implementation, whether it should be shared between users or not will depend on how much you care about sharing or not the state – if any – in the service implementation.

It doesn’t mean that you can’t mimic NonShared behavior. It just means that you have to write a bit more code in order to do that.

Say that you have a Foo component, and you want that each “consumer” of Foo to have their own exclusive, non-shared copy of it:

public class MyObject
{
    [Import]
    public FooFactory Factory { get; set; }
    
    private Foo _foo;
    public Foo Foo 
    { 
        get 
        { 
            if (_foo == null) 
            {
                _foo = Factory.CreateFoo();
            } 
            return _foo;
        }
    }

    public void DoWork()
    {
        // Do work with Foo
    }
}

So MyObject cannot simply import Foo. It needs to import something that carries the semantic of creating always a new instance. So it imports a Factory that you created.

Now you probably have a Foo that has dependencies. Fair enough. You can support that using at least two approaches.

In the first scenario, you know before hand the dependencies:

public class Foo
{
    public Foo(Baz baz)
    {
       Baz = baz;
    }

    public Baz Baz { get; set; }

    public Bar Bar { get; set; }
}


public class FooFactory
{
    [Import]
    public Bar Bar { get; set; }

    [Import]
    public Baz Baz { get; set; }

    public Foo CreateFoo()
    {
        var foo = new Foo(Baz);

        foo.Bar = Bar;

        return foo;
    }
}

The second situation you do not know the dependencies:

public class Foo
{
    // Assume Foo has unknown dependencies
}

public class FooFactory
{
    [Import]
    public ICompositionService CompositionService { get; set; }

    public Foo CreateFoo()
    {
        var foo = new Foo();

        CompositionService.SatisfyImports( CompositionServices.CreateAttributedPart(foo));

        return foo;
    }
}

We are really looking for feedback on this one. Do you think that’s reasonable? Would you be angry or frustrated if you had to write this code? And before you ask, we are not considering ripping off the feature because we don’t have anything better do to. :-) It all comes down to the fact that supporting factories lead to situations that we are unable to provide good solutions for.

Categories: MEF, MS | Top Of Page | 13 Comments » |

Session on Windsor

November 4th, 2008

Great talk on Castle Windsor from Gojko and Mike.

I especially appreciate that Mike was careful on the terms, patterns and principles – even though I have my disagreements :-) But I’ll refrain from nitpicking. Great talk again, I could never do it better.

Changes to Castle Project

October 31st, 2008

I’m happy to announce a few changes that the PMC agreed upon regarding how Castle Project will be led from now on. These changes are long overdue, and intend to fix our release and documentation debts.

Projects will be split

Until now each Castle release was a bundle release. This is good and problematic. Some unstable projects drag the release of stable ones. We lose momentum and everybody’s miserable.

From now on, each project will be a top-level project, having its own release cycle.

Each project will have its leader

We have always had collective ownership, if you’re a committer you can make changes to whatever you want.

One can be more attached to a project than others. We decided that each top-level project should be led by a committer. He should oversee the project in near and long terms, keep the documentation, take care of patches, set goals and roadmaps, seek collaboration and release the bits.

Project list – with leader

Here is a list of the projects and who is leading them:

Main projects

  • ActiveRecord (Markus Zywitza)
  • MonoRail (Ken Egozi)
  • MicroKernel/Windsor (Ayende)

Tools

  • DynamicProxy (Jonathon Rossi)
  • NVelocity (Jonathon Rossi)
  • Visual Studio Integration (Jonathon Rossi)

Facilities

  • ActiveRecordIntegration
  • AutomaticTransactionManagement
  • BatchRegistration (Alex Henderson)
  • db40 Integration (Henry Conceicao)
  • EventWiring (Henry Conceicao)
  • FactorySupport (Alex Henderson)
  • Logging (Alex Henderson)
  • NHibernateIntegration (Tuna Toksöz)
  • Remoting (Henry Conceicao)
  • Startable (Richard Fleming)
  • Synchronize (Craig Neuwirt)
  • TypedFactory (Alex Henderson)
  • Wcf Integration (Craig Neuwirt)

Components

  • Validator (Andrew Hallock)
  • Transaction Services (Ernst Naezer)
  • Logging Services (Ernst Naezer)
  • DictionaryAdapter (Craig Neuwirt)
  • Binder (Ernst Naezer)
  • Email/TemplateEngine
  • Scheduler
  • Pagination (Colin Ramsay)

Notice two things: some of the people are not yet committers – we will see how it goes – and that some projects are still waiting for a leader.

Finally, I think this will bring energy and a bright future to the project as a whole. Exciting times!

Categories: Castle | Top Of Page | 7 Comments » |

Framework Design Guidelines video

October 30th, 2008

Awesome to see Kryz showing IoC as a solution for testability. I’d add that this is a side effect, not the fundamental goal. The fundamental goal is loosely coupled design. But even so, when I wrote this article almost 4 years ago I would never expect to see a member of the CLR preaching the same things :-)

See for yourself

One thing I’m particular happy is how he used the IoC term, not DI.

Categories: MS | Top Of Page | 1 Comment » |