In my last post I showed the transformation from the generic repository to the unit of work pattern only. I received an interesting question in the comment section.

Looks nice so far. But didn’t you mix up and simplify things a little bit too much here? For me the Repository is the separation of Domain Objects and Persistent Entities. It’s also a separation of the client from the used persistency technology (either NHibernate, EF, SharePoint, ADO.NET, WebService or whatever). As client side calling code, I really don’t care, where and how my data is stored.

Of course the interface of the repository should be expressive enough and not generic as this was mentioned many times by you and the different contributors.

But why do you mix together the Repository with the UnitOfWork and the transaction handling? Is it something NHibernate specific? Did I miss your point?

I want to clarify my point in this blog post.

I don’t think I mixed up a little too much. The implementation I show in the blog post is moving from the repository pattern to the unit of work pattern. The article shows that a repository is an unneccesary abstraction which can be removed. Let us look into the formal definition of repositories and unit of work:

“A REPOSITORY represents all objects of a certain type as a conceptual set (usually emulated). It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the REPOSITORY inserts them or deletes them from the database. This definition gathers a cohesive set of responsibilities for providing access to the roots of AGGREGATES from early life cycle through the end.”
[...]
“Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.”
- Domain Driven Design: Tackling complexity in the heart of the software -

and the unit of work

“When you’re pulling data in and out of a database, it’s important to keep track of what you’ve changed; otherwise, that data won’t be written back into the database. Similarly you have to insert new objects you create and remove any objects you delete.”
[...]
“A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you’re done, it figures out everything that needs to be done to alter the database as a result of your work.”
- Patterns of Enterprise Application Architecture -

As we see the two definitions closely relate to each other. The repository does not only offer querying capabilities but also allows to add and remove entities. But Repositories itself should not commit operations on the database. That is the responsibility of the unit of work. But the unit of work itself has to keep track of changes (add, removes and updates). Even querying requires the usage of an explicit business transaction (aka unit of work scope), not having an explicit transaction can result in implicit (and autocommiting transactions, see (1)). Therefore for querying we should also wrap these in a unit of work scope. I always prefer being explicit about my unit of work boundaries.

So what I did in the end is: I moved the add, remove and update responsibility solely to the unit of work (as it has to keep track of changes anyway). When you do that all what is left on the repository is the querying capability. Querying also needs explicit unit of work boundaries (business scope) and this can also be moved to the unit of work. Hope that helps.

(1)
NHibernate: “When we don’t define our own transactions, it falls back into implicit transaction mode, where every statement to the database runs in its own transaction, resulting in a large performance cost (database time to build and tear down transactions), and reduced consistency.”
http://nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions
EF: “When performing a SaveChanges operation, the Entity Framework implicitly wraps all of the commands in a database transaction; however, you can take control of transactions as well.”
http://msdn.microsoft.com/en-us/library/orm-9780596520281-01-16.aspx

There are a lot of discussions going on about the repository pattern. I also started one at the last usergroup meeting together with Julie Lerman. Generally the generic repository is considered an anti pattern as stated by Greg Young, he offers a solution by applying a composition pattern to maximize code reuse. Mike from SapiensWork even calls it a complete anti pattern. Ayende calls it since a long time the new singleton. Ayende also suggests in his older articles to either use directly NHibernate’s ISession or RavenDB’s IDocumentSession. Complex queries should be placed into query objects according to his article. So do we really need a repository? This article tries to answer this question.

Let us look into how a generic repository would look like.

interface IRepository<T> {
IEnumerable<T> FindAllBy(IQuery<T> query);
void Add(T item);
void Delete(T item);
...
}

This approach has the following drawbacks:

• We need to instantiate for each entity a new repository of T
• Like Greg states we are loosing expressivness when we are using FindAllBy(new CustomerByNameQuery(“Daniel”))

What about when we apply Gregs composition approach?

Public class CustomerRepository {
    private Repository<Customer> internalGenericRepository;
    Public IEnumerable<Customer> GetCustomersWithFirstNameOf(string name) {
         internalGenericRepository.FindAllBy(new CustomerFirstNameOfQuery(name));
    }
}

This would be a bit more expressiv because we have meaningful methods which describe what actually is done instead of FindAllBy(new QueryObject(…)). But still there is one major drawback:

• We need to instantiate a concrete class for each entity type we want to fetch data from.

Let us try even another approach. What about that repository:

interface IRepository {
IEnumerable<T> FindAllBy<T>(IQuery<T> query)
 where T : Entity;
…
}

We suddenly don’t need to instantiate a repository for each entity. We can fetch data from multiple entities with the same repository instance. But still it has a drawback:

• It is missing expressivness

How could we overcome this issue? There is actually a solution with extension methods. We can use extension methods to cover the query objects behind the scenes and give this approach more expressivness.

public static class CustomerRepositoryExtensions {
   public static IEnumerable<Customer> GetCustomersWithFirstNameOf(this IRepository repository, string name) {
      return repository.FindAllBy(new CustomerFirstNameOfQuery(name))
   }
}

Now we can have the following:

public class Foo {
   public Foo(IRepository repository) {
      this.repository = repository;
   }
   public void Bar() {
      var customers = this.repository.GetCustomersWithFirstNameOf("daniel");
   }
}

That looks kinda nice. It is easy to test. We don’t need a real database for the Foo class. But stop! What about transaction management and where is the session in case of NHibernate or something similar? In case of NHibernate we can directly use ISessionFactory.GetCurrentSession() to get the current session and then start a transaction.

public class Foo {
   public Foo(ISessionFactory sessionFactory, IRepository repository) {
      this.sessionFactory = sessionFactory;
      this.repository = repository;
   }
   private ISession Session {
      get { return this.sessionFactory.GetCurrentSession(); }
   }
   public void Bar() {
      using(var tx = this.Session.BeginTransaction()) {
         var customers = this.repository.GetCustomersWithFirstNameOf("daniel");
         // modify customers
         tx.Commit();
      }
   }
}

Suddenly we have NHibernate not only in the query objects and the repository implementation (someone needs to pass the current session of the call scope into the query) but also on the business logic. And also we have two dependencies which need to be injected in every class which needs database access. We can solve the first problem with an easy adapter for the session and the transaction which even allows nested scopes:

    public class UnitOfWork : IUnitOfWork
    {
        private readonly Func<IUnitOfWorkScope> rootScopeFactory;
        private readonly Func<IUnitOfWorkScope> dependentScopeFactory;
        public UnitOfWork(ISessionFactory sessionFactory, Func<IUnitOfWorkScope> rootScopeFactory, Func<IUnitOfWorkScope> dependentScopeFactory)
        {
			this.sessionFactory = sessionFactory;
            this.rootScopeFactory = rootScopeFactory;
            this.dependentScopeFactory = dependentScopeFactory;
        }
        public IUnitOfWorkScope Start()
        {
            IUnitOfWorkScope scope = !CurrentSessionContext.HasBind(this.sessionFactory)
                                         ? this.rootScopeFactory()
                                         : this.dependentScopeFactory();
            scope.Begin();
            return scope;
        }
    }
	public class UnitOfWorkScope : IUnitOfWorkScope
    {
        public UnitOfWorkRootScope(ISessionFactory sessionFactory)
        {
			this.SessionFactory = sessionFactory;
        }
        protected ISessionFactory SessionFactory { get; private set; }
        protected ISession Session
        {
            get { return this.SessionFactory.GetCurrentSession(); }
        }
        protected ITransaction Transaction
        {
            get { return this.Session.Transaction; }
        }
        public virtual void Begin()
        {
            if (!this.Session.Transaction.IsActive)
            {
                this.isTransactionCreated = true;
                this.Session.BeginTransaction();
            }
        }
        public virtual void Commit()
        {
            this.isScopeCompleted = true;
            if (this.isTransactionCreated)
            {
                this.Transaction.Commit();
            }
        }
        public virtual void Rollback()
        {
            this.isScopeCompleted = true;
            this.Transaction.Rollback();
        }
        public void Dispose()
        {
            this.Dispose(true);
            GC.SuppressFinalize(this);
        }
        protected virtual void Dispose(bool disposing)
        {
            if (disposing)
            {
                if (!this.isScopeCompleted && this.Transaction.IsActive)
                {
                    this.Rollback();
                }
                if (this.isTransactionCreated)
                {
                    this.Transaction.Dispose();
                }
            }
        }
    }
	public class UnitOfWorkRootScope : UnitOfWorkScope
    {
        public UnitOfWorkRootScope(ISessionFactory sessionFactory)
            : base(sessionFactory)
        {
        }
        public override void Begin()
        {
            ISession session = this.SessionFactory.OpenSession();
            CurrentSessionContext.Bind(session);
            base.Begin();
        }
        protected override void Dispose(bool disposing)
        {
            base.Dispose(disposing);
            if (disposing)
            {
                ISession session = CurrentSessionContext.Unbind(this.SessionFactory);
                session.Close();
                session.Dispose();
            }
        }
    }

Let’s revisit our Foo class, shall we?

public class Foo {
   public Foo(IUnitOfWork uow, IRepository repository) {
      this.uow = uow;
      this.repository = repository;
   }
   public void Bar() {
      using(IUnitOfWorkScope scope = this.uow.Start()) {
         var customers = this.repository.GetCustomersWithFirstNameOf("daniel");
         // modify customers, other class could att
         scope.Commit();
      }
   }
}

Nice we gained a little bit of abstraction in our business code regarding the persistency layer but we still have two dependencies in our Foo class. But do we really need the repository abstraction? NHibernate’s ISession is itself an unit of work. So why don’t we just move these few members onto the scope?

    public interface IUnitOfWorkScope : IDisposable
    {
        void Begin();
        void Commit();
        void Rollback();
	IEnumerable<T> FindAllBy<T>(IQuery<T> query)
          where T : Entity;
        ...
    }

We can even move away the generic restriction which would then allow to use projections in the query too. This simplifies Foo to the following implemention (still using the extension method approach but this time on IUnitOfWorkScope).

public class Foo {
   public Foo(IUnitOfWork uow) {
      this.uow = uow;
   }
   public void Bar() {
      using(IUnitOfWorkScope scope = this.uow.Start()) {
         var customers = scope.GetCustomersWithFirstNameOf("daniel");
         // modify customers, other class could att
         scope.Commit();
      }
   }
}

Isn’t that nice? No need for repositories. Unit testable. Simple and small abstraction. All persistency related stuff in either in the query or in the unit of work implementation and only there we need tests which either go to the database or use InMemory databases. But there is still one caveat regarding testability. Can you spot it?

Since I started using and working on Ninject I have never seen a good use case for Activations Blocks like they are implemented at the moment. That’s why I’m currently planning on changing their behavior to give them more sense. This blog post will explain what I have in mind at the moment.

Current usage and behavior (Ninject 3.0.0)

Ninject V3.0.0 provides kernel.CreateBlock() which returns a IResolutionRoot. Within this resolution root every type exists exactly once as a local singleton object no matter which scope is defined for the binding.

In my opinion this behavior makes no sense. There are situations where you want to have exactly one instance of a service in the application. Activations Blocks do not allow to use these services because exactly one instance of each dependency is created within the activation block. Instead of sharing the instance between multiple activation blocks a new one is created for each activation block.

Purpose of activation blocks

The second problem of activation blocks is the way they are used. In order to create one you have call the CreateBlock method on the kernel. This has two disadvantages:

1. To create an activation block you need to know the kernel which gives you a dependency on Ninject.
2. You will get an IResolutionRoot on which you can resolve any type of dependency which means you are using Ninject like a kind of service locator.

Because of these problems the activation block shouldn’t be used within applications. We can achieve the same behavior without having these problems with named scopes. How this is done is explained in the next chapter.

But there is situations where activation blocks are helpful. There are frameworks e.g. ASP.NET WebAPI and NServiceBus that have the concept to create a scope around a request. While integration into these types of frameworks using named scopes is possible it is much simpler to do so with an activation block. But the current implementation of the activation block where everything is a singleton object within the block is not correct an needs to be changed as described in the last part of this article.

Creating an activation block using a Named Scope

As already explained using activation blocks within an application has two disadvantages. You can get the same behavior using named scopes and factories.

Instead of creating a new block you pass a factory to the component that is responsible to start the activation block and use it whenever a new activation block is required. E.g. pass a IMyTcpRequestHandlerFactory to the IMyTcpServer class and whenever a new connection is established this factory is used to create a new IMyTcpRequestHandler.

The second step is to configure that this newly created component is the scope for other components it is depending on using a named scope and assign this scope to the dependencies:

public class MyTcpRequestHandler : IMyTcpRequestHandler
{
    public MyTcpRequestHandler(ISomeDependency someDependency) {}

    ....
}

const string TcpRequestScope = "TcpRequestScope";
Bind<IMyTcpRequestHandlerFactory>().ToFactory();
Bind<IMyTcpRequestHandler>().To<MyTcpRequestHandler>().DefinesNamedScope(TcpRequestScope);
Bind<ISomeDependency>().To<SomeDependency>().InNamedScope(TcpRequestScope);

In case you need to create multiple dependencies depending on some runtime conditions you can pass other factories to this component and use them to create them. But in this case you will have to load the Ninject.Extensions.ContextPreservation extension together with the named scope extension.

How activation blocks will behave in future

public class MyTcpRequestHandler : IMyTcpRequestHandler
{
    public MyTcpRequestHandler(IProcessingStrategyFactory processingStrategyFactory, ...) {}

    public void HandleRequest()
    {
        var contentType = this.GetTcpContentType();
        var processingStrategy = contentType.IsXml
            ? this.processingStrategyFactory.CreateXmlProcessingStrategy();
            : this.processingStrategyFactory.CreateBinaryProcessingStrategy();

        ....
    }
}

const string TcpRequestScope = "TcpRequestScope";
Bind<IMyTcpRequestHandlerFactory>().ToFactory();
Bind<IProcessingStrategyFactory>().ToFactory();
Bind<IMyTcpRequestHandler>().To<MyTcpRequestHandler>().DefinesNamedScope(TcpRequestScope);
Bind<IProcessingStrategy>().To<XmlProcessingStrategy>().InNamedScope(TcpRequestScope);
Bind<IProcessingStrategy>().To<BinaryProcessingStrategy>().InNamedScope(TcpRequestScope);

Changes to the current activation block

I’m currently planning to add a new scope InActivationBlockScope to Ninject. Only bindings with this scope type will be affected by the activation block. Within an activation block they will be local singleton objects. Exactly one instance will be created within the activation block and they will be disposed together with the activation block. Outside of an activation block they will behave like transient objets. All other scopes will behave exactly the same way within and outside of activation blocks.

With this change it will be possible to use the existing scopes within an activation block while having the possibility to scope some objects by an activation block. This will make it easy to use Ninject together with Frameworks like ASP.NET WebAPI and NServiceBus.

Currently, this change is still a proposal. Feedback is very welcome.

For a project we use some SunRay 3 Plus terminal with the Sun Oracle VDI server. After all I only can say this thin client solution rock!!! But in the project time we hade to debug a problem. The problem was some Sun Ray Clients did unexpected reboots every 2 till 5 minutes. And it comes even stranger, next day the Terminal works without any problem and another terminal reboots. After some vi action we found the following error in the Log of the vdi server.

TIME SERVERNAME utauthd: [ID 197738 user.info] Worker5 UNEXPECTED: during send to: java.net.SocketOutputStream@94c924 error=java.net.SocketException: Broken pipe

After searching the error in the net, we don’t get any step forward. next thing we did analyze the thin client traffic with wire shark. 30 seconds before the Terminal reboots there are many tcp retransmits on the network.

It was “to milk mousses”* after some searching (x>2 Day’s) we find out that the arp Table on the switch with the SunRay attached flips a mac address.

With this additional input it takes 20 seconds and we get the brake trough idea. The problem was a simple IP conflict with a old Printer. So if you ever get this problem don’t waste 3 Day’s of your live.

Regards Konrad

*milk mouse is some German saying for we are working very hard but don’t get any step near the Target.

These are the slides with comments of my conference talk at MedConf 2012 in Lucerne:

Software development without using open source software (OSS) is unthinkable in today’s world. This holds also for medical technical projects.

This presentation is split into three parts. First we take a look at some myths and facts about open source software. Then at how to integrate an OSS into your project so it can be validated against regulatory requirements. And finally, we’ll see what is important when selecting open source software.

During my career as a software engineer, I got used to use open source software a lot.

But when I started in my very first medical technical project, I was confronted with strong opinions about open source software.

I was told that they don’t meet the quality needs. It was unthinkable to use some sloppy written code of someone who has nothing better to do in his spare time than coding.

And that it would be insane to rely on a piece of software for which there was no commercial support. Overall, using open source software would just be far too risky.

Okay, I said, but let’s take a look at some facts.

First, we need to take a look at what kinds of software we actually have in our project.

There is the code we wrote ourselves. Then there is the code we bought – typically as closed source. And there is open source code.

There are even some mixtures of these kinds. For example there are commercial libraries, which offer you the source code, too. Or there are open source projects that offer commercial support. But for simplicity, let’s use these three types of source code.

Now, let’s take a look at the myth that the quality of open source software is not as good as the quality of our own code or of commercial libraries.

The question here is: What does actually influence quality?

The main driver for quality is …

… feedback.

The more feedback a projects gets about defects and its usability the better its quality gets.

But this is a big problem for the code we wrote ourselves. There is much less feedback than commercial or open source projects get. Simply due to the fact, that they are used in more projects, by more developers and users.

Domain know-how of the developers is another big influence on the quality. Only when the developers know what they are building, quality can get really high.

Obviously, our own team cannot know everything. So there are aspects in our software where we lack domain know-how. Or does your team know how to write a scheduling component for example?

That means, that the quality of commercial or open source software in special areas is much higher than when built by ourselves. Commercial and open source projects focus on a single topic and therefore gain domain know-how on this single topic.

Transparency helps to assess quality. When you can look at the code, or see how many defects are in the defect tracking system, you can decide for yourself whether a library or product is good enough for you.

Most commercial products don’t give you access to the source code or the defect tracking system. Therefore, they are a black box and hard to assess.

In open source software, as in your own code, you have full access. You can run some quality metrics against the code and check how many open defects lie around in the defect tracking system and how long it normally takes the team to fix a defect.

Finally, quality is a result of motivated teams and innovative solutions.

People working in open source projects are likely highly motivated. They spend their spare time!

The people involved in your team or from the company you buy software from may be a bit less motivated.

The coverity scan (http://scan.coverity.com/) of the year 2011 states that “Open source quality for active projects in Coverity Scan is better than the software industry average.“

To sum up, if you are looking for quality in your software, try not to implement it yourself.

Another myth is that you don’t get any guarantees with open source software.

So what happens if you need help with a defect? You probably don’t get a support contract.

It’s like with your own code. There, you have to support yourself.

With commercial products, you can rely on the support. But far too often, support is slow, and you’ll have to wait for the next release for your problem to be fixed.

With open source software you get the best of both worlds. Either you can take measures on your own and fix the defect yourself, or rely on the project team and the community to fix the problem for you.

Although you don’t have a contract in hand, open source software gives you flexibility to act on your own, or wait for the project to take care of defects. The latter is in most cases the cheaper variant.

An analysis of the Food and Drug Administration shows that from the recalled medical devices between 1992 and 1998, 7.7% were caused by software failures.

79% of these software related recalls were caused by software defects that were introduced when changes were made to the software after its initial production and distribution.

Therefore, if you are looking for quality, externalize maintenance and profit from the feedback of everyone else using the software.

When using open source software in your projects, there are other things you need to consider, too.

The license of the open source software you want to use can have a big influence on how you have to distribute your software.

If you for example use a GPL license, all derived work has to be published under GPL, too. Therefore, avoid GPL open source software if you want to build commercial software.

On the other side, projects licensed under Apache 2.0 require you only to include the license and information from where you have the code, somewhere in the installation.

Unfortunately, there are a lot of different licenses. You may need a lawyer to make sure that you don’t run into any problems with some of these.

Another aspect you have to be aware of is copy right and patent violation.

In your own code, it’s up to you to make sure that the developers don’t violate any patents or copy rights.

This also applies to most open source projects. But there are foundations that take care of these questions, like the Eclipse and Apache Foundation.

And if you use open source software that is used by a wide variety of other companies, it’s unlikely that someone will succeed with a patent lawsuit.

Regarding risk management, writing your own code, buying a commercial product and using open source software have all their advantages and disadvantages.

Regarding legal aspects, commercial products are best for you (they would have a problem and not you). Open source software has a bit less risk than writing your own code because of the foundations we have seen before helping to mitigate these risks. And you are probably not alone.

The risk of bad quality is highest for your own code. Mainly because of the lack of feedback compared to commercial and open source software. Commercial products and open source software with bad quality likely won’t survive very long.

There is always the risk that the product you use is no longer maintained. This is more likely in open source projects. But at least, you have the source code and could continue using it. If a commercial product is dead, your only option is to leave it. There is also an end of life in your own code. If know-how about your code is sparsely distributed in your team, a team member leaving could have the same effect.

Open source software could get commercial. However this happens quite rarely and you could still continue to use the latest open version of the product. Or of course, buy the new version. Obviously, the risk of getting commercial has already occurred for commercial products.

Implementing your own code is for sure the most expensive variant if there are commercial or open source products available that solve the same problem. Therefore, the financial risk is highest for your own code. The financial risk is lowest for open source software because you get the software for free. However, it still costs to integrate and learn an open source software.

The risk that the solution you built or bought is only a short-living solution is highest for your own code. That’s because of less feedback compared to commercial or open source software. A short-lived solution forces you to invest effort soon because it does not support future development.

Finally, there is the risk that the roadmap or release cycle of the product you chose does not match your needs in the future. Open source software gives you however the possibility to act on your own and adapt the source code yourself. This can be very important regarding your own deployment cycles.

Overall, open source software is a strong choice regarding risks. Especially, if financial aspects have a heavy weight for you.

Looking back at my first medical technical project, once we convinced the developers and project leaders that open source software can save us a lot of money and trouble, the guys from the regulatory department stepped in.

They said that they don’t want any open source software, how should this software be validated?

The most important point is that you take the source code of the open source project and add it to the source control system where your own code lives.

This is the only way you will know in the future, which version of the open source software was used in which of your releases. And maybe the open source project dies and you cannot download the sources anymore.

Furthermore, you will have to maintain your software probably for a long time. This can be a problem with commercial products. Maybe the product does not support the latest operating system anymore. With open source software, you can adapt the code yourself as a last resort.

Regarding validation, it can be a great advantage that you can fix defects yourself. You could do this in a way so that only a minimum of code is changed and therefore minimizing validation effort needed.

It’s very unlikely that you get support for validation from the open source project.

To validate the open source software, you should treat it just like your own code. Do whatever you do with your own code to get it validated.

The advantage of open source software is that it is not a black box to you.

You can review the code and if the open source software contains unit or acceptance tests, you can use them, too.

Additionally, you could even include the source code when submitting your project for validation.

When using open source software, make sure that you use an …

… up-to-date version.

Documentation and help from the community is normally only available for up-to-date versions.

And you can only profit from externalized maintenance if you update regularly.

Good open source projects provide you with tutorials how to upgrade from one version to the next. Therefore you shouldn’t be behind more than one version.

Looking back at my first medical technical project, it took some time to get support from all involved parties. But finally, open source software could be used in great variety.

But there is still one problem to solve:

How to find the right open source software.

First of all, the open source software should solve a problem of yours. But that is not enough.

You should check whether the project has a road map so that you can decide whether the project runs in the right direction. Take a look at news, releases, commit and the number of committers to see whether the project is alive. Check whether there is an issue tracker and how many defects are in there. And whether these defects get fixed in a reasonable amount of time.

Technically, you should check whether you can build the sources so you could fix defects yourself. Check whether there are unit and acceptance tests and whether the code style suits you.

And very important, check if there are any external dependencies and if they meet your requirements.

In order to get you up to speed quickly, take a look at the…

… documentation. Are there a wiki, web page and samples. Are they up-to-date? Do you find success stories of other people using this software?

Is there a community that supports the OSS. Is there a forum? Are questions answered? In a reasonable time frame?

It takes quite a lot of time to get a picture of an open source software. But it will save you lots of problems when done thoroughly.

To sum everything up, I’d like you to think about …

… whether open source software could help you in your projects to get better quality, less maintenance or to finish your project earlier before beginning to write your own code.

And if you use open source software …

… please provide feedback.

Links

FDA guideance (validation of 3rd party software)

Coverty scan (OSS quality)

How to select open source libraries (Daniel Marbach)

In my last post I described the problem domain behind client / server localization. In this post I’m going to tackle how dynamic translation can be achieved in a client / server environment. The basic idea is to use compiled resources from the server side and transport it over the wire to the client. When talking about “resources” we want to use a mechanism which is really close to the way localization generally works under .NET. To understand this we need to have a look into the resource manager.

The .NET Resource manager under System.Resources has the following responsibilities:

• It looks up culture-specific resources
• Provides resource fallbacks when a localized resource does not exists
• Supports resource serialization

The ResourceManager can either retrieve resources from binary resource (.resources) files laying on the disk or from resource files which are embedded in an so called satellite assembly. Satellite assemblies are special assemblies (they only contain resources) which are compiled and deployed together with the corresponding main assembly but can be individually versioned. Usually you have one satellite assembly per language you support in your application. Using satellite assemblies for dynamic client / server localization doesn’t make sense because the client doesn’t use the same deployment units (aka assemblies) as the server application. Luckily the ResourceManager allows use to declare file based resource managers from binary resource files by using the static method CreateFileBasedResourceManager. This declares a ResourceManager which doesn’t depend on any particular assembly.

Binary resource files must follow a certain convention. Each binary resource file must have a basename. For example we could define a basename “MyResources”. In this case the default resource file on the disk must be called “MyResources.resources”. The language dependent resource files must be called “MyResources.[de/fr-Be..].resources”. So imagine we have the following resource structure on the server side:

someserverpath/MyResources.resources
someserverpath/MyResources.de.resources
someserverpath/MyResources.de-ch.resources
...

The only thing we have to do to start with dynamic localization is we need to somehow transfer all the *.resources files from the server to the client. The client needs to place all the downloaded files into a similar structure as found on the server, for example:

someclientpath/MyResources.resources
someclientpath/MyResources.de.resources
someclientpath/MyResources.de-ch.resources
...

After we have downloaded and placed all *.resources files on the client side we need to instantiate a resource manager for each basename. In the example above this can be achieved with the following line of code:

var myResourcesRM = ResourceManager.CreateFileBasedResourceManager("MyResources", "someclientpath/");

As soon as we want to translate something on the client we only need to call

myResourcesRM.GetString("resourcekey")

So far so good. In the next post I’m going to show how we can get resources from the server to the client and how to handle multiple resource managers and basenames. Stay tuned.

Imagine you need to code the following requirements:

• When an exception is thrown the transaction must be rolled back
• The thrown exception must be rethrown

The productive code could look like:

public class SomeComponent
{
   public void Do() {
      ITransaction tx = this.session.BeginTransaction();
      try {
      this.session.Save(foo);
      } catch(DataException e) {
         tx.Rollback();
         throw;
      }
   }
}

Now how would you write the requirements above in two separate unit tests? Here comes FluentAssertions into the play.

We just write a little extension method which ignores a specific kind of exception type and hook it up just after the fluent assertions extension method “Invoking”.

    public static class CustomAssertionExtensions
    {
        public static void IgnoreAnyExceptions<TException>(this Action action)
            where TException : Exception
        {
            try
            {
                action();
            }
            catch(TException)
            {
            }
        }
    }

And here the test code which uses it.

    [TestFixture]
    public class SomeComponentTest
    {
        private ITransaction transaction;
        private ISession session;
        private SomeComponent testee;

        [SetUp]
        public void SetUp()
        {
            this.transaction = A.Fake<ITransaction>();
            this.session = A.Fake<ISession>();
            this.SetupSessionReturnsTransaction();

            this.testee = new SomeComponent(this.session);
        }

        [Test]
        public void WhenExceptionOccurs_ShouldRollbackTransaction()
        {
            A.CallTo(() => this.session.Save(A<object>.Ignored)).Throws(new DataException());

            this.testee.Invoking(t => t.Execute()).IgnoreAnyExceptions<DataException>();

            A.CallTo(() => this.transaction.Rollback()).MustHaveHappened();
        }

        [Test]
        public void WhenExceptionOccurs_ShouldRethrow()
        {
            A.CallTo(() => this.session.Save(A<object>.Ignored)).Throws(new DataException());

            this.testee.Invoking(t => t.Execute()).ShouldThrow<DataException>();
        }

        private void SetupSessionReturnsTransaction()
        {
            A.CallTo(() => this.session.BeginTransaction()).Returns(this.transaction);
        }
    }

Hope this helps. I suggest you check out fluent assertions! Have fun. By the way the example was written using FakeItEasy. Be sure to check it out too!

If you are familiar with hamcrest and JUnit the time will come when you have
the need to create your own matchers.
Creating your own matcher can be as simple as useful. One reason for
creating your own matcher could be that your object is not a default object
like a String or a Collection. And if you would like to get a more readable
version of the assert for the next developer who has to read your
test. Let’s make an example. If you have an object with two methods;
“getName” and “getNumber” and you would like to check whether the resulting object
has the correct values.
In my opinion the best way to verify this is to create two matchers and
combine them. Before we can combine these two matchers let’s see how to
create them.
For our examples we will test an instance of the following class:

public class Foo {
   public String getName() {
      return "Foo";
   }

   public int getNumber() {
      return 41;
   }
}

If you have a look at the Matcher interface you will see some hints
which tell you not to implement the Matcher itself. So have a look at
BaseMatcher which is referred to in the Matcher interface.

Let’s check if the number is 42 and the name is “Bar”. The samples show
possible solutions without every time creating its own class files. I just
write a small factory method instead of creating a matcher class. This
will be the first step while coding your test/matcher. If you see the
matcher can be used somewhere else, it should be very easy to create an
own class. It would also be helpful to create a factory class which
will centralize your matchers.

Using BaseMatcher

If we use BaseMatcher we will recognize that we have to implement the
following two methods:

• public boolean matches(Object item) : here we will do the check.
  The item will be our object under test (Should be an instance of
  Foo).
• public void describeTo(Description description) : here we will
  have to return a description of our matcher. This will simplify our
  life if there are failures.

Now let’s see how the implementation of a BaseMatcher could look like for
checking the value of getNumber().

private Matcher<Foo> hasNumber(final int i) {
   return new BaseMatcher<Foo>() {
      @Override
      public boolean matches(final Object item) {
         final Foo foo = (Foo) item;
         return i == foo.getNumber();
      }
      @Override
      public void describeTo(final Description description) {
         description.appendText("getNumber should return ").appendValue(i);
      }
   };
}

And the usage would look like this:

@Test
public void numberIs42() {
   final Foo testee = new Foo();
   assertThat(testee, hasNumber(42));
}

This results in a failing test. All right we want a failing test
otherwise we could not have a look at the features of our new matcher
since this will only be apparent while the test is failing
So the test will give us this output:

java.lang.AssertionError: Expected: (getNumber should return <42>) got: <ch.adrianelsener.MatcherSampleTest$Foo@136070f0> 

You will agree with me that this is not very useful. But it is a good
demonstration why to do a failing test first, to demonstrate what can happen when
the test fails, otherwise you might never have noticed that there is room for
improvement.
There are two possible solutions to get a more powerful message:

• Implementing toString on Foo would be one of them but not what we want.
• Implement the method “public void describeMismatch(final
  Object item, final Description description)“ in our
  matcher

If we add “describeMismatch”, our matcher would now look like this:

private Matcher<Foo> hasNumber(final int i) {
   return new BaseMatcher<Foo>() {
      @Override
      public boolean matches(final Object item) {
         final Foo foo = (Foo) item;
         return i == foo.getNumber();
      }
      @Override
      public void describeTo(final Description description) {
         description.appendText("getNumber should return ").appendValue(i);
      }
      @Override
      public void describeMismatch(final Object item, final
Description description) {
         description.appendText("was").appendValue(((Foo) item).getNumber());
     }
   };
}

Now the result of the failing test tells us:

Expected: getNumber should return <42> but: was<41> 

This will work great, but you will have to do casts all the time even hough you
define the type of the object to test in the signature. To
solve this you can use the TypsafeMatcher.

TypesafeMatcher

This matcher is almost identical to BaseMatcher. Almost The
differences are:

• protected boolean matchesSafely(final T item)
• protected void describeMismatchSafely(final T item, final
  Description mismatchDescription)

Now the item already is of the known type and it is verified by
TypesafeMatcher to be what it should be. If you use the assertThat
method it would change nothing, since there are generics to define
what you can match and what not but the casts are no longer necessary.
Our sample matcher will change into something like this:

private Matcher<Foo> hasNumber(final int i) {
   return new TypeSafeMatcher<Foo>() {
      @Override
      public void describeTo(final Description description) {
         description.appendText("getNumber should return ").appendValue(i);
      }

      @Override
      protected void describeMismatchSafely(final Foo item, final
Description mismatchDescription) {
         mismatchDescription.appendText(" was ").appendValue(item.getNumber());
      }

      @Override
      protected boolean matchesSafely(final Foo item) {
         return i == item.getNumber();
      }
   };
}

If you let the test run you will see the same result as with the
matcher extended from BaseMatcher. But we don’t have to cast the
object all the time. Now you’ll ask what will the
TypesafeDiagnosingMatcher bring more. Let’s have a look.

TypesafeDiagnosingMatcher

With the TypesafeDiagnosingMatcher you only have to implement two
methods. These are:

• public void describeTo(final Description description) : This
  has still the same function: Describe what the matcher is doing
• protected boolean matchesSafely(final T item, final Description
  mismatchDescription) : Here we do the check AND the
  error description.

So we change the creation of our matcher to the following:

private Matcher<Foo> hasNumber(final int i) {
   return new TypeSafeDiagnosingMatcher<Foo>() {
      @Override
      public void describeTo(final Description description) {
         description.appendText("getNumber should return ").appendValue(i);
      }

      @Override
      protected boolean matchesSafely(final Foo item, final
Description mismatchDescription) {
         mismatchDescription.appendText(" was ").appendValue(item.getNumber());
         return i == item.getNumber();
      }
   };
}

There is one point you have to keep in mind. If the match fails, the method
matchesSafely will be called at least twice. This is because the
method will be called to do the match AND to write
the failure message.

FeatureMatcher

There is one abstract matcher which will be very easy to use for our
problem. When implementing FeatureMatcher we just have to implement
“protected abstract U featureValueOf(T actual);” (T will be our item
and U the type that has to be checked) and all the rest will be done
by FeatureMatcher. No more failuretext no more description. Nice,
isn’t it?
Here how our matcher looks like after implementing it with FeatureMatcher:

private Matcher<Foo> hasNumberFeatureMatcher(final Integer i) {
   return new FeatureMatcher<Foo, Integer>(equalTo(i), "number", "number") {
      @Override
      protected Integer featureValueOf(final Foo actual) {
         return actual.getNumber();
      }
   };
}

After executing we will have this StackTrace:

java.lang.AssertionError: Expected: number <42> but: number was <41> 

As you see, we have to change something. The FeatureMatcher is
designed to return a value (feature) of an object. Because of this we
have something special in the constructor. Have you seen it? Yes,
the equalTo matcher. This is because the feature matcher is
designed to take an other matcher. So it would also be possible to
compare with lessThan/greaterThan etc. Nice isn’t it?

Combining two matchers

Now let’s do the rest. Our goal was to compare two getters. To do this
the CombinableMatcher will be helpful. Just have a look at Matchers
and you will find the following way to combine two matchers:
“Matchers.both(MatcherA).and(MatcherB)”. In my opinion this is a very
readable way to combine two matchers. But there is one problem with
it: The message will not be as good as it should. If we let this run

assertThat(testee, both(hasName("Foo")).and(hasNumber(42)));

we will se something like this:

java.lang.AssertionError: Expected: (getName should return "Foo" and getNumber should return <42>) but: was <ch.adrianelsener.Foo@2484e723> 

if we do not implement toString on our result we can’t really get
enough information to get a conclusion what happend. Here I would do a
little manual work.

class MyCombinableMatcher<T> extends BaseMatcher<T> {
   private final List<Matcher<? super T> matchers = new ArrayList<>();
   private final List<Matcher<? super T> failed = new ArrayList<>();

   private MyCombinableMatcher(final Matcher matcher) {
      matchers.add(matcher);
   }

   public MyCombinableMatcher and(final Matcher matcher) {
      matchers.add(matcher);
      return this;
   }

   @Override
   public boolean matches(final Object item) {
      for (final Matcher<? super T> matcher : matchers) {
         if (!matcher.matches(item)) {
            failed.add(matcher);
            return false;
         }
      }
      return true;
   }

   @Override
   public void describeTo(final Description description) {
      description.appendList("(", " " + "and" + " ", ")", matchers);
   }

   @Override
   public void describeMismatch(final Object item, final Description
description) {
      for (final Matcher<? super T> matcher : failed) {
         description.appendDescriptionOf(matcher).appendText(" but ");
         matcher.describeMismatch(item, description);
      }
   }

   public static <LHS> MyCombinableMatcher<LHS> all(final Matcher<? super LHS> matcher) {
      return new MyCombinableMatcher<LHS>(matcher);
   }
}

If we now execute this line:

assertThat(testee, all(hasNameTypesafeMatcher("Bar")).and(hasNumber(42)));

java.lang.AssertionError: Expected: (getName should return "Foo" and getNumber should return <42>) but: getName should return "Foo" but was "Bar" getNumber should return <42> but was <41> 

assertThat or assertThat ?

If you see just something like this

java.lang.AssertionError: Expected: (getName should return "Foo" and getNumber should return <42>) got: <ch.adrianelsener.Foo@21a79b48> 

Then it might be because you have used the assertThat from JUnit and not the one
from hamcrest. This is because JUnit delivers an assertThat to get
small support for hamcrest. But it does not use all of the “new” features
of hamcrest. They deliver an old implementation. All you have to
do is use MatcherAssert.assertThat within the hamcrest library. It
would be better to get the JUnit jar without hamcrest and replace it
completely by the hamcrest jar itself.

Currently, I have some spare time and wanted to play around with geeky stuff. The guys from sharpcrafters.com provided me a evaluation version of their tool PostSharp. PostSharp is a framework for aspect oriented programming in .NET. In short, aspect oriented programming helps you to remove unnecessary boiler plate code such as logging, transaction handling, exception handling and many more. The boiler plate code I’m talking about is also called cross-cutting concern because it cuts through your whole application. If you want to know more about aspect oriented programming I suggest you follow the links provided in this article. But now let’s dive into PostSharp.

PostSharp comes with a simple installer which installs PostSharp HQ on your machine. Everything is then setup to start using PostSharp. PostSharp HQ is essentially nothing more than a simple browser window which provides you information about your license status and links to documentation and tutorials. When you start VS2010 the first time after the PostSharp installation, a new information area is placed beside your toolbox. The information area provides you with a check list and tutorials which allow you to dive into the features and possibilities of PostSharp.

The basics of PostSharp are really simple. I’m not going to cover the stuff of PostSharp which is already in the tutorials but I’ll provide a detailed list of tutorials at the end of this post.

PostSharp itself is really user friendly. They are trying to provide a maximum amount of information possible at compile time. For example if you forget to mark your aspects as serializable you receive a compile error which points you to the cause of the problem. It is even possible to extend this message based information system with your own compile errors or warnings (look for MessageSource and Message.Write in the documentation).

Another powerful feature is the provided Visual Studio plugin. The plugin visualizes aspects and code which is influenced by aspects. On every recompile new information is available. For example the aspect browser shows aspects which are part of the solution and the affected code for each aspect (first screenshot). The code editor integration of the plugin shows nicely all aspects directly in the editor window. It is even possible to directly jump to the disassembled code with your favorite disassembler (for example ILSpy, DotPeek…).

All the rest should be covered in detail in the tutorials below. Happy PostSharping!

Hints from my side

• If you are using ReSharper I suggest you add some templates to your solution settings which help you write aspects (for example the template should include the serializable attribute)
• Always keep in mind that the application of attributes is undeterministic so there is no guarantee of execution order (PostSharp will also let you know that in the warnings)
• The order of execution can influence the operational behavior of an aspect!
• When possible try to avoid using the AttributePriority to modify the priority when aspects are applied. This can quickly become a huge mess.
• Read the tutorials about aspect scoping multiple times
• If you are using FxCop there is a section in the documentation about FxCop compatibility with PostSharp (haven’t tried it out yet)

Aspect Oriented Programming

• WhitePaper from SharpCrafters 
• Aspect-Oriented Software Development Community & Conference
• AspectJ Documentation
• C2.com Wiki

PostSharp Tutorials

• Documentation
• PostSharp Principles: Day 1 – OnExceptionAspect 
• PostSharp Principles: Day 2 – Applying Aspects with Multicasting Part 1
• PostSharp Principles: Day 3 – Applying Aspects with Multicasting Part 2 
• PostSharp Principles: Day 4 – OnMethodBoundaryAspect
• PostSharp Principles: Day 5 – Visual Studio Add-ins
• PostSharp Principles: Day 6 Your code after PostSharp
• PostSharp Principles: Day 7 Interception Aspects – Part 1
• PostSharp Principles: Day 8 Interception Aspects – Part 2
• PostSharp Principles: Day 9 Aspect Lifetime & Scope Part 1
• PostSharp Principles: Day 10 Aspect Lifetime & Scope Part 2 
• PostSharp Principals: Day 11 – EventInterceptionAspect
• PostSharp Principals: Day 12 – Aspect Providers, Part 1
• PostSharp Principles: Day 13 – Aspect Providers, Part 2
• PostSharp Principals: Day 14 – Introducing Members and Interfaces, Part 1
• PostSharp Principles: Day 15 – Introducing Members and Interfaces, Part 2
• Applying aspects to 3rd party assemblies using PostSharp
• Method Tracing Using log4net and PostSharp (shows also Unit Testing)

Unfortunately, ASP.NET providers like the MembershipProvider and RolesProvider aren’t designed for dependency injection. Many users have problems to assign dependencies to them. In this blog post I’ll show a way to how this can be done using Ninject.Web.Common 3.0.0. This solution works for MVC and WebForms.

The provider itself is created by the ASP.NET framework which adds the restriction that all dependencies have to be passed using property injection because the ASP.NET framework expects a parameter less constructor. So the first thing you have to do is to add a property for all required dependencies to your provider

    public class MyMembershipProvider : SqlMembershipProvider
    {
        [Inject]
        public SpecialUserProvider SpecialUserProvider
        {
            get; set;
        }

        public override bool ValidateUser(string username, string password)
        {
            return this.SpecialUserProvider.IsSpecialUser(username) ||
                   base.ValidateUser(username, password);
        }
    }

As second step you need to create an HttpModule that will get an instance of all your providers. The idea behind this is that the providers are resolved and injected long time before they are used somewhere else. In the following example it is done for the MembershipProvider only. But you can easily extend it to initialize all required providers.

    public class ProviderInitializationHttpModule : IHttpModule
    {
        public ProviderInitializationHttpModule(MembershipProvider membershipProvider)
        {
        }

        public void Init(HttpApplication context)
        {
        }

        public void Dispose()
        {
        }
    }

As last step you need to create the bindings for the http module and the providers.

    kernel.Bind<MembershipProvider>().ToMethod(ctx => Membership.Provider);
    kernel.Bind<IHttpModule>().To<ProviderInitializationHttpModule>();