So what are the possibilities? What kind of guidance package do we want to develop? What audience will it target? What procedures will it automate? That’s a whole set of questions we have to answer before starting the development phase. But we have to do something else too… Before you can start off experimenting fully with the Guidance Automation Toolkit, there are some basic concepts that one should understand well so we can take full advantage of the capabilities of the toolkit.

One of the first concepts, a true GAPD (Guidance Automation Package Developer) should master, is the diference between bound and unbound recipes. When do we use bound recipes, or when do we choose to implement unbound recipes? …

Some basic things to know…

The goal of a recipe, is automating a serie of actions, that are normally manually performed by a developer in each project. Using a recipe will ensure that these series of actions will be performed correctly and consistently. A recipe, can trigger a number of actions which have to be defined within the recipe. You can use an existing action (meaning one provided by the Recipe Framework) within the XML-file, or you can develop your own custom actions. The only key to defining your own  actions, is making them inherit the Microsoft.Practices.RecipeFramework.Action-class.
More information and an example of developing actions, will follow later…

In most of the cases, a recipe needs a set of arguments to execute its actions. These arguments can be either required or optional. We can gather these arguments in two different ways: we let the user define the argument’s value using a wizard or we can use value providers, which are implementations of interfaces that can be used by the framework to gather arguments. The strength of value providers lies in the ability to intercept changes in other arguments, so you always obtain a value that’s completely up-to-date. Value providers implement the Observer pattern in this way. When an argument which is observed, changes it’s value, it notifies all the arguments that are observing it, so they can update their values.

Getting to the different recipe types

As we all have derived from the title by now, there are two kind of recipes within the Recipe Framework: bound and unbound recipes.

A bound recipe, is a recipe that is associated with a specified Visual Studio solution element. This can be a solution, a project, a class file… The recipe will only appear in the context menu on the item you have specified to bound it to (only on solution level for example).

A bound recipe can again be recurring or non-recurring.

Easily said: a recurring recipe is like a recipe to add a test class, it wil contain a basic test method from which to start, it wil contain the correct namespace references to get you started, and so on… You can add as many test classes as you want, meaning that that specific recipe, is recurring.

When using a non-recurring recipe, once the recipe is executed, you can’t choose to execute it again. A case scenario in which you would want to create a non-recurring recipe is when you want to create a static gateway. Imagine this static singleton class only serves to hold single instances of objects and provide it for usage in other classes using properties. We could develop a recipe that would create this class, for all objects you want to instantiate just once (you could let the user choose these classes in a wizard for example). You only want to create this static gateway once, so once the recipe is executed, it is never again available. It’s possible you would want to regenerate this static singleton class, adding more or less objects in the wizard, but let’s assume in this case, you would do this in a phase of your project where this decision can’t vary.

Bound recipes are bound to a bound recipe reference. A bound recipe reference is an object used by the Recipe Framework to associate a particular recipe with a particular launch point – or speaking in Visual Studio terms, a command. The reference enables the recipe to be executed, and stores it’s state (for example, has it been executed already?).

On the other hand, we have unbound recipes. Unbound recipes aren’t asociated with any item within Visual Studio. The recipe is not “placed” on solution-, project-, nor item-level. These kind of recipes work in a whole other way. Unbound recipes are associated with unbound recipe references, and these references, selects the solution items it’s associated with or used in.

As I just said, the unbound recipe reference chooses the solution items to appear on, but it does this according to a selection condition, a so called Target Condition. This condition is written in code, thus it is defined by us, the GAPD’s. It can be a simple condition and be satisfied by a very broad number of scenarios, or quite complex thus only satisfied in very specific cases. A TargetCondition is a piece of code returning a boolean value which specifies whether the condition was met or not.

Let’s discuss a concrete example. You’re developing a guidance package, which contains a number of folders inside the Domain-project that you have predefined for usage. Since you specify an “Exceptions” folder, you want all the custom Exceptions placed inside this folder, that’s obvious. You also developed a start for custom Exception classes, which you defined as “Exception class” (which is the same as a normal class, but already inherits the ApplicationException class and contains the correct namespace instead). You only want Exception classes within the specific Exceptions-folder, but how do we enforce it???
Well, this is where the unbound recipes come to the rescue. You write a simple condition in code, which checks if the item on which the user clicked is a folder, and also checks it name…. If the recipe is satisfied, an extra command appears in the context menu of that folder: “Add new Custom Exception class”.

How does VS deal with this?

Actually I really wondered how this worked when I started with GAT. When we register a guidance package, one of the main things that happen, is that Visual Studio is told what commands we want to specify on each item in Visual Studio. In the Visual Studio world, this is not dynamic. The commands are loaded before the package, thus Visual Studio needs to know what “icons” it has to display on context-menu’s before anything. That’s why the registering process is so important (of course, this is not the only reason). The action behind the command, that’s where the guidance package comes to the scene. Olaf Conijn explained this to us on the VISUG-event about Software Factories we had a while ago.

So, what about the unbound recipes? How could this be predefined? They actually seem quite dynamic since the commands to unbound recipes are only shown if the condition was satisfied… Well, every time a solution element is selected, Visual Studio queries the Recipe Framework and calls the TargetCondition of each unbound recipe in the package. If the condition returns true, the corresponding command is displayed in the context menu. In the last sentence, I want to emphasise “displayed in the context menu”. VS uses dynamic visibility for unbound recipes. When registering a package, the items on which the unbound recipes can be available, are in deed registered. But it’s when such an item in VS is clicked, that VS adjusts the visibility of commands according to the TargetCondition of the unbound recipes.

Summary

So, I think -and hope- you now understand the difference between bound and unbound recipes.

To summarize it in a sentence, a bound recipe is a recipe attached to a particular item in your project while unbound recipes aren’t attached to any item, but contain a serie of conditions which in combination decide whether you can or not execute the recipe in a certain scenario.

Stay tuned for more GAT-talks!
Laila Bougria

To start of creating your own package, you can make use of a guidance package specifically designed for creating other guidance packages. That’s what I call eating your own dog food. So let’s generate the source for our package in a solution called Factory, which can be obtained in its current form from our codeplex team project.

The second part of this wizard allows you to set some package options like the package name, the namespace and some other information. Make sure not to include spaces in the package name as that will give issues later on.

The wizard will create us a solution with sample code for most of the elements that you can find in a guidance package, like bound and unbound recipes, templates, snippets, wizard pages and more… Besides all the sample code, there is also an installer and a setup package generated so that you can immediatly start of testing the package.  But before we can do this we need to register the guidance package. This can be done by right clicking the guidance package project and selecting “Register Guidance Package”.

In order to test your guidance package, you need to open a new instance of visual studio and navigate to the Guidance Packages section of the New Project window. As you will notice, the Domain Driven Design Software Factory has been added as a guidance package.

Note that registering the guidance package does take some time as all elements need to be reconfigured inside the visual studio environment. If you don’t have any new recipes or templates that need to be registered or if you didn’t change any HostData sections that define the integration with Visual Studio, you can get away with the “Quick Register” option which is remarkably faster.

Now let’s open a new instance of Visual Studio and lets create a sample solution and fill out the wizard.

And as a result of our guidance packages code generation, we end up with a solution that we can use to test the sample structure, templates, bound and unbound recipes.

I suggest you take a look around the generated solution if you’re not acquainted with the guidance automation packages, otherwise you can delete it again as it has obviously nothing to do with Domain Driven Design.

Next time we will start shaping our factory so that it will enforce the default Domain Driven Design layering, which has already been discussed in the Setting the scene column.

See you next time,
Yves Goeleven

Remember that objects, when they are in memory, are identified by their memory address and not some property that acts as an identifier like this is the case in a relational database. The underlying infrastructure must ensure that the two are mapped to one another, which is often done using the identity map design pattern. Implementing such an infrastructure can be a pretty daunting task, but if you are interested, I have created an entire series of blog posts last year which covers most of the difficulties that you will encounter. Or, you could use an Object Relational Mapper instead.

On the other hand, a domain model contains a lot of Value Objects as well, which will be covered in the next post.

Stay tuned,
Yves

I like to represent modules with folders containing classes in the domain. In the future though I hope we can have a nice DSL that displays the domain layer with all modules as simple shapes in a domain diagram, implemented behind the scenes as folders, and that allows to drill down to the components that are contained in the module. The different types of components that can exist in a module will be discussed in upcoming articles, for now we will continue with a real life example of how to determine modules.

To determine modules one should simply look at the business domain. Currently I’m working on a contracting application for the belgian gas flow manager, so the domain is definitly contracting. Now if you think about contracts, you probably think about different Business Partners signing Agreements right? Business partners can take up different roles depending on the agreement that is signed, they could be shippers, traders, gas flow managers etc. Furthermore agreements can come in many forms: first of all there is the master agreement that says that we’re going to do business together, next we have technical agreements that limit for example the pressure of gas that is exchanged or the rules that apply for allocation of capacity to the buyer and there are many more of these kinds of agreements. But just signing a paper isn’t going to cut it! If you want to, for example, store gas, you have to make sure whether it is possible or we may blow up that nice little storage tank. So you have to ask whether you can get a certain Service at a given point or period in time, services could for example consist of rights to store gas, or to inject it, to trade it, etc…

Now if you look at the description above of a typical contracting domain for the gas flow market, one can identify a few big groups of business logic in there. These big groups, like in this example Business Partners, Agreements and Services, are what modules are all about. Note that there is a direct dependency from Services to Agreements to Business Partners, but not the other way around.

To wrap up, if your domain is rather complex ( and which one isn’t? ), split it up in different parts based on the knowledge that you have of the particular domain, but be sure to let the domain be your guide.

Next time we will start to go through the different components that can be found inside a module.

Stay tuned,
Yves Goeleven

In this post I’ll simply line out the way to create them, and how you can use them. You’ll be using this approach many times once you get going with Guidance Automation, since they are one of the key parts to defining the solutions and projects you want your package to unfold. This talk was inspired by GAT, but of course, you can use this knowledge for a lot of other scenario’s…

Why use Visual Studio templates?

Why would you use Visual Studio templates? Well, as I said, they are a key part to using Guidance Automation, but then again, what is Guidance Automation about? It’s about automating everyday tasks, it’s about reusability. Well, with templates, you can reuse structures, classes, and some concepts you already applied in previous projects. A template contains a lot of information and can create basic projects (such as a C# library containing some default folders you use) or more specialized projects (such as a C# domain layer that already implements some basics to using Domain-Driven-Design in your project)…

Let’s take off

Just imagine you have this great project, and you would like to get a template that contains all the stuff you have in this project… How do you get started? Well, it’s pretty simple, with some clicks Visual Studio does the job for you… Just open your project, click the menu “File”, “Export Template” and a new wizard appears.

You can then choose to create a project template or an item template. What’s the difference? Usage is…

When you create a project template, you will be able to use it from the “New Project” dialog once it is installed and all new projects based on this template will contain the features of your base-project. When you’re creating an item template, it will be available in the “Add new item” dialog, which appears when – for example – you right-click on a solution item.

You can give project templates a rightfully chosen name (remember that this name will be used in the “New project” dialog, so I suggest you make it meaningful yet simple), a custom icon and even a description that contains more information for the users. The same story for item templates: give them a sensible name, and if you want to, choose a custom icon to differentiate them rapidly.

For item templates, there’s more to choose. Once you have chosen the class you want to create a template of, VS will list all the namespace references this class has and ask you the ones you want to include in the template.

If the item template already contains some code, this is very necessary to have a buildable item in the first place.You’ll be thinking, this is easy, I could have figured that out myself… Well, it is! You just have to know it exists…

But now, let’s take it all a step further, let’s see what Visual Studio has generated for us…

The template file

Open a windows explorer and navigate to the path you save the template in. You’ll see that VS created a zip-file with the name you provided as template-name. When extracted, you’ll notice there’s a bunch of files in there… Let’s have a look.

The most important file you want to have a look at, is “MyTemplate.vstemplate”. This is the actual template and contains the structure of the project. When you open it, you’ll see this is nothing but an XML-file, which can be divided in two major parts, the TemplateData and the TemplateContent.

The TemplateData-node contains a number of general properties for the template, such as it’s name, whether the template should create a new folder for the project, a default name, and so on… You can adjust every single one of these properties to your own preference.

<TemplateData>
 <Name>Domain</Name>
 <Description>Project for the Domain-layer of an application (DDD)</Description>
 <ProjectType>CSharp</ProjectType>
 ...
</TemplateData>

<TemplateContent>
 <Project TargetFileName="Goeleven.Web.RssAggregation.Domain.csproj" File="Goeleven.Web.RssAggregation.Domain.csproj" ReplaceParameters="true">
  <ProjectItem ReplaceParameters="true" TargetFileName="Model.cd">Model.cd</ProjectItem>
  <Folder Name="RssAggregate" TargetFolderName="RssAggregate">
   <Folder Name="Exceptions" TargetFolderName="Exceptions">
    <ProjectItem ReplaceParameters="true" TargetFileName="InvalidAggregateException.cs">InvalidAggregateException.cs</ProjectItem>
    <ProjectItem ReplaceParameters="true" TargetFileName="InvalidFeedException.cs">InvalidFeedException.cs</ProjectItem>
   </Folder>
  <ProjectItem ReplaceParameters="true" TargetFileName="RssFeedRepository.cs">RssFeedRepository.cs</ProjectItem>
  ...
  </Folder>
 </Project>
</TemplateContent>

The project file

A csproj-file also contains of two key-nodes: PropertyGroup-nodes and ItemGroup-nodes.

PropertyGroup-nodes will typically contain general information such as the output type, default namespace, the target framework, whether to treat warnings as errors (which I suggest to always set to true!), … You’ll recognize all this information when you look at the project properties of some existing projects you have.

The ItemGroup-nodes, can contain another group of nodes. In here, you want to define the references the project must have by default, and the files you want to include in it. For each file, you can again specify it’s properties (compile, content, … ?).

<ItemGroup>
<Reference Include="Goeleven.Framework, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a1fc815d91c11418, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\..\Dependencies\Goeleven.Framework.dll</HintPath>
</Reference>
...
<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
...
</ItemGroup>

<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
<ProjectGuid>$guid1$</ProjectGuid>
<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
<OutputType>Library</OutputType>
...
</PropertyGroup>

A feature that I also find very nice, is that you can define a PropertyGroup-node for each configuration you use in your project and thus adjust some properties according to the scenario. If you think it’s extreme to set the “TreatWarningsAsErrors” to true in a Debug-environment (which I don’t, but opinions differ ), well, then you can activate it for Release-environments only.

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<TreatWarningsAsErrors>True</TreatWarningsAsErrors>
</PropertyGroup>

Regards,
Laila Bougria

HEROES happen {here}

2 days packed with technical content, that’s what TechDays is for you. A full house of developers will have the opportunity to choose between 3 developer-oriented tracks and the architecture track. The agenda even provides some Software Factory related sessions! Some sessions that might interest you as a reader of this blog:

Community

As always, TechDays also provides a good medium to connect with your peers. Most Belgian user groups are present, as will quite some members of IntoFactories.NET! Be sure to meet us at the Compuware booth!

Just like last year, Visug is organizing its Visug Geek Bowling as an evening activity.
On the evening of March 12th, they’ll gather at the Bowling Palace in Lochristi around 20h!

Be there!
Stijn.

The goal of the domain layer is to capture all the business logic that applies to the domain that we are writing software for, hence its important that the source code for the domain layer reflects the true domain as much as possible.  Why? Well, this way you can use the source code as a means of communication with all members of the team and with the eventual consumers of the application, in fact all concepts that will be discussed in the upcoming chapters should be part of this common language, called the ‘Ubiquitous Language’.

Code an sich does not lend itself very well for communication does it? It contains a lot of chatter, like point comma’s, curly braces etc… just for the sake of getting it compiled. A better way to communicate the code is using a model, a graphical domain specific representation of the code. This is where DSL’s or Domain Specific Languages come in, they can provide a graphical representation of code which is specifically tailored for the problem domain and as such DSL’s can bridge the gap between the code and the Ubiquitous Language. An excellent example of a DSL can be found in the Visual Studio Class designer, which is nothing more than a nice DSL on top of code that represents classes.

A DSL is a great way to present the concepts in a given problem domain, like the concept of a class or a workflow, as long as the concept you want to show is expressable as a graphic. But many enterprise models are just to difficult or to wieldy to capture at one glance, which is one of the biggest problems for a graphical DSL.

Next time we will look into the options we have to separate the different parts of a large model into distinct parts.

I’m no thought leader on the future of IT, but I do have a vision of how software development will evolve in the next couple (or hundreds) of years and Team system plays a big part in it. But before we dive into this vision, let’s have a look at what the development world looks like today.

What does software development look like today?

Today, software development is a craftsmanship, a lot like conventional industry was 400 years ago. Most software development teams are made up of a small amount of specialist developers, of which only a few actually master most of the available technologies or as Bart calls them in his article ‘The developer gap’, expert and regular developers.

In some cases these teams are self organizing, which means that they have managed to gather the right mix of developers, each talented in their own way, so that they can make all the necessary decisions for themselves. If you are in such a team, great, but reality tells me…

That there are just not enough good developers on the market to be sure that you can compose a self organizing team in the limited time you have to set up the project. Often you just have to work with less talented people, or people whose talents don’t match with the needs of the project.

And if you do manage to find the expert developers, you will only find a few and they will be pretty expensive. Both of these factors make that the software, which is supposed to add value to the business, will take several months to develop and will cost a lot of money. By the time the software is released, the market will already look differently and a lot of the effort goes to waste.

Don’t get me wrong, I like the idea of the self organizing team, and I would love to have a few thousands of colleagues that have as much expertise as the few dozen I currently have, but that’s just not how our market works. And trust me, after being in the Compuware recruiting team for a few years now, there are not many good developers available on the market.

Where should the industry go to?

In my opinion, the total cost of software development and the lack of talent on the market will force us to hire low cost, less skilled workers to complete our projects. We still have to go through the same revolution as happened with conventional industry in the 1800’s, we need to improve the current processes of software development and automate them into factories.

The biggest difference between IT and conventional industry, however, is that we are not developing the same parts all over again, which makes standardization a lot harder. Each project has different business needs and is started to solve a different problem, it will be very difficult to design a ‘Customer’ class that will fulfill the needs of a local grocery shop or that of your countries biggest transport company.

I don’t believe we can make some ‘Robot’ that will generate all the code of an application for us; instead I believe we should organize our software factory around a development process for which some tasks are fully automated, a few are done by expert developers and most of the labor is done by less skilled people, who don’t necessarily have to have skills in software development.

What needs to happen before we can achieve this?

As the state of software development is today, I don’t believe this revolution is at hand in a very short time. A lot needs to be changed before we can even think about large scale automation:

First of all, we need to find the default software architecture. If we want to automate the development of most types of software, we need to figure out what the default architecture is for each kind of application and define the common denominator. Today most teams start all over again for each software project they attempt, but to be productive they should start off with the default architecture and only make minor changes to it if a special feature is required. I believe this is probably the hardest task we are facing; I do have a default architecture for services, one for smart clients and one for web applications, but to achieve this goal all kinds of applications should be architected the same way preferably. Multiple defaults are possible as well, but that would make reuse of the assets much harder.

Secondly, all software components should be standardized. This means they all should conform to a certain design, a fixed interface. In transport, all containers fulfill to a number of standard sizes, no matter what can be transported with the container, no matter how it’s going to be transported. This way the containers are interchangeable allowing trucks, trains and boats to be designed without knowing what they are going to be used for. Once the interfaces of all software components are stabilized, general infrastructure code can be provided to allow faster and easier development.

Finally, each detail of the software development process, or better, the entire application lifecycle, should be studied and documented in detail. When a car manufacturer starts his assembly line, he will know exactly what parts are used at which points of the line, he knows how many milliseconds it will take to put a screw into the chassis, each part of the assembly line is controlled and monitored with great detail. When all details are documented, they can be assigned on an individual basis to non developers as well, in my opinion. With the correct documentation I do believe that a non developer can perform a code review targeting coding guidelines for example.

What technologies are required?

In order to automate some of the tasks, we can resort to code generation. However I’m not a big believer of code generation as each piece of code to be generated has its own specific needs. What I do believe in though is discrete code generation in the form of snippets and GAT recipes that can be used by less skilled developers to perform a specific task like creating a data access component for example.

If we would like to use non developers to actually create parts of the application, we need to provide them with a DSL so that they can configure the component with terms they know and have the code generated when they are finished.

But a software factory is more than just snippets, recipes and DSL’s. Each of these technologies is like a robot in a factory that can perform a small specific task. All of these robots should be combined with people (both expert developers as unskilled ones), to form an assembly line. The role of the assembly line can in my opinion be played by Team Foundation Server, and more specifically the process template and continuous integration features.

Team Foundation Server

Besides all the necessary tools that TFS provides us, like work item tracking, version control and a build server, it has one big advantage over different products: The process template. The process template gives us the means to set up the configuration of an assembly line.

We can create custom work items that can be interpreted by humans to perform a task, but using the work item object model, software components can interpret them as well and could automate some of the jobs. Obviously a standardized and well controlled process is crucial to achieve this.

Work items can be linked to code, in order to keep track of the time it took to complete the work, so that we can monitor how the assembly line is doing. Check-in policies allow us to enforce the linkage so that human interactions can be tracked as well.

Team build and more specifically MS Build allows us to perform automated compilation, testing, code metrics collection and automated deployment without knowledge of the developer checking in his code. With the TFS 2008 features and the SDC library, this task becomes even trivial.

All collected information is gathered in a data ware house so that the management team has a clear view of performance and quality at any moment through advanced reports.

My plans in the near future

I hope I have convinced you that TFS, or one of its successors, will be the key to the future software factory that I have in mind. In the near future I hope to write a series of articles on several parts of TFS and how you can use it to automate some of the tasks that need to be performed during the development of an application.

I will double post the articles that are directly related to software factories on both my own blog and the intofactories blog. Articles that cover only technical details of TFS like the build API or process customization will only be posted on my own blog so that IntoFactories stays focused on software factories only.

Stay tuned,
Yves Goeleven

The building block where Unity is built on, exists since the first version of Enterprise Library and is called ObjectBuilder. ObjectBuilder was one of the first Dependency Injection frameworks available for .Net, but it has lived a silent life since then. I think this was caused by the complex interface of the API and the lack of documentation.

Ok, enough bla bla! Let’s take a look at the Unity framework:

I made a small class that will do a HelloWorld, the HelloWorldService. Like every Ioc container, the container needs to be configured. Unity framework allows configuration from code or an xml configuration file. From code it looks like this:

IUnityContainer container = new UnityContainer();
container.Register();

IUnityContainer container = new UnityContainer();
UnityConfigurationSection section =
   (UnityConfigurationSection)ConfigurationManager.GetSection(“unity“);
section.Containers.Default.GetConfigCommand().Configure(container);
IHelloWorldService service =
  container.Get();

In code:

Console.WriteLine(container.Get(“transientHelloWorld“).HelloWorld(“Thomas Annerel“));
Console.WriteLine(container.Get(“transientHelloWorld“).HelloWorld(“Thomas Annerel“));
Console.WriteLine(“Singleton“);
Console.WriteLine(container.Get(“singletonHelloWorld“).HelloWorld(“Thomas Annerel“));
Console.WriteLine(container.Get(“singletonHelloWorld“).HelloWorld(“Thomas Annerel“));

The result:

In this example I’ve shown you how you can manage the lifestyle of an Object. Another small feature is that you can give a type a name and use that name to get an instance. Next feature is dependency injection. Unity supports all types of Dependency Injection, Constructor, Property and Interface injection, it even supports injection of strings. So let’s give it a try. I created an improved version of the HelloWorldService. In this version the message (a string) is injected and the second object hosted by unity is injected to do the formatting (just a simple string.ToUpper(), nothing fancy). So here is the config:

The code behind MessageInjectionHelloWorldService:

#region Properties

/// 
/// The injected formatter
/// 
[Dependency]
public IMessageFormatter Formatter
{
  get
    {
      return formatter;
    }
  set
    {
      formatter = value;
    }
}       

#endregion        

#region Override Properties       

/// 
/// The message of HelloWorld
/// 
[Dependency(“HelloWorldMessageString“)]
public string MessageFormat
{
  get
    {
      return helloWorldMessageFormat;
    }
  set
    {
      helloWorldMessageFormat = value;
    }
}       

#endregion

The attribute on the properties tells the ObjectBuilder behind Unity to inject an instance into this class. The attribute describes who to inject. The cool thing is that you can inject value types into an instance. The discussion about what to inject and what not is going to rise since the configuration of Unity can’t replace the need for custom configuration sections.

And now the result:

A pity is that there is no way to configure the dependencies in the configuration file. Maybe this is a feature that’s not implemented (yet).

So, I think I covered the most important stuff of an IoC container, except some features that are totally new in IoC land.

The first one is hierarchical containers. You can’t configure it using the configuration file, but it can be easily done in code. You can actually add a child container to every Unity container. In this child container you can overrule mappings of the parent container. It’s like object inheritance. This is a unique feature and I love it. This will make overriding the container in some circumstances (like UnitTesting) a lot easier.

Another great feature is that ObjectBuilder isn’t hidden away, this means that you can inject in classes that are not hosted in the container, you only need to create them using the ObjectBuilder. In the following example we ask the container to create a Form. If the form has any dependencies these will be automatically injected.

container.Get());

Summary

Lets put all the pros and cons together:

Pros:

• Can contain multiple containers.
• Container can be configured using code or a config file, letting the door open for other configuration options.
• API Interface supports generics, so no unnecessary casts.
• Container Hierachy.
• Can inject in objects that are not in the container, using the Object Builder functionality.
• Supports 3 sorts of Dependency Injection, namely constructor, property and method injection.
• Can inject instances and value types.

Cons:

• Not everything is configurable yet using the app.config.
• Missing some options in creating custom lifestyles (for singleton per HttpRequest in web applications).

Conclusion: this is the first CTP of Unity framework. I think this is a great start but still needs some work. I think it’s a great first candidate for our IoC DSL.

Why build an IoC Dsl?

Before I go into detail on IoC, I’ll give you a little explanation why IoC is important for us, IntoFactories laborers. Our main goal is getting into all cool things like DSL, Guidance Automation Toolkit and any other Software Factory technologies. Because we want to build a Factory that builds something, we chose to create a DDD Software factory. Now any DDD implementation needs an IoC container. Why? Simple. One of the rules of DDD is that the Infrastructure Layer (ex an ORM) knows the Domain Layer and the Domain Layer doesn’t know the infrastructure Layer. Solution: IoC to the rescue!

Inversion of Control

Inversion of Control is all about loading the right plugin implementation and injecting it in your running code. IoC is a too generic term, from a simple logging provider that is loaded (ex the Entlib logging) to advanced IoC containers as Spring.Net or Castle. The term dependency injection is therefore closely coupled to IoC.

There are 3 forms of dependency injection:

• Constructor Injection: Injects an instance of class A into class B using the constructor of B
• Property Injection: Injects an instance of class A into class B by setting a Property of B
• Interface Injection: An interface that describes how an instance needs to be injected

Every IoC container is built on the same 3 pillars:

• Configuration file: A file that describes which components are hosted by the IoC container.
• Assembler: Component responsible in loading the right implementation and injecting the necessary dependencies.
• Object lifestyle manager: Every IoC container has the possibility to manage the lifestyle of an object. Commonly supported lifestyles are singleton and single call.

Most of the IoC containers also support aspect oriented programming (also called policy injection after the Policy Injection Block in EntlLib 3.1). This allows you to handle cross cutting concerns like logging, security and transactions of the in the IoC Container hosted objects.

The frameworks

There are a lot of available frameworks in the open that support dependency injection:

• Castle MicroKernel and Windsor
• Spring.Net
• ObjectBuilder & Unity (New framework of the P&P group)

The following posts will handle these frameworks.

Back to the main topic!

What part of IoC and dependency injection can we automate in our Software Factory and technical framework? First off all, abstraction of external components is always a best practice. This will prevent assembly references to 3rd party frameworks in your projects and will ease the integration of a newer version. That’s typically a job for a technical framework. We will make the assumption that every AppDomain will contain only one instance of an IocContainer. By creating a static gateway to the IoC container we can hide its implementation. Because every architecture is different, we have to allow the user to choose which implementation of the IoC container he wants to use. This can be easily done by a provider mechanism.

Now let’s go to the cool stuff! The generation of the config file can be done with a Dsl. This Dsl needs to be able to generate the possible humongous config files for the different IoC Container implementations. Next thing that would be cool is single-click “Host in IoC” option provided by GAT… Ok, the requirements are almost set, so let’s start building the IoC Dsl/GAT package.

The following days/weeks I will write some posts about the different IoC implementations on the market, starting with Unity. See you next time!

Greetz,
Thomas