In the previous post we saw how to provide Inversion of Control capabilities to a WCF service. That’s pretty cool but unfortunately it requires a big refactoring if you plan to apply the Dependency Inversion pattern on an existing WCF project.

Today we will see an interesting alternative provided by Castle project. If you are not aware of Castle, you can have a look at the community web site here. Castle provides a set of tools for NET, Active Record, Dynamic Proxy, Windsor and a set of facilities that you can easily plug into your code.

The demo project

Before starting to have  a look at Castle Wcf Facility we need a new WCF project and a WCF web site to host our service. The idea is to create an empty service and host it, then we will refactor the project to include Castle Windsor and WCF facility.

Let’s start by creating an IIS web site, a DNS redirect and a folder for our IIS web site. The final result will be like the following one:

Now we need to create the new project in Visual Studio. I have created a solution that contains 2 projects:

• Empty WCF Service Library named “Service.Contracts”
• Empty WCF Service Library named “Service.Implementations”
  • reference the project “Service.Contracts”

And this would be the final result of this step:

We have just implemented the correct way of creating a WCF service implementation and a WCF service contract. The Client will have a reference to the contract assembly in order to be able to work with the service implementation, without the need of using a Proxy. This concept is outside the fact that I will use an ioc container, it’s just a lot easier than adding a “web service reference” in visual studio and carry tons of useless proxy classes in your project.

Hosting WCF service

The final step is to host this WCF Service inside an IIS ASP.NET or ASP.NET MVC website. I have create a new “web site application” and from the options I choose “WCF service application”. Then I select my local IIS for the development path, but this is up to you.

Now Visual Studio will ask you if you want to override the current web site or use the existing content. If you choose the second option you will have to provide also web.config configuration and initial setup, so I kindly suggest the first option.

If everything went ok you should be able to visit the default service created by Visual Studio at this url: http://staging.service.local/Service.svc.

Now we need to change the content and the name of the .svc file, but before we need to add a reference for Contracts and Implementations from the solution explorer!

[sourcecode language='php' ]
<%@ ServiceHost 
    Language="C#" Debug="true" 
    Service="Service.Implementations.ServiceImplementation" %>
[/sourcecode]

We need to reference the Implementation because we don’t have a factory yet able to translate the IServiceContract into a ServiceImplementation class. So the next step is to install in our solution the WCF castle facility nuget package.

Add WCF facility

So far we didn’t need any external tool because we have an empty service created by default by Visual Studio with a dummy code, or probably during the tutorial you have already changed your service to so something more interesting. The next step is to add a facility in order to be able to change the default factory used by IIS to create an instance of our service.

The first step is to add a new global.asax file if you don’t have one already and plug the Windsor container inside the Application_Start event.
This is my global.asax file:

[sourcecode language='php' ]
<%@ Application Language="C#" Inherits="ServiceApplication" %>
[/sourcecode]

Now, in the code behind file we want to create an instance of a new Windsor Container during the Application_Start event:

[sourcecode language='csharp' ]
public class ServiceApplication : HttpApplication
{
    public static WindsorContainer Container { get; set; }

    protected void Application_Start()
    {
        BuildContainer();
    }
}
[/sourcecode]

And this is the code to initialize a new container. In this code we need to pay attention in the way we specify the server name, because WCF facility uses the service attribute value to search inside the Windsor container. So, this is the code to register the service:

[sourcecode language='csharp' ]
private void BuildContainer()
{
    Container = new WindsorContainer();
    Container.Kernel.AddFacility<WcfFacility>();
    Container.Kernel.Register(Component.For<IServiceContract>()
                                        .ImplementedBy<ServiceImplementation>()
                                        .Named("ServiceContract"));
}
[/sourcecode]

And this is the change we need to apply to the Service.svc file:

[sourcecode language='php' ]
<%@ ServiceHost 
    Language="C#" Debug="true" 
    Service="ServiceContract"
    Factory="Castle.Facilities.WcfIntegration.DefaultServiceHostFactory, Castle.Facilities.WcfIntegration" %>
[/sourcecode]

Now your service is ready to use dependency injection under the power of Castle Windsor.

Add a dependency to a WCF service using Windsor

Simple example, I have a service that requires an ILogger injected in it. I need to change the code for my service to allow injection and then I need to register the logger in the global.asax file during the Windsor container activation process.

[sourcecode language='csharp' ]
public class ServiceImplementation : IServiceContract
{
    private readonly ILogger logger;

    public ServiceImplementation(ILogger logger)
    {
        this.logger = logger;
    }

    public string GetData(int value)
    {
        this.logger.Trace("Method started!");
        return string.Format("You entered: {0}", value);
    }
}
[/sourcecode]

And this how we change the registration in the container:

[sourcecode language='csharp' ]
Container.Kernel.Register(
    // register the logger
    Component.For<ILogger>()
        .ImplementedBy<TraceLogger>(),
    // register the service
    Component.For<IServiceContract>()
        .ImplementedBy<ServiceImplementation>()
        .Named("ServiceContract"));
[/sourcecode]

The source code is available here:

http://sdrv.ms/16BLYoI

When you start to work with TDD and other Agile practices the first thing you try to apply almost everywhere in your code is the Dependency Inversion pattern because you want to invert the logic of your dependencies to make your code more testable and maintainable.

In order to accomplish this result I am using Castle Windsor, while before 2013 I was working with Microsoft Unity. I am not going to jump into the conversation “Which Inversion of Control container is better?” because it really depends on what you need to do. For years I was more than satisfied with Unity but recently I started to create complex bootstrappers for my applications and I found Windsor more flexible, that’s it!

How does WCF create a service instance?

First of all, in order to apply dependency inversion inside WCF we need to understand how WCF works and how it creates new service instance. I found this article on MSDN very helpful during my researches: Extending WCF.

So, this is the final result I want to obtain:

When you create a new service in WCF, you can specify the factory that will be in charge of creating the service instance.

This is the code you should use to specify the factory:

   1: <%@ ServiceHost Language="C#"

   2:     Factory="Raf.DependencyInjectionHostFactory"

   3:     Service="Raf.MyService" %>

Now, the factory should start a new instance of our service, or better, should use the ioc container to resolve an instance of that service.

Second step is to create a custom host that will add a new behaviour to our service, the behaviour will call the service locator (I know it’s an anti-pattern …) to inject the dependencies. In my case, Castle Windsor.

Factory

   1: public class DependencyInjectionHostFactory : ServiceHostFactory

   2: {

   3:     protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)

   4:     {

   5:         // method called when we hit a request to http:// ... youservice.svc

   6:         return new DependencyInjectionHost(serviceType, baseAddresses);

   7:     }

   8: }

Host

   1: public class DependencyInjectionHost : ServiceHost

   2: {

   3:     // omit

   4:     // ...

   5:     protected override void OnOpening()

   6:     {

   7:         // attach the behavior

   8:         Description.Behaviors.Add(new DependencyInjectionServiceBehavior());

   9:         base.OnOpening();

  10:     }

  11: }

Service behavior

   1: public class DependencyInjectionServiceBehavior : IServiceBehavior

   2: {

   3:     #region IServiceBehavior Members

   4:

   5:     public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)

   6:     {

   7:     }

   8:

   9:     public void AddBindingParameters(

  10:         ServiceDescription serviceDescription,

  11:         ServiceHostBase serviceHostBase,

  12:         Collection<ServiceEndpoint> endpoints,

  13:         BindingParameterCollection bindingParameters)

  14:     {

  15:     }

  16:

  17:

  18:     public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)

  19:     {

  20:         foreach (ChannelDispatcherBase cdb in serviceHostBase.ChannelDispatchers)

  21:         {

  22:             var cd = cdb as ChannelDispatcher;

  23:             if (cd != null)

  24:             {

  25:                 foreach (EndpointDispatcher ed in cd.Endpoints)

  26:                 {

  27:                     ed.DispatchRuntime.InstanceProvider =

  28:                         new DependencyInjectionInstanceProvider(serviceDescription.ServiceType);

  29:                 }

  30:             }

  31:         }

  32:     }

  33:

  34:     #endregion

  35: }

So, the instance provider is able to retrieve a registration for our service using the service locator:

   1: public class DependencyInjectionInstanceProvider : IInstanceProvider

   2: {

   3:     private readonly Type serviceType;

   4:

   5:     public DependencyInjectionInstanceProvider(Type serviceType)

   6:     {

   7:         this.serviceType = serviceType;

   8:     }

   9:

  10:     public object GetInstance(InstanceContext instanceContext, Message message)

  11:     {

  12:         IServiceLocator serviceLocator = ServiceLocator.Current;

  13:

  14:         return serviceLocator.GetInstance(serviceType);

  15:     }

  16:

  17:     public void ReleaseInstance(InstanceContext instanceContext, object instance)

  18:     {

  19:         // if you container allows you to destroy instance

  20:         // you can destroy your service instance here

  21:     }

  22:

  23:     #endregion

  24: }

That’s it. Of course my container needs to know what is my service registration, and with Windsor I have two options:

   1: // option one, register the interface

   2: Component

   3:     .For<IWriteService>()

   4:     .ImplementedBy<WriteService>()

   5:

   6: // option two register the class

   7: Component

   8:     .For<WriteService>()

   9:     .ImplementedBy<WriteService>()

And of course you need to change the markup of your .svc file depending on how you want to resolve the service, with the interface or with the  class type.

Dependency Injection

Now, let’s assume that my service needs an IUnitOfWork contract, how should we do that?

First of all we need to register both types in our container, and with Windsor one of the possible options is this one:

   1: Component.For<IUnitOfWork>()

   2:             .ImplementedBy<UnitOfWork>(),

   3: Component

   4:     .For<ICommandService>()

   5:     .ImplementedBy<CommandService>(),

And my command service is constructed in this way:

   1: public class CommandService : ICommandService

   2: {

   3:     private readonly IUnitOfWork unitOfWork;

   4:

   5:     public CommandService(IUnitOfWork unitOfWork)

   6:     {

   7:         this.unitOfWork = unitOfWork;

   8:     }

   9: }

Note for purist of CQRS: I know that a command service should get a command dispatcher injected but for this blog post I guess it would not make things clear enough, so a unit of work or an IRepository would make more sense.

This year has been seriously tough for me and my family, but finally we went beyond it successfully. So I guess it’s time for my first year review and new year proposals.

2012, relocation(s)

In Spring 2012 we moved away from Bermuda after almost 5 years. The relocation has not been easy, after few months in Netherlands I got sick and I had to quit my job and take a long break. Unfortunately I didn’t take a serious break between Bermuda and Netherlands and my body couldn’t afford it. So, we decided to move to Italy and kite surf for a couple of months (which was quite successful and pleasant …) and take a break from any type of technology (phone, mail, web …).

It was a good break and overall I am quite happy I took it, even if it cost us a lot of money, being on vacation and not getting a revenue. But I personally believe that life is one and health and family come before everything else. That’s it.
Btw I also cured my problem and now I am back in shape and ready for my daily activities, which include this blog.

In November we decided to move back to Netherlands and I successfully signed a new contract for a position of Software Architect for Mproof, a Dutch Software House. The environment is really Agile and friendly and this is making me an “happy coder”. Plus I am working remotely with a team in Ukraine, which I recently visited. It was a nice trip and I was able to share some Agile workshops about SOLID and TDD. I am also quite happy seeing new coders embracing Agile without prejudices.

Recently I also attended the XP days (Agile conference) in Netherlands and I had the pleasure to interact with some Europeans coders and architects. I guess I would speak about Agile and NET, next year and the next XP days, not sure about what yet.

Unfortunately I had to quit a lot of extra activities for a while, such as “blog”, “open source”, “studying”, “certifications” and so on … I had some health problems and the laptop was one of my first enemies during these months so I couldn’t interact with technologies for a while until I was fine. My wife was very helpful during this time and we found in the kite surf a good cure for stress.

Overall expectations

Well, if you ask me now, I can easily say that at the beginning of 2012 we were not planning to leave Bermuda yet, especially for the economical crisis around the world. The relocation was a shock for the family because we were almost used to Bermuda were everything is “another world”, so you can imagine the shock after few months of city living. After we left Bermuda we had some plans but sometimes reality is much different and you need to “adapt” your plans to reality.

• I completed my IASA certification and in my backlog there is my third book.
• I couldn’t complete the code of my previous books but my readers can now access all my code on TFS 2012.
• I finally complete my learning process on kite surfing, even if I can’t jump yet, and I found it a really nice and cool sport.
• We successfully relocated to Netherlands and this was my dream when I was a kid. I also got a new job which it’s quite challenging right now and of course well paid!

Plans for 2013

I have few plans for 2013 but I will do my best to accomplish them. First of all learn Dutch, you can easily live in Netherlands without speaking Dutch, but you will never be “part of it” if you know what I mean. Because I am good European citizen I don’t regret to learn a new European language, even if I can say already that Dutch is a pretty damn difficult language to learn.  

Move back to my blog and show a lot of Agile samples, complete my blog migration on WordPress because I am quite disappointed about Subtext roadmap at the moment.

Totally embrace Agile at my current employer.

Kite surf and be back to gym. Write my third book. Plus I have some private plans with my family that I can’t share with you…

The plans over my blog will all be related to my new book, so you will be able to “taste” a little bit of it over my next blog’s posts. I got a free account on TFS 2012 and I am publishing all my projects over there so that anyone of you can simply go there and get the latest version of what’s available.

I am not sure yet, but I would like to re-start to speak at public conferences, I think the XP days would be a good re-start.

For now that’s it!

Right now I am working on a CQRS project, and I am using WCF as my web service technology. In this project I decided to challenge myself and make a full TDD project. The first big problem I found was to simulate a real web server, because I didn’t want to hit a production or QA environment to run my tests.
Second I didn’t want to write any integration test at all, so I had to figure out how to create an in-Process test to run my WCF methods.

Why in-process test? When you write a unit test, you should test a single functionality, and in order to make the test atomic, it should run in-process. It should not involve third party tiers like a database or IIS, otherwise the test won’t be in-process anymore, so it will became an Integration test.

The first idea I came out was to fake the behaviour of IIS, and in order to accomplish this I could easily work with a mock framework like Typemock and mock out the entire IIS infrastructure.

Is this what I really want? Not at all. I don’t want and I don’t need to fake the behaviour of IIS, I need an instance of it because my WCF services are using custom factories and custom behaviours and I need to be sure they are acting in the right way.

So I have created two different type of tests. The first one is pure Unit Test, where I verify the command behaviours:

   1: [TestMethod]

   2: public void AddUsersCommandHandler_ValidCommand_WillPersist()

   3: {

   4:     // arrange

   5:     AddUsersCommand expectedCommand = new AddUsersCommand { UsersStream = expectedStream };

   6:     // service with mocked unit of work

   7:     IServiceCommandHandler<AddUsersCommand> handler = new AddUsersCommandHandler(mockUnit.Object);

   8: 

   9:     // act

  10:     handler.Handle(expectedCommand);

  11: 

  12:     // assertions against the command behaviour

  13:     mockUnit

  14:         .Verify(x => x.BeginTransaction(), Times.Once());

  15:     mockUnit

  16:         .Verify(x => x.Save(It.IsAny<User>()));

  17:     mockUnit

  18:         .Verify(x => x.CommitTransaction(), Times.Once());

  19: }

The second one is the (in)famous integration test, where you call the WCF service and test the overall process. Unfortunately for the second step I couldn’t find anything really TDD so I had to figure out by myself a different solution.

IIS Express

Yesterday I spent some time googling around for a solution while I found a nice post from Scott Gu about IIS express. With IIS express we have an in-process IIS server that we can startup or shutdown at any time during the lifecycle of our tests. It provides almost all the functionalities provided by IIS and it also trigger the Application_Start event, something not very well handled by Cassini …

So, first of all I had to figure out how to bootstrap my unit tests to run over a different IIS than the one configured in the web.config.

Piece of cake, first of all I need something that allows me to bootstrap IIS express before my unit test harness starts:

   1: [ClassInitialize]

   2: public static void ClassInitialize(TestContext context)

   3: {

   4:     // create a process for IIS express

   5:     issProcess = new Thread(IssUtility.StartIisExpress)

   6:                  {

   7:                     IsBackground = true

   8:                  };

   9:     // start it

  10:     issProcess.Start();

  11:     // create a new channel factory using the generated URL

  12:     factory = new ChannelFactory<IDomainWriteService>(

  13:        new BasicHttpBinding(),

  14:        new EndpointAddress("http://localhost:5555/services/DomainWriteService.svc"));

  15: }

Then I need another utility to kill everything when my test harness is done:

   1: [ClassCleanup]

   2: public static void ClassCleanup()

   3: {

   4:     // close the WCF factory

   5:     factory.Close();

   6:     // shutdown IIS express

   7:     IssUtility.TearDownIis();

   8:     issProcess.Abort();

   9: }

At this point I can write any test in the following format:

   1: [TestMethod]

   2: public void ChannelFactory_ReceiveValidCommand_WillExecute()

   3: {

   4:     var expectedCommand = BuildAddUsersCommand();

   5:     service.AddUsers(expectedCommand);

   6: }

I found this technique very useful because we work with TFS on Azure so my Build environment cannot be polluted at all with any third party components or by installing the WCF service under test in the build machine.

In the same way I found very quick to bootstrap IIS express for my tests, honestly they are faster than running on my local IIS 8.

IIS Express utility class

Below is the code I use to initialize IIS express, feel free to use it in your tests and let me know if you come up with a better solution than this one.

   1: namespace xxx

   2: {

   3:     using System.Diagnostics;

   4: 

   5:     public class IssUtility

   6:     {

   7:         private static Process iisProcess;

   8:

   9:         // Start IIS on port 5555

  10:         public static void StartIisExpress()

  11:         {

  12:             var startInfo = new ProcessStartInfo

  13:                 {

  14:                     WindowStyle = ProcessWindowStyle.Normal,

  15:                     ErrorDialog = true,

  16:                     LoadUserProfile = true,

  17:                     CreateNoWindow = false,

  18:                     UseShellExecute = false,

  19:                     Arguments =

  20:                         string.Format("/path:\"{0}\" /port:{1}",

  21:                                         @"your WCF dev path", 5555)

  22:                 };

  23: 

  24:             var programfiles = string.IsNullOrEmpty(startInfo.EnvironmentVariables["programfiles"])

  25:                                     ? startInfo.EnvironmentVariables["programfiles(x86)"]

  26:                                     : startInfo.EnvironmentVariables["programfiles"];

  27: 

  28:             startInfo.FileName = programfiles + "\\IIS Express\\iisexpress.exe";

  29: 

  30:             try

  31:             {

  32:                 iisProcess = new Process {StartInfo = startInfo};

  33: 

  34:                 iisProcess.Start();

  35:                 iisProcess.WaitForExit();

  36:             }

  37:             catch

  38:             {

  39:                 iisProcess.CloseMainWindow();

  40:                 iisProcess.Dispose();

  41:             }

  42:         }

  43: 

  44:         // kill everything

  45:         public static void TearDownIis()

  46:         {

  47:             iisProcess.CloseMainWindow();

  48:             iisProcess.Dispose();

  49:         }

  50:     }

  51: }

Enjoy!

Last week I presented a webinar about Agile Architecture and I got an unexpected positive feedback from it. First it was unexpected because I didn’t expect to get lot of people interested in this particular topic. Second it was unexpected because I am still at the beginning of my teaching career and presenting webinars so I am not so good yet to keep the audience interested for 60 min.

Btw, considering the result of the webinar, I decided to post the video of the webinar (thanks to the guys of Typemock!) and a short introduction to Agile Architecture.

Agile Architecture webinar:

Update: slides available on SlideShare.

Agile architecture

What is Agile Architecture? It is a methodology that follows the Agile guidelines but differ from some aspect of its process.

At this web address: http://www.agilearchitect.org/ you can find probably the official website of this Agile methodology, even if you may find a lot of interesting discussions and articles here and there on the web, just google “Agile Architecture”.

Another interesting web site is http://www.agilemodeling.com/ where you can find tons of information about Agile Modeling and Agile Architecture. (If you watch the webinar I spoke about both of them).

Finally, if you want just to read a quick article and understand the overall process of Agile Architecture, I found this article of J.D. Meier very helpful: “How to design with Agile Architecture”.

TFS Template

I got various requests about the TFS and Dashboard templates I used during the webinar. I got them from the beta of Team Foundation Server 2011, available here. You need to customize the process to fit better Agile Architecture methodology. I am planning to prepare a custom template for TFS 2011 as soon as the SDK will be finalized.

Q/A from the webinar

Below is a short list of some of the most interesting Questions and Answers I got during the webinar. I am posting them here because during the webinar I wasn’t able to read them because I am using the MAC version of GoToWebinar.

Q: Acceptance Tests should have been written before the model.

Not really, if you adopt the strict TDD all the acceptance tests should be written before, but when you envision the architecture, it is too early to write acceptance
tests. When you start the iteration and you have your requirements defined, you may start to model against the acceptance criteria for that iteration. But remember
that the modeling part should be light enough to provide value for the next step.

Q: the functions of the architect are clear, but it is not clear how these functions are intended to fit into the Sprints.

The sprint is composed by three parts, modeling, brainstorm and coding. The architect will perfectly fit into each of this phase. I think I have explained this
concept during the webinar, but just to be sure. During modeling and brainstorm the architect should help with his knowledge and collaborate in the modeling, during
the coding he should be an active coder too and contribute to the technical decisions providing knowledge and expertise.

Q: Can you elaborate on what you mean with the “design phase”?

Ok, during the first iteration, the envision, there is a light design phase. You should design some scratches of your envision, representing the architecture and the UI, but you should not invest too much time.
Design phase while modeling means adopting UML to design your models.

Q: How does your “Iter: 0″ relate to the PO, backlog and sprint planning?

Ah ah, interesting. The envision or iteration 0 is tricky to fit into SCRUM. Take the classic meter to measure an iteration, like 1 or 2 weeks. Inside this timeframe you should have enough space and time to prepare the necessary analysis and mocks required by next steps. So you may consider iter 0 like a beginning sprint.

Q: Couldn’t the use-case diagram be enough for the modelling phase? I’m interested in hearing your reasoning because I’m currently in this situation in my current project. What level of detail is enough when it comes to architecture that lets developers use their brain and problem solving power?

No, the use case is not enough because it may incur into personal interpretation. With the use case and the acceptance you and your team are ready for the modeling phase, where you create the architectural style for that feature. The modeling should be enough to represent the current feature and it should not be implemented, the implementation occurs in the next phase where you apply TDD against the model discussed in the previous part. It is hard to keep the model the blueprint of the code and often it doesn’t provide value. It is important that the model represents what you are delivering.

Q: Does the Process workflow you describe impact the philosophy of embracing change? How can we perform radical change when we get a bigger up-front model?

No, it doesn’t because Agile Architecture pretends the flexibility into your model. Model just enough to represents the feature and remember that you can always come back and re-model and re-factor. Embracing Agile Architecture will force you to have a dynamic more agnostic and flexible model than using a classic architecture approach.
Why would you get a radical change request with a radical model upfront? Of you adopt Agile you should structure these changes into small iterations.

The envision phase is the most critical, you or the architect need to understand what the stakeholder wants from your team. If you get that, you are in a good starting position.
The big mistake is to take too much for the envision, which is not the modeling phase. Mocking out your application doesn’t mean to model everything, so the envision should take few days, at most one week. If it takes more you may have some smells in your team: lack of requirements, lack of business knowledge, lack of technical knowledge.
Remember that every iteration has a modeling phase and a brainstorm phase, so you may move back to the envision and adapt it to the new requirements.

The 9th of May 2012 at 2 p.m. (GMT +1) I will speak about Agile Architecture. The webinar will be registered and hosted by Typemock.

This is the address to register: https://www2.gotomeeting.com/register/427749090

Below is the Agenda and you are still in time to add some little changes:

What is Software Architecture
• What is Agile development
• How they can live together?
Discover principles of Agile architecture
• Lifecycle and process
• Modeling and development
• The right solution for the right problem
• How to deliver quality with (TDD)

If you want to listen about this topic or more feel free to drop me an e-mail (using my blog contact form) and I will be more than glad to expand it during the webinar. Of course it has to be something related to Agile Architecture …

If you want to read more about it I would suggest you the following articles:

Agile Architect principles
http://www.agilearchitect.org/agile/principles.htm

J.D. Meier “Agile Architecture”
http://blogs.msdn.com/b/jmeier/archive/2008/11/06/agile-architecture-method.aspx

PS: I guess if we are numerous I may get a Typemock license available for free to one of the attendee.

I am very excited about this new series I am publishing today. It’s all about caching, a very useful portion of your architecture that should be seriously taken into consideration, especially if you are designing a web application.

Actually, I used NCache with NHibernate and I can only say that it is a very good and valuable product. Of course most of you may believe that I got a free license so this is the reason of my review. Actually I am reviewing this product because I found it pretty good and that’s why the review came up with a short series of articles.

I will show you the following features of NCache:

• NCache architecture
• Simple caching of objects
• Caching of complex graph
• Control the lifetime of a cache

Introduction

From NCache documentation:

NCache is a clustered caching solution that makes sharing and managing data in a cluster as simple as on a single server. It accomplishes this by coordinating updates to the data using cluster-wide concurrency control and replicating and distributing data modifications across the cluster using the highest performing clustered protocol available. The primary purpose of NCache is to help improve performance of .NET applications that would otherwise make expensive trips to database systems, web services, mainframes, or other systems across the network.

Below is a very simplified diagram of NCache architecture (please forgive me for the simplicity of this architecture design):

So, how does it work?

The explanation is pretty simple but in the same time is represented by a complex architecture. You can have two different type of Cache, a local cache or a remote cache. The first one will work because the client has a cache server installed locally, the second one will work with the client accessing the remote cache server from the network.

Of course you can easily swap from a local configuration to a remote configuration without even need to restart or rebuild your application, plus you can easily add or remove cache clusters to your architecture using an “hot swap” technology that doesn’t require any reboot or re-configuration.

Installation

Let’s try to get practical and let’s write some code, otherwise this blog post will get really boring!

In order to use NCache you have to go to this web address and download a 60 days trial version: http://www.alachisoft.com/download.html. There are three major versions: NCache for .NET (x86 and x64) in two flavors, Enterprise and Professional, NCache for Java (x86 and x64) and NCache express (a free version with a limited amount of features). In this demo I will use the full version for .NET in x64 bit Professional. The setup for the professional edition is about ~30 Mb and it’s pretty quick to install.

Note: the only problem you may encounter is with Windows UAC because NCache works better if UAC is disabled. To know more about UAC go here: MSDN Windows ACL

The Wizard will propose you three different types of installation, like the screenshot below:

In my case I need a developer license because I will run everything from my machine and I need also to have access to NCache API. The cache server installation is used to install a new cluster while the Remote Client installation is used to install the client connection components used by your applications to access the remote cache servers.

As soon as NCache is installed you will get a new icon in your start menu (in my case is a tile because I have Windows 8):

In the next posts I will show you how to configure your first cache and how to write a WPF application that will work against this cache.

Stay tuned

In the previous post I have introduced you to NCache architecture. In this post we will create our first cache (locally) and we will write some C# code to interact with this cache.

For the purpose of this series I have created a very simple WPF 4.0 application available from my SkyDrive (see below at the end of this post) that you can download and run locally; but of course you need to install NCache in your development machine.

With this very simple WPF application (even if very simple it works with IoC and MVVM) I have a Listbox that will provide a list of items (books titles). The list will be retrieved with the first command from a database, with the second command from the cache and with the third command the cache will be cleared. The cache is populated automatically after you retrieve the data from the database.

Note: I am including the full source code of this series but this is not a series about MVVM and/or WPF so I will not provide that code inside the posts in order to stay focus on the topic, which is NCache.

Create a new local cache

First of all we need to create a new cache in NCache and this can be easily accomplished using the UI of NCache. Open you instance of NCache and create a new local cache, which is going to be more than enough for our demo.

The following picture shows the steps you need to follow to create a default local cache in your system.

1. Create a new local cache
2. Select the current machine as the destination of the local cache
3. Name the cache
4. Configure the memory allowed by this cache
5. Configure the objects lifecycle for the cache

At this point, NCache will create the new cache and if you have configure it to startup the cache right away, the NCache IDE will open a new window showing you the NCache health status. From this window you can monitor the amount of objects created by the cache and many other functionalities.

Retrieve the data from the database

In this project I have created a very simple database structure that contains a table with a bunch or rows, each row represents a Book record. The data is retrieved using Entity Framework and this is the code used to populate the Listbox:

   1: public IList<Book> GetListOfBooks()

   2: {

   3:     using (var orm = new ORM())

   4:     {

   5:         var results = orm.GetListOfBooks();

   6:         return results

   7:             .Select(result =>

   8:                 new Book {Title = result.Title, ISBN = result.ISBN})

   9:                 .ToList();

  10:     }

  11: }

The data is then DataBound to a WPF listbox using the MVVM pattern:

   1: <ListBox

   2:    Grid.Column="0" Grid.Row="1" Grid.RowSpan="3"

   3:    Style="{StaticResource ListboxStyle}"

   4:    ItemsSource="{Binding Books,IsAsync=True}">

   5:     <ListBox.ItemTemplate>

   6:         <DataTemplate>

   7:             <StackPanel>

   8:                 <TextBlock Text="{Binding ISBN}" />

   9:                 <TextBlock Text="{Binding Title}" />

  10:             </StackPanel>

  11:         </DataTemplate>

  12:     </ListBox.ItemTemplate>

  13: </ListBox>

And the listbox shows the final results:

Retrieve the data from the cache

The second command of the UI is calling the cache, instead of calling the database, to retrieve the data. But, how does it work? I have drawn below a very simple logical flow that my application follows in order to retrieve the data from the cache, when available.

And this is how it works:

   1: // initialize the cache

   2: using (Cache cache = NCache.InitializeCache("Cache"))

   3: {

   4:     var list = new List<Book>();

   5:     // if cache empty, populate the cache

   6:     if (cache.Count == 0)

   7:     {

   8:         IList<Book> books = GetListOfBooks();

   9:         foreach (Book book in books)

  10:         {

  11:             cache.Add(book.ISBN, book);

  12:         }

  13:     }

  14: }

Of course this is just a simple implementation to show you how the NCache mechanism works. It is like working with a simple dictionary of objects if you are not implementing NCache on top of another caching framework.

As soon as you add the items to the cache, the NCache management studio will show you the new objects cached in the system:

Few final notes

• First of all you need to orchestrate your application in a way that the cache will be bootstrapped with the application, bootstrapping the cache in a method of the data layer like I did it is absolutely wrong!
• The objects contained inside the cache, like any other cache system, must be serializable otherwise you will receive a nice runtime exception from NCache.

If you search inside an English dictionary the sentence “leaving for good” you will find the following explanation: “leaving for good means leave a place permanently, with no intention to return”. This is exactly what is going to happen to me and my wife, we are leaving Bermuda for good. It has been 4 years and a half (beginning of 2008) but now it is time to move to a new adventure.

Below I decided to post a brief history of why we moved to Bermuda, what it means live in Bermuda and why we are leaving.

Why did we move to Bermuda?

In 2008 I was working in Switzerland for a private bank and I decided with my wife to challenge our life. We were 28 years old and we were sick of living in a country (Italy) where the only way to have a decent career is to “know somebody …”, in the same time we were exhausted by the “frontaliere” (Italian term used to classify an Italian worker that cross the border with another country every day and comes back home in the evening) life we were having by crossing the border of Switzerland every morning at 7 a.m. and coming back home in the evening at 8 p.m.

I found an interesting offer in Bermuda for a public re-insurance company (Nasdaq company) and I applied for the position of CTO (Chief Technology Officer). Within a few weeks our life has completely changed. I got my job and I had to leave Italy in few weeks and my wife was able to reach me only after 6 months, due to the absolutely insane restrictions that Bermuda immigration department applies to work permit holders.

If somebody asks me now, why did I move to Bermuda? I would say because I was looking for something different, something new, something more challenging. Did I find it? Absolutely yes, even if I am still looking for new challenges and new adventures, I absolutely “realized” what I was looking for when I moved to Bermuda. And to answer to the classic question: “Would you do it again?”, I would say: “Yes I would but I would change some things in a different way”.

What is good about living in Bermuda?

Well, I can’t say that the life in Bermuda was a bad experience.

• First of all you save money, and this is probably the best thing you can do when you are married and your plan is to build a family. In Bermuda salaries are absolutely higher than any other place in the world, tax rate is almost 0% (there are taxes but they were all paid by the employer) and the criminality was very low.
• The weather, it is absolutely nice especially from April to November/December you can easily have some spectacular sunny days and going in the office is really hard!
  In the summertime the humidity can reach insane levels and between July and September you live with the A/C on all day (humidity can reach 90%). The average temperature is 20 C in the spring, 25 C in the summer and 15 C in the winter.
  Of course you are in the Caribbean, more or less, so you can expect: Storms, Hurricanes, Heavy rain and more …
• Meet people from all over the world. Even if Bermuda is a small island, we got the opportunity to meet people from all over the world. US, Europe, Australia, New Zeeland, you name it … This has been a fantastic experience, I made a lot of friends and even if I won’t see them anymore (maybe) I learned that the sex, the color of the skin and/or the nationality doesn’t really matter; you can find good and bad people coming from the same town.

What is bad about living in Bermuda?

Wow, do you really want me to open this Pandora Box? Seriously?

• Bureaucracy simply too long. Bermuda is a small island, there is an average of 60,000 people and 4/5,000 expats some says 10,000. The amount of public employees, considered the size of the island, is big and every single public service has problems. It takes long to get paperwork’s and permits and as soon as there is a little issue it will just take more time. They are starting some telematics automation but it is still not enough, especially from a geek point of view.
• Food quality is something that you have to deal with on a small island in the ocean, especially if you compare with the high price. One Apple may cost you around 1.5$,the water is very expensive, one bottle of sparkly water costs you almost 2.5$ … The meat and the fish are frozen and expensive too, because every single piece of food, or most of them must be imported by sea in the island. 
• Cultural difference, living on a small Island is different than living in a big a city and local culture and approach to socialization and communication is very different; for example, Bermuda requires a special ceremony composed by “Good morning, how are you?” that needs to be included before any request or question to a local. It is not bad but if you don’t know the local culture you may risk to be misunderstood.
• Infrastructure difference. If you come from a big city you may find fundamental to have high speed internet, cable TV, wireless everywhere and many other services. I had 3G and DSL in Bermuda but it was very expensive and not so high speed as I would like to have. Plus with bad weather conditions you may struggle in receiving good signals.

Why Netherlands?

We have been in the Netherlands few times and visited the entire country, we love the flat landscape because is simple and well organized, Dutch are  friendly people and even if you speak only English you can easily communicate with everybody. The social system is expensive but works pretty well, so I prefer to pay more taxes but live in a system where everything works properly. The food is not too expensive and the quality is good. Traffic with the car is more complicated but if you ride a bicycle is the perfect place for you!

It is absolutely organized, consider that we found an apartment from internet, we saw it and we liked and when we moved in it was absolutely perfect. Every single paperwork has been done from internet and we received in the new location all the documents we needed.

Below I want to share some nice shot (not mine) taken from www.flickr.com. They represent where I was and I where we are now! Enjoy.   

Bermuda photos

Bermuda VIEW SLIDE SHOW DOWNLOAD ALL

Den Haag photos

Den Haag VIEW SLIDE SHOW DOWNLOAD ALL

In this series of articles we saw how the cache system is implemented in NHibernate and what can we do in order to use it. We also saw that we can choose a cache provider but we didn’t have a look yet at what providers we can use.

I personally have my own opinion about the 2nd level cache providers available for NHibernate 3.2 and I am more than happy if you would like to share with me your experience about it.

Below is a list of the major and the most famous 2nd level cache providers I know:

I would personally suggest you to answer the following questions in order to understand what is the cache provider you need for your project:

• Size of you project (small, standard, enterprise)
• Cache technology you have already in place
• Quality attributes required by your solution (scalability, security, …)

SysCache

It is an abstraction over ASP.NET cache so it can’t be used in a non-web application. It works but Microsoft suggest to do not use it for non-web applications.

The cache space is not configurable so it is the same for different session factories … really dangerous on a web application that requires isolation between the various users (http://ayende.com/blog/1708/nhibernate-caching-the-secong-level-cache-space-is-shared)

Useful for: small in house projects, better for web projects hosted in IIS

NCache

NCache is a distributed in-memory Object cache and a distributed ASP.NET Session State manager product.

It is able to synchronizes cache across multiple servers so it is designed also for the enterprise.

It provides dynamic clustering & cache configuration for 100% uptime for a real scalable architecture.

Cache reliability through data replication across servers

InProc/OutProc cache for multiple processes on same machine

API identical to ASP.NET Cache

It is available for download and trial here http://www.alachisoft.com/ncache/edition-comparison.html, it is a third party provider and it is not free.

Useful for: medium to big applications that are designed to be scalable

MemCache

MemCache is a famous Linux cache system designed exclusively for the enterprise. It is a complex enterprise cache system based on Linux platform that provide a cache mechanism also for NHibernate.
It is pretty easy to be scaled on a big server farm because it is designed to do so
It does not require licensing cost because it’s an OSS and it is a well known system with a big community.

The following picture represents the core logic of MemCache:

The only downside is that it requires a medium knowledge of Linux OS in order to be able to install and configured it.

Useful for: enterprise applications that are designed to be scalable

Velocity, a.k.a. AppFabric

Velocity has been now integrated in AppFabric and it is the cache system implemented by Microsoft for the enterprise. It requires AppFabric and IIS and it can be used locally or with Azure (does it make sense to cache in the cloud?? ).

• AppFabric Caching, provides local caching, bulk updates, callbacks for updates, etc… so this is why it’s exciting over something like MemCache which doesn’t provide these features Out of the Box.
• For enterprise architectures, really scalable, Microsoft product (there may be a license requirement)

Useful for: enterprise applications that are designed to be scalable

In the previous post we saw how the cache system is structured in NHibernate and how it works. We saw that we have different methods to play with the cache (Evict, Clear, Flush …) and they are all associated with the ISession object because the cache of level 1 is associated with the lifecycle of an ISession object.

In this second article we will see how the second level cache works and how it is associated with the ISessionFactory object that is in charge of controlling this cache mechanism.

Second Level cache architecture

How does the second level cache work?

First of all, when an entity is cached in the second level cache, the entity is disassembled into a collection of keys/values pair, like a dictionary and persisted in the cache repository. This mechanism is accomplished because most of the second level cache providers are able to persist serialized dictionary collections and because in the same time NHibernate does not force you to make serializable your entities (something that IMHO, should never be done!!).

A second mechanism happens when we cache the result of a query (Linq, HQL, ICriteria) because these results can’t be cached using the first level cache (see previous blog post). After we cache a query result, NHibernate will cache only the unique identifiers of the entities involved in the result of the query.

Third, NHibernate has an internal mechanism that allows him to know and keep track of a timestamp value used to write tables or to work with sessions. How does it work? Well the mechanism is pretty clear, it keeps track of when the last table was written too. A series of mechanism will update this timestamp information and you can find a better explanation of Ayende’s blog: http://ayende.com/blog/3112/nhibernate-and-the-second-level-cache-tips.

Configuration of the second level cache

By default the second level cache is disabled. If you need to use the second level cache you have to let NHibernate know about that. The hibernate.cfg file has a dedicated section of parameters that should be used to enable the second level cache:

<property name="cache.provider_class">

NHibernate.Cache.HashtableCacheProvider

</property>

<!-- You have to explicitly enable the second level cache ->

<property name="cache.use_second_level_cache">

true

</property>

First of all we specify the cache provider we are using, in this case I am using the standard hashtable provider, but I will show you in the next article what are the real providers you should use. Second we say that the cache should be enabled; this part is really important because if you do not specify that the cache is enable, it simply won’t work …

Then you may provide to the cache a default expiration in seconds:

<!-- cache will expire in 2 minutes -->

<property name="cache.default_expiration">120</property>

If you want to add additional configuration properties, they will be cache provider specific!

Cache by mapping

One of the possible configuration is to enable the cache at the entity level. This means that we are marking our entity as “cachable”.

<class

name="CachableProduct“

table="[CachableProduct]“

dynamic-insert="true“

dynamic-update="true">

<cache usage="read-write"/>

In order to do that we have to introduce a new tag, the <cache> tag. In this tag we can specify different type of “”usage”:

• Read-write

  It should be used if you plan also to update the data (no with serializable transaction)

• Read-only

  Simplest and best performing, for read only access

• Nonstrict-read-write

  If you need to occasionally update the data. You must commit the transaction

• Transactional

  not documented/implemented yet because no one cache provider allows transactional cache. It is implemented in the Java version because J2EE allow transactional second level cache

Now, if we write a simple test that will create some entities and will try to retrieve them using two different ISession generated by the same ISessionFactory we will get the following behavior:

using (var session = factory.OpenSession())

{

// create the products

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** FIRST SESSION ***");

var expectedProduct1 = session.Get<CachableProduct>(productId);

Assert.That(expectedProduct1, Is.Not.Null);

tx.Commit();

// retrieve the number of hits we did to the 2nd level cache

Console.WriteLine("Second level hits {0}", 
           factory.Statistics.SecondLevelCacheHitCount);

}

}

using (var session = factory.OpenSession())

{

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** SECOND SESSION ***");

var expectedProduct1 = session.Get<CachableProduct>(productId);

Assert.That(expectedProduct1, Is.Not.Null);

tx.Commit();

// retrieve the number of hits we did to the 2nd level cache

Console.WriteLine("Second level hits {0}", 
           factory.Statistics.SecondLevelCacheHitCount);

}

}

The result will be the following:

As you can see the second session will access the 2nd level cache using a transaction and will not use the database at all. This has been accomplished just by mapping the entity with the <cache> tag and by using the GET<T> method.

Let’s make everything a little bit more complex. Let’s assume for a second that our object is an aggregate root and it is more complex than the previous one. If we want to cache also a collection of child or a parent reference we will need to change our mapping in the following way:

<!-- inside the product mapping file -->

<bag name="Attributes" cascade="all" inverse ="true">

<cache usage="read-write"/>

<key column="ProductId" />

<one-to-many class="CacheAttribute"/>

</bag>

<!-- inside theCacheAttribute file -->

<class

name="CacheAttribute"

table="[CacheAttribute]"

dynamic-insert="true"

dynamic-update="true">

<cache usage="read-write"/>

<!-- omit -->

<many-to-one

class="CachableProduct"

name="Product" cascade="all">

<column name="ProductId" />

</many-to-one>

</class>

Now we can execute the following test (I am omitting some parts for saving space, I hope you don’t mind …)

using (var session = factory.OpenSession())

{

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** FIRST SESSION ***");

var expectedProduct1 = session.Get<CachableProduct>(productId);

Assert.That(expectedProduct1, Is.Not.Null);

Assert.That(expectedProduct1.Attributes, Has.Count.GreaterThan(0));

tx.Commit();

Console.WriteLine("Second level hits {0}",

factory.Statistics.SecondLevelCacheHitCount);

}

}

using (var session = factory.OpenSession())

{

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** SECOND SESSION ***");

var expectedProduct1 = session.Get<CachableProduct>(productId);

Assert.That(expectedProduct1, Is.Not.Null);

Assert.That(expectedProduct1.Attributes, Has.Count.GreaterThan(0));

tx.Commit();

Console.WriteLine("Second level hits {0}",

factory.Statistics.SecondLevelCacheHitCount);

}

}

And this is the result from the profiled SQL:

In this case the second ISession is calling the cache 4 times in order to resolve all the objects (2 products x 2 categories).

Cache a query result

Another way to cache our result is by creating a cachable query that is slightly different than creating a cachable object.

To write a cachable query we need to implement an IQuery object in the following way:

using (var session = factory.OpenSession()) {

     using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

     {

        var result = session

             .CreateQuery("from CachableProduct p where p.Name = :name")

             .SetString("name", "PC")

             .SetCacheable(true)

             .List<CachableProduct>();

        tx.Commit();

     }

}

Now, let’s try to write a unit test for this:

using (var session = factory.OpenSession())

{

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** FIRST SESSION ***");

var result = session

.CreateQuery("from CachableProduct p where p.Name = :name")

.SetString("name", "PC")

.SetCacheable(true)

.List<CachableProduct>();

Console.WriteLine("Cached queries {0}",

factory.Statistics.QueryCacheHitCount);

Console.WriteLine("Second level hits {0}",

factory.Statistics.SecondLevelCacheHitCount);

tx.Commit();

}

}

using (var session = factory.OpenSession())

{

using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

{

Console.WriteLine("*** SECOND SESSION ***");

var result = session

.CreateQuery("from CachableProduct p where p.Name = :name")

.SetString("name", "PC")

.SetCacheable(true)

.List<CachableProduct>();

Console.WriteLine("Cached queries {0}",

factory.Statistics.QueryCacheHitCount);

Console.WriteLine("Second level hits {0}",

factory.Statistics.SecondLevelCacheHitCount);

tx.Commit();

}

}

And this is the expected result:

In this case the cache is telling us that the second session has 1 query result cached and that we called it once.

Final advice

As you saw using the 1st and 2nd level cache is a pretty straightforward process but it requires time and understanding of NHibernate cache mechanism. Below are some final advice that you should keep in consideration when working with the 2nd level cache:

• 2nd Level Cache is never aware of external database changes!
• Default cache system is hashtable, you must use a different one
• Wrong implementation of the 2nd level cache may result in a non expected performance degrade (i.e. hashtable doc)
• First level cache is shared across same ISession, second level is shared across same ISessionFactory

In the next article we will see what are the available cache providers.

In this series of articles I will try to explain you how NHibernate cache system works and how it should be used in order to get the best performance/configuration from this product.

• Introduction 
  • Architecture
  • Cache Level 1 mechanism
  • Load and Get, what’s the difference
  • Session maintenance: Evict, Flush and Clear
• 2nd Level Cache
  • Architecture
  • Configuration
  • Cache by mapping
  • Cache by query
  • Final advice
• Cache providers (most known)

NHibernate Cache architecture

NHibernate has an internal cache architecture that I will define absolutely well done. On an architectural point of view, it is designed for the enterprise and it is 100% configurable. Consider that it allows you to create also your custom cache provider!

The following picture show the cache architecture overview of NHibernate (actually the version I am talking about is the 3.2 GA).

The cache system is composed by two levels, the cache of level 1 that usually it is configured by default if you are working with the ISession object, and the cache of level 2 that by default is disabled.

The cache of level 1 is provided by the ISession data context and it is maintained by the lifecycle of the ISession object, this means that as soon as you destroy (dispose) an ISession object, also the cache of level 1 will be destroyed and all the corresponding objects will be detached from the ISession. This cache system works on a per transaction basis and it is designed to reduce the number of database calls during the lifecycle of an ISession. As an example, you should use this cache if you have the need to access and modify an object in a transaction, multiple times.

The cache of level 2 is provided by the ISessionFactory component and it is shared across all the session created using the same factory. Its lifecycle correspond to the lifecycle of the session factory and it provides a more powerful but also dangerous set of features. It allows you to keep objects in cache across multiple transactions and sessions; the objects are available everywhere and not only on the client that is using a specific ISession. 

Cache Level 1 mechanism

As soon as you start to create a new ISession (not an IStatelessSession!!) NHibernate starts to holds in memory, using a specific mechanism, all the objects that are involved with the current session. The methods used by NHibernate to load the data into the cache are two: Get<T>(id) and Load<T>(id). This means that if you try to load one or more entities using: LinQ, HQL, ICriteria … NHibernate will not put them into the cache of level 1.

Another way to put an object into the lvl1 cache is to use persistence methods like Save, Delete, Update and SaveOrUpdate.

As you can see from the previous picture, the ISession object is able to contains two different categories of entities, the one that we define “loaded” using Get or Load and the one that we define “dirty”, which means that they were somehow modified and associated with a session.

Load and Get, what’s the difference?

A major confusion I personally noticed while working with NHibernate is the not correct usage of the two methods Get and Load so let’s see for a moment how they work and when they should or should not be used.

I personally prefer Get because it returns NULL instead of throwing a nasty exception, but this is a personal choice; while some of you may prefer to use Load because you want to avoid a database call until is really needed.

Below I wrote a couple of very simple tests to show you how the Get and Load methods work across the same ISession.

Get<T>()

   1:  [Test]

   2:  [Category("Database")]

   3:  public void UsingGetThePersonIsFullyCached()

   4:  {

   5:      using (var session = factory.OpenSession())

   6:      {

   7:          using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))

   8:          {

   9:              var persons = MockFactory.MakePersons();

  10:              persons.ForEach(p => session.Save(p));

  11:              tx.Commit();

  12:              session.Clear();

  13:              Console.WriteLine("*** FIRST SELECT ***");

  14:              var expectedPerson1 = session.Get<Person>(persons[0].PersonId);

  15:              Assert.That(expectedPerson1, Is.Not.Null);

  16:              Console.WriteLine("*** SECOND SELECT ***");

  17:              var expectedPerson2 = session.Get<Person>(persons[0].PersonId);

  18:              Assert.That(expectedPerson2, Is.Not.Null);

  19:              Assert.That(expectedPerson2.FirstName, Is.Not.EqualTo(string.Empty));

  20:          }

  21:      }

  22:  }

In this test I have created a list of Persons in one transaction and then I cleared the session in order to be sure that nothing was left in the cache. Then I loaded one of the Person entities using the Get<T> method and then I load it again using the same method call in order to verify that the SELECT statement was issued only once.

As you can see, NHibernate is loading the entire entity from the database in the first call, and in the second one is simply loading it again from the level 1 cache. You should notice here that NHibernate is loading the entire entity in the first Get<T> call.

Load<T>()

[Test]
[Category("Database")]
public void UsingLoadThePersonIsPartiallyCached()
{
    using (var session = factory.OpenSession())
    {
        using (var tx = session.BeginTransaction(IsolationLevel.ReadCommitted))
        {
            var persons = MockFactory.MakePersons();
            persons.ForEach(p => session.Save(p));
            tx.Commit();
            session.Clear();
            Console.WriteLine("*** FIRST SELECT ***");
            var expectedPerson1 = session.Load<Person>(persons[0].PersonId);
            Assert.That(expectedPerson1, Is.Not.Null);
            Console.WriteLine("*** SECOND SELECT ***");
            var expectedPerson2 = session.Load<Person>(persons[0].PersonId);
            Assert.That(expectedPerson2, Is.Not.Null);
            Assert.That(expectedPerson2.FirstName, Is.Not.EqualTo(string.Empty));
        }
    }
}

In this second test I am executing the same exact steps of the previous one, but this time I am using the Load<T> method and the result is completely different! Look at the SQL log below:

Now NHibernate is not loading the entity from the database at all, it is loading it only in the second call, when I try to hit one of the Person properties. If you debug this code you will notice that NHibernate issues the database call at the line Assert.That(expectedPerson2.FirstName, Is.Not.EqualTo(string.Empty)); and not before!

Session maintenance

If you are working with the ISession object in a Client application or if you are keeping it alive in a web application using some strange behaviors like keeping it saved inside the HttpContext you will realize, soon or later, that sometimes the cache of level 1 needs to be cleared.

Now, despite the fact that these methods (based on my personal experience) should never be used, because it means that you are wrongly implementing your data layer, and despite the fact that the behavior of these methods may result in something unexpected, NHibernate provides three different methods to clear the cache of level 1 content.

I will probably write more about these three methods in some future post but if you need to investigate more about them, I would suggest you to read carefully the NHibernate docs available here: http://www.nhforge.org/doc/nh/en/index.html

In the next article we talk about the level 2 cache.

Last week I came up with a fancy requirement that forced me to struggle a little bit in order to find an appropriate solution. Let’s say that we have a massive solution file, containing something like 100ish projects and we would like to keep the same assembly version number for all these projects.

In this article I will show you how the assembly version number works in .NET and what are the possible solutions, using Visual Studio.

Assembly version in .NET

As soon as you add a new project (of any type) in Visual Studio 2010, you will come up with a default template that contains also a file “AssemblyInfo.cs” if you are working with C# or “AssemblyInfo.vb” if you are working with VB.NET.

If we look at the content of this file we will discover that it contains a set of attributes used by MSBuild to prepare the assembly file (.dll or .EXE) with the information provided in this file. In order to change this information we have two options:

1. Edit the AssemblyInfo.cs using the Visual Studio editor.
   In this case we are interested in the following attributes, that we will need to change every time we want to increase the assembly version number:
   

      1:  using System.Reflection;

      2:  using System.Runtime.CompilerServices;

      3:  using System.Runtime.InteropServices;

      4:   

      5:  [assembly: AssemblyVersion("1.0.0.0")]

      6:  [assembly: AssemblyFileVersion("1.0.0.0")]

2. Or, we can open the Project properties window from Visual Studio using the shortcut ALT+ENTER or by choosing “properties” of a VS project file from the Solution Explorer
   
   

How does the versioning work?

The first thing that I tried was to understand exactly how this magic number works in .NET.

If you go to the online MSDN article, you will find out that the version number of an assembly is composed by 4 numbers, and each one has a specific mean

1. Major = manually incremented for major releases, such as adding many new features to the solution.

0. Minor = manually incremented for minor releases, such as introducing small changes to existing features.

0. Build = typically incremented automatically as part of every build performed on the Build Server. This allows each build to be tracked and tested.

0 Revision = incremented for QFEs (a.k.a. “hotfixes” or patches) to builds released into the Production environment (PROD). This is set to zero for the initial release of any major/minor version of the solution.

Two different assembly version attributes, why?

I noticed that the [assembly] attribute class exposes two different properties, Assembly Version and Assembly File Version.

AssemblyFileVersion

This attribute should be incremented every time our build server (TFS) runs a build. Based on the previous description you should increase the third number, the build version number. This attribute should be placed in a different .cs file for each project to allow full control of it.

AssemblyVersion

This attributes represents the version of the NET assembly you are referencing in your projects. If you increase this number in every TFS build, you will incur in the problem of changing your reference redirect every time the assembly version is increased.

This number should be increased only when you release a new version of your assembly and it should be increase following the assembly versioning terminology (major, minor, …)

Control the Versioning in Visual Studio

As I said before VS allows us to control the version number in different ways and in my opinion using the properties window is the easiest one. As soon as you change one of the version numbers from the properties window, also the AssembliInfo.cs file will be automatically changed.

But what happens if we delete the version attributes from the assembly info file? As expected VS will create an assembly with version 0.0.0.0 like the picture below:

Sharing a common Assembly version on multiple projects

Going back to the request I got, how can we setup a configuration in Visual Studio that allows us to share on multiple projects the same assembly version? A partial solution can be accomplished using shared linked files on Visual Studio.

Ok, what’s a shared linked file, first of all? A linked file is a file shortcut that points in multiple projects to the same single file instance. A detailed explanation of this mechanism is available on Jeremy Jameson’s blog at this page.

Now, this is the solution I have created as an example where I share an AssemblyVersion.cs file and an AssemblyFileVersion.cs file to the entire Visual Studio solution.

Using this approach we have one single place where we can edit the AssemblyFileVersion and the AssemblyVersion attributes. In order to accomplish this solution you need to perform the following steps:

1. Delete the assembly version and the assembly file version attributes for all the existing AssemblyInfo.cs files
2. Create in one project (the root project) a file called AssemblyFileVersion.cs containing only the attribute AssemblyFileVersion
3. Create in one project (the root project) a file called AssemblyVersion.cs containing only the attribute AssenblyVersion
4. Add as linked files these two files to all the existing projects
5. Re-Build everything

Final note on Visual Studio properties window

Even if my root project has now two files with the attributes AssemblyFileVersion and AssemblyVersion, when I open the Visual Studio properties window, it tries to search for these attributes in the AssemblyInfo.cs file, and clearly, it can’t find them anymore, so it does not display anything:

If you add a value to these textboxes Visual Studio will re-create the two attributes in the AssemblyInfo.cs file without taking care of the two new files we have created and as soon as you try to compile the project you will receive this nice error:

So, in order to use this solution you need to keep in mind that you can’t edit the AssemblyFileVersion and the AssemblyVersion attributes from the VS properties window if they are not saved in the AssemblyInfo.cs file!

I believe that MS should change this in the next versions of Visual Studio.

Last month (21st of July 2011) I spoke at the Bermuda NET Event “Migrating WinForm applications to WPF/Silverlight”. This has been for me the first NET Event in Bermuda but for sure it will not be the last one. We are planning to have a new event this autumn where we will touch other topics like: ALM, Parallels and more.

Thanks to Alessio Bellisomi, the web developer that works in my company, I am able to share with you some nice pictures of the event and three short movie of the event. Unfortunately, for this event, we were not super organized so I do not have with me the full video of the entire event. I promise that for the next event we will provide the entire video and maybe we will be also able to stream the content.

The audience, considering that we were in Bermuda and considering that it was end of July, was more than expected. I believe we were around a 30/40 ish attendees. The feedback has been really positive and we expect a very fast grow of this UserGroup by having more events and more speakers.

Pictures

The pictures are available through Google photos

Slides

Videos

The videos have been hosted on my Vimeo account and they can be viewed through their web site

Bermuda WinForm event, part 01 from Raffaele Garofalo on Vimeo.

Bermuda WinForm event, part 02 from Raffaele Garofalo on Vimeo.

Bermuda WinForm, part 03 from Raffaele Garofalo on Vimeo.

Thanks

Special thanks need to go to Sandra de Silva (president of the UG and owner of Nova Ltd) and to the other members of the committee. I want also to thank all the participants and I hope this autumn there will be more!

Last year in Bermuda we had a new born, a NET community. The community has been created by some locals companies to attract developers, architects and analyst; but also anybody passionate of development.

You can check-out the web site here: http://www.dnug.bm/.

This month I will have the opportunity to present my two books:

• Applied WPF in context (APRESS)
• Build enterprise application with WPF and MVVM (MS PRESS)

and to talk about WPF/Silverlight.

During this event I will explain what are the common problems you may encounter when moving from legacy applications to WPF/Silverlight. When you should and when you should not migrate an application to a new UI technology. When you should use WPF and when you should use Silverlight. Oh and I will also give some free copies of my books plus some additional discounts.

This is the page of the event: http://www.dnug.bm/index.php?option=com_jevents&task=icalrepeat.detail&evid=5&Itemid=58&year=2011&month=07&day=21&title=july-2011-dot-net-user-group-event&uid=a620ff387a7449aaad68443c9780f7c2

If you are planning a vacation around the 21st of July, please come here and join us in this first event about WPF/Silverlight.

Hope to see you there!

PS: I forgot to mention that one of the amazing price for the attendees is to win a 1 year subscription to MSDN.

Note for purists: In this tutorial I am showing you a simplified example of a Unit of Work and a Repository, please do not care about the complexity or simplicity of these objects but look at the TypeMock implementations.

We are now at the third post of this series and I found out that there are a lot of readers interested in learning TypeMock, which means that series will have to continue!

Last time, we have created some object’s mocks using TypeMock but they were simple Value Objects with nothing or very few business logic in it. This time I want to show you how you can control the behaviors of a mock so that you do not have to control or fake the entire object if you are testing a single method.

Testing a IUnitOfWork

I do not know if you have already created a data layer in your career of software developer; if you did not, you can have a look at one of my tutorials or books about layering an application.

First of all we have a Unit of Work, which allows us to “Save”, “Update” or “Delete” the object we are passing it using a generic signature. The contract for a Unit of Work is represented by the following image:

As you can see we have a simple interface with three methods and we still do not have an implementation for it but we have some expectations that we would like to pre-test using a mock in order to be sure that the next step will be properly handled by TypeMock.

The pre-requisite is that every entity in our domain has some properties inherited by a base class DomainObject; these properties can tell us the ID of the entity, if the entity is new, modified or deleted.

The following object represents the base class for a domain entity.

The 3 properties are of type boolean while the UniqueId is of type Guid, so by default we will have a Guid.Empty value and after we mark dirty or updated the object we should have them populated.

Test the interface

If we test the interface we can start by writing three different expectations like the three following snippets:

And as soon as we run this test it simply fails because of course TypeMock is not able to properly mock the method MarkNew as we did not instruct it on how to do it …

The solution in this case is pretty straightforward, before invoking the MarkNew<T> method we need to teach to TypeMock what is our expectation for this method when we add a Person object to it.

In this case we have informed TypeMock that when we will call the method MarkNew<T> passing as a generic paramenter the Person object, it will have to modify the person object and return it with a new ID and the IsNew property populated.

Another way to do that is to use the WillReturn method of TypeMock that can be used, like in this case when we have functions and not void methods.

In the same way we can test that the method may also return an unexpected exception, so we can inform TypeMock to force the mock interface to throw an exception.

This section of type mock is called Controlling method behaviors and you can find a detailed documentation about it at this address:

controlling methods

In the next tutorial we will see how to customize a chain of mockup object and faking the methods so that the IUnitOfWork will be used as a dependency for a Repository class.

If you want you can also download the code of every tutorial at this address on Codeplex:

http://typemock.codeplex.com/

Encrypted string of the week: IHcKGzESRVs=
using Blowfish CBC 64bit

In this new  part of the TypeMock series I am going to show you how to deal with objects and classes in general, how you can create them and what are (honestly aren’t) the limit of TypeMock on dealing with objects.

First of all I have just drawn down a little domain that I have added to the demo application. I am planning to upload this demo the next week on Codeplex.com so that every geek reading this blog can just go there and download the source code.

The Demo domain

The domain is a very simple one, we have an abstract base class called Person, then we have two concrete classes, an Employee and a Customer that right now do not have any differences (we will see in the next tutorials why we have two different concrete classes) and then we have a value object Address that is composed only if we provide to it a parent Person object in the constructor. The Person entity exposes a read-only IEnumerable collection of Addresses, so in order to add or remove an address we must use the provided methods AddAddress and RemoveAddress.

The following picture shows the corresponding class diagram of this small domain.

These are the most important piece of code that you may be interested in:

and

As you can see we have few things that need to be tested but in order to do that we have to create new instances of these objects in order to run our tests, which is pretty verbose and boring …

Create the test project

The first step is to create a new Visual Studio 2010 Visual C# class library project and call it TypeMockDemo.Fixture and add the following references to it:

The references are pointing to:

• my TDD framework nUnit (you can work with any TDD framework but I personally found nUnit to be the best out there …)
• TypeMock assemblies, installed in the GAC of your machine
• The TypeMockDemo project (the one we have the domain entities in)

Now we can start to create the first class fixture and verify that we can create a new Person, a new Employee and a new Customer. But hold on a second! How can we mock an abstract and two sealed class with a mocking framework? We simply can’t if we are not using TypeMock …

Looking at the code we have introduced the new method Isolate.Fake.Instance<T> that is coming from TypeMock. With this method we can simply inform TypeMock that we want it will create for us a Proxy of the object we want to mock and it will return a derived class of the tested one, even if we are mocking a sealed class.

If the class is sealed TypeMock will create a new instance of the original object while if the object is abstract, TypeMock will create a proxy version of that object. Same thing will be done for all the child properties, complex or not …

That’s simply wow, we just used two lines of code to create a mockup and test it.

Now let’s move forward and let’s verify that we will not be able to add the same address twice and to remove the same address twice from a Person object.

Working with Instances or Proxy?

First of all we start to create this simple test but the result is not the one we expect …

nUnit bombs saying that at line 8 the expected result is supposed to be 1 but in reality is 0. Why? This happens because TypeMock has created a full mockup proxy of the person object so also the methods AddAddress and RemoveAddress are mocks and they do not point to the real code we have implemented …

If we change the way TypeMock is creating the object Person, we can now say to it:

“Dear TypeMock, I want that you create an instance of my object and that you call its constructor so that I can test the code I have implemented in this abstract class …”

Et voila’, the test will pass! Same thing for the remove address and so on …

Now, the last test we may require is that we want to be sure that when we create a new address, the constructor is properly injecting the parent Person object so that we can keep a back-forward reference from the parent object and the collection of children.

We run the test and kabum! It fails again. This time it fails on the address side because the Person instance TypeMock is injecting is not the same it returned to use in the previous line of code. So what can we do now?

We can manually create an Address and inject the parent Person but it sucks … or we can do this:

We simply inject the person value we want to use (the one created by TypeMock) because this is what it is going to happen with live code. What we care here is to be sure that inside the Address class constructor, the Person parameter is passed to the read-only property Person of the Address class, nothing more, nothing less!

Conclusion

As you can see, TypeMock is pretty cool and it allows you to control the way we can create and fake objects. Even if we use proxies we can still ask to TypeMock to create a real mock that reflect our code so that we can still test the business logic included in our objects without the need of creating complex objects manually.

If you want to read more about this topic I kindly suggest you this:

• Faking instances of an object
• Handling object constructor

In the next tutorial we will see how to customize the methods and other behaviors of an object and I will also publish the first part of the quiz that will allow you to win almost 1,000 USD value of TypeMock license!

Stay tuned

Just a little OT to keep you up to date also about my private life (if anyone of you cares … ).

Last Friday we got a new member in our family, after we lost our precious Doberman after 10 years, we decided to move forward and forget the drama by getting a new dog. This time we bought a Jack Russell Terrier … what a Devil!

Her name is Sophie, she is now 3 months old and she is the alpha of her litter … so a little bit a “devil dog”. Really energetic and with a strong character! A nice challenge for me and my wife.

The first thing we want to teach her is to jump on a surf board and surf! I will publish a video of her soon.

For now, enjoy this:

Sophie (little devil) VIEW SLIDE SHOW DOWNLOAD ALL

The best way to learn a tool is to try it, test it and then finally use it over your code. Of course if the tool provides also a great community support and a great documentation the task will be easier.

Some weeks ago we started to adopt a wonderful tool to create mockups and other TDD fancy stuff, the tool is TypeMock.

The idea I got is to create a series of tutorials about TypeMock and provide to you a piece of a code to download a full license of this tool. At the end of the series (probably 1 month) you will be able to enable your 10 days trial into a full working license. I will create a sort of bid and from all my readers that will contact me to get the license I will come up with one or two free licenses.

Guys, consider that one license of TypeMock is 800 $ !!

Setup and Installation

In order to start right away with TypeMock you need to download the latest version of the tool (at this time they have the version 6.0.10) but be careful because they upload new versions often. The product you need to download for .NET is Isolator.NET. They also provide additional tools that we will analyze during this series, like:

• TestDriven.NET, an integrated test runner for Visual Studio
• Isolator for Sharepoint
• Isolator for ASP.NET and ASP.NET MVC
• TeamMate, a useful tool to monitor your TDD approach
• Isolator ++, the same version but for C++
• TestLint, a nice tool that will help you to develop your TDD skill

and more.

After you have downloaded the setup (7 Mb) you will have to follow a very straightforward setup wizard with only two options available; use the advanced option and install everything including the samples for .NET.

That’s it, you are now ready to go!

File Location

TypeMock is installed on your C:\ drive and depending on where you choose to install it, you should have a folder called TypeMock/Isolator/6.0 on your Program Files directory. Inside this folder you can find all the assemblies available from TypeMock.

You do not need to use them directly as TypeMock is also installed on your GAC folder but if you plan to work with C.I. (Continuous Integration) you may probably need to add a reference to these files instead of pointing directly to the GAC, depending on what type of build server you are working with …

Inside the folder Examples you will find a set of useful examples to start to learn TypeMock quickly but do not worry as I will go through all these examples in this series.

If you want to make your experience with TypeMock easier and smoother, I kindly suggest you to download and install also TestDriven.NET or Resharper with Gallio. I personally use and love Resharper so you will find in this series all the reference examples pointing to the Resharper UI inside Visual Studio. The choice is up to you but I personally believe R# is the best tool so far for Visual Studio (IMHO)

Visual Studio integration

After the installation you can open Visual Studio and this is the surprise you will find in the IDE:

You will find a new menu on Visual Studio called TypeMock; in this menu you can setup the license, the profiler to use with TypeMock and few other options for a better Visual Studio experience.

There aren’t a lot of other ways to easily configure TypeMock but we will see together how you can tackle each of the common tasks you may encounter while working with TypeMock.

From this menu you have also the easy option of enabling/disabling TypeMock at anytime so that you can or cannot work with it without the need to restarting Visual Studio every time (like you have to do with other plugins of Visual Studio).

The Demo Project

I have created a very small project for this series of tutorials to show you how you can test every single layer of a .NET application using TypeMock to separate the dependencies. The structure of the demo project is in the following way:

The project is composed by 4 different layers:

1. TypeMockDemo: the project that contains the Domain Model of the tutorial
2. TypeMockDemo.DataLayer: a data layer built around NHibernate 3.2
3. TypeMockDemo.ServiceLayer: the service layer used to write the business logic around the domain and the data layer
4. TypeMockDemo.UserInterface: an application developed using WPF 4.

For each project there is a corresponding “fixtures” project that includes all the fixtures related to the project. With fixture I mean “test” …

Tutorials and resources

Before starting to follow this series I kindly suggest you to have a look at the TypeMock web site learning content, so that you will follow better my tutorials. As you know, I do not usually go too deep into a specific topic, so if you need to learn also what TDD is, I kindly suggest you to read also the following tutorials about TDD and testing in general.

TypeMock learning content:

• Introduction to TypeMock http://www.typemock.com/getting-started-step-1-set/
• General articles and web casts http://www.typemock.com/general-unit-testing-pages/
• TypeMock documentation

TDD learning content:

• TDD
  http://en.wikipedia.org/wiki/Test-driven_development
  http://www.agiledata.org/essays/tdd.html
• Tutorials
  This is a very complete introduction to TDD in .NET
  http://www.codeproject.com/KB/dotnet/tdd_in_dotnet.aspx

So stay tuned and I’ll see you next Friday for the next part of this series.

The Microsoft’s book I have published few months ago: “Building Enterprise Applications with WPF and MVVM” has been a success but I still got some negative feedbacks that me and my editor we want to get rid off.

This book is my first real book and of course it was my first experience on writing a book (for this reason we kept the price of the book very low). Anyway .. I got some bad feedbacks about missing parts, parts not explained as expected and a misunderstanding of the book audience and target.

I personally believe that the biggest problem is in the title of book, it drives you a little bit out of the topic of the book, if you buy this book you will believe to get the “bible to LOB applications with MVVM”, which is not.

For this reasons and also to keep high the audience of the book, we have decided to deliver for free new additional content for the book!

The list of the new content is still under discussion with my editor but this is a rough list of the topics I will touch or expand in this new context that should be composed by 3 additional chapters!

• Design patterns
  I am planning to add 20/30 additional pages on the second chapter in order to exhaustively cover everything related to the most known design patterns
• Advanced MVVM
  I will add a new chapter where I will explain some “well known” problems you may find when the adoption of the MVVM pattern starts to get tricky!
• Composite Frameworks for MVVM in practice
  In this chapter we will build the same Master-Detail UI logic using the three most famous frameworks for WPF/Silverlight: PRISM, Caliburn and Light Toolkit

If you believe that the book is still missing other information, feel free to send me an e-mail and I will be glad to discuss this with my editor.

Note: Remember also that we are planning to distribute the source code of the book as an Open Source project on Codeplex.com before the end of the year.

Hope this will help!