September 25, 2010

False Positives in Database Integration Tests

You may sometimes find that all your tests pass, but in production your entities cannot be hydrated from the database. Take this example:

@PersistenceContext(unitName="shipmentOrder")
EntityManager entityManager;

@Test
@Transactional
public void maps_correctly_to_and_from_database() throws Exception {

	ShipmentOrder state = new ShipmentOrder();
	state.setCustomerName("CALLERNAME");
	state.getDeliveryAddress().setCountry("NIRVANA");

	entityManager.persist(state);
	entityManager.flush(); // enforce writing to the database

	ShipmentOrder foundState = entityManger.find(ShipmentOrder.class, state.getId());

	assertEquals("CALLERNAME", foundState.getCustomerName());
	assertEquals("NIRVANA", foundState.getDeliveryAddress().getCountry());
}

This test will happily pass, but the same call fails in production. Why?

Below are the entity classes - note, that JPA by default does not allow @Embeddable's to inherit (see e.g. the Hibernate Annotations Reference, section "3.2.4.4. Inherit properties from superclasses" for more details). Even worse, Hibernate does not complain, but silently ignores inherited fields.

@Entity
class ShipmentOrder {
	String customerName;
	@Embedded
	DeliveryAddress deliveryAddress;

	String getCustomerName() { return customerName; }
	DeliveryAddress getDeliveryAddress() { return deliveryAddress; }
}

@Embeddable
class DeliveryAddress extends Address{
	String deliveryLocation;
	String getDeliveryLocation();
}

class Address {
	String country;
	String getCountry();
}

So, why does the test pass then?

The problem is, that while within a transaction, Hibernate reuses objects from the 1st Level cache. This means the our call to "flush()" causes Hibernate to write changes to the database, but the entity instance is still kept in memory. If we execute the find() method, Hibernate simply returns the entity instance from the cache and will never try to hydrate the instance from the database.

Solution

EntityManager.clear() allows to manually purge the 1st level cache. Changing the test to

repository.store(state);
entityManager.flush(); // enforce writing to the database

entityManager.clear(); // purge 1st level cache

state = repository.findById(state.getId());

will successfully catch the mapping error.

Here is a method we use in integration tests to automatically flush+purge all persistence contexts defined in Spring:

protected void flushAndClearPersistenceContexts() {
    Map<String, EntityManagerFactory> entityManagers = this.getApplicationContext().getBeansOfType(EntityManagerFactory.class);
    for(EntityManagerFactory emf:entityManagers.values()) {
        EntityManagerHolder emHolder = (EntityManagerHolder) TransactionSynchronizationManager.getResource(emf);
        if (emHolder != null) {
            final EntityManager entityManager = emHolder.getEntityManager();
            try {
                entityManager.flush();
            } catch (TransactionRequiredException e) {
                // ignore - couldn't find a way to properly check if we are within a transaction
            }
            entityManager.clear();
        }
    }
}

NOTE: never use flush() and clear() in your production code as this seriously kills the performance of hibernate

You can find the sample code reproducing this issue on my git repository.

January 25, 2010

The Danger Of Mislead Solutions: Constructor Over-Injection

Recently Jeffrey Palermo blogged about something he calls "constructor over-injection anti-pattern". This post caused a couple of reactions, in particular Mark Seemann's rebuttal to be mentioned. Mark Seemann already did a nice job arguing against the tight coupling in Jeffrey's proposed solution of (taken from the follow-up)

IOrderShipper shipper = new OrderShipperFactory().GetDefault();

to lazily resolve the IOrderShipper reference. Although I agree with Mark, that those lines are as wrong as possible and introduce an even worse smell than the one Jeffrey tried to cure, I disagree with him, that the problem here is the dependency on a concrete type and that we're dealing with the servicelocator antipattern. The real problem with this solution is that it is only a variant of the singleton pattern. Misko Hevery wrote a nice post, why the singleton pattern is a really bad idea.

What's The Problem?

Let's take a step back and look at Jeffery's original problem. He started with the problem, that it took a long time to instantiate the OrderProcessor because of the constructor-dependency on an IOrderShipper. From the fact, that IOrderShipper is not used by OrderProcessor in 100% of the cases, he draws the conclusion, that IOrderShipper should not be a mandatory argument to the OrderProcessor, thus effectivly turning IOrderShipper into an optional dependency of OrderProcessor.

Is IOrderShipper Really Optional?

What does making IOrderShipper an optional dependency of OrderProcessor buy us? Of course OrderProcessor get's initialized much faster now. But this comes at a price. By removing the dependency from the constructor (or passing it in via .NET 4.0's Lazy<> as some suggested), we are giving up some important advantages.

For one, we won't get any notice if there's anything wrong with the IOrderShipper until it is actually needed. There might be an important resource like a database not available, a configuration error or whatever. Only when the first user enters a valid order, this user will experience an error. This violates the fail fast & early principle.

If everything is configured correctly, this first user also will experience a surprising delay while the system is processing his order, as he has to wait until the IOrderShipper is available. This breaks the principle of least surprise.

The Real Problem: IOrderShipper

After all, it is to expect, that the majority of our users will enter a valid order. The conclusion, that IOrderShipper is an optional dependency, is simply plain wrong when looking at the real world scenario. Thus making IOrderShipper an optional dependency of OrderProcessor due to performance issues when instantiating the object graph is just curing a symptom. It is not about healing the real problem: the terrible performance of instantiating the IOrderShipper.

The lesson I learned from this exercise: always carefully evaluate, that you're drawing the right conclusions from your analysis. It is sometimes too tempting to take the easy path or be mislead and in doing so introduce even bigger problems in the long run than the one currently at hand.

As a sidenote, I absolutely agree with Jeffrey, that IoC containers are just tools and your application's design should not rely on your container's features. After all, non-invasiveness is one of the fundamentals of IoC.

So Constructor Over-Injection Is Not An Issue?

In his second post, Jeffrey introduces even more dependencies into OrderProcessor to proof his point. I have to admit, that services classes sometimes tend to grow and serve as a sort of "feature attractors". In my next post I will look into this problem and provide some thoughts on why this is a problem and how to solve it.

January 10, 2010

Spring.NET AOP - Behind The Scenes (3)

In the last installment of this series I showed you how you can leverage Spring.NET's ProxyFactory to wrap an object with a proxy and add interceptors to this proxy in order to enrich the behavior of your object's methods without having to changing a single line of code. Nevertheless it is quite cumbersome to wrap each single object explicitely.

Describing the "Where To Apply"

What we are looking for is a more automated approach, where we just want to describe the objects or - more fine grained - methods that we want to have a particular behavior applied. An interceptor ("Advice" in AOP terms) only describes *what* to do (e.g. retrying an operation), thus we need a way to describe *where* to apply it. In AOP terms, every method that can be wrapped by an interceptor is called a Joinpoint.

image

Of course we can taxatively enumerate the list of joinpoints that we want a particular advice to be applied like this:

Apply RetryInterceptor At
CalculatorWebService.Add
CalculatorWebService.Divide
...

but this clearly is not what we really want as in larger applications this quickly requires us to list each and every joinpoint in this list. What want to say something along the lines of

Apply RetryInterceptor At
All Service Methods

Looks much clearer, but how shall we describe that? You can compare it to selecting records from a database table. What we are dealing with here is a set of possible joinpoints and our "where" clause describes the characteristics of those joinpoints that we want to capture by our select statement. Applying this to our example, we can e.g. write

Apply RetryInterceptor At
ClassName LIKE '*Service' AND MethodName LIKE '*'

In AOP terms, such a SELECT statement, selecting a subset of joinpoints out of all possible joinpoints, is called a Pointcut.

image

Applying Advices to Pointcuts: Entering Object Post-Processors

Now that we have an idea, how we may select a set of joinpoints based on some criteria, how can we apply this technically? Remember, that in Spring you describe your objects using object definitions, a sort of recipe, that tells Spring how to instantiate and configure a particular object. Here's an example of such construction recipes in XML:

<object name="Alice" type="Spring.Objects.TestObject">           
<property name="age" value="31"/>
</object>

<object name="Bob" type="Spring.Objects.TestObject">
<property name="age" value="33"/>
<property name="spouse" ref="Alice" />
</object>

Using such object definitions we can build up whole object graphs, Since instantiation of these objects happens under control of Spring, we can leverage one of Spring's extension points to manipulate an object once it gets instantiated. This extension point is called "object post-processing". Everytime an object gets instantiated, Spring hands this object to all configured objects that implement the interface IObjectPostProcessor:

image

This is exactly what we need! We can implement our own IObjectPostProcessor to wrap the target instances within a proxy as needed. A simple implementation using a predicate for deciding which objects to wrap looks like this:

public class CustomAutoProxyCreator : IObjectPostProcessor
{
private readonly Func<object, string, bool> matchesPointcut;
private readonly IMethodInterceptor[] advices;

public CustomAutoProxyCreator(Func<object, string, bool> matchesPointcut,
                              params IMethodInterceptor[] advices)
{
  this.matchesPointcut = matchesPointcut;
  this.advices = advices;
}

public object PostProcessBeforeInitialization(object instance, string objectName)
{
  return instance;
}

public object PostProcessAfterInitialization(object instance, string objectName)
{
  if (matchesPointcut(instance, objectName))
  {
    ProxyFactory proxyFactory = new ProxyFactory(instance);
    foreach(var advice in advices)
    {
      proxyFactory.AddAdvice(advice);
    }
    return proxyFactory.GetProxy();
  }
  return instance;
}
}

We can now add this CustomAutoProxyCreator to our configuration in order to apply caching and retry behaviors to every object, who's object name ends with "*Service":

[Configuration]
public class AutoProxyDemoConfig
{
public CalculatorWebService TheCalculatorService()
{
  return new CalculatorWebService();
}

public CustomAutoProxyCreator AutoProxyCreator()
{
  return new CustomAutoProxyCreator(
      (instance, name) => name.EndsWith("Service"),
      new CacheInterceptor(), new RetryInterceptor()
  );
}
}

Reusing Spring.NET's AutoProxy Facilities - DefaultAdvisorAutoProxyCreator

Of course you don't need to implement your own IObjectPostProcessor for automatically creating AOP proxies. Spring.NET already comes with a predefined set of implementations that allow you to choose from various strategies for automatically creating proxies, DefaultAdvisorAutoProxyCreator (DAAPC) being the most flexible and powerful one.

What makes DAAPC so powerful? Remember our initial discussion about pointcuts and advices. DAAPC allows you to simply add such combinations of pointcuts and advices to the container configuration and will automatically pick them up to do it's magic. For this reason, Spring.NET introduced a special kind of object, a so called "Advisor". An advisor is nothing else than a combination of a pointcut and an advice to apply at this pointcut:

image

To leverage DAAPC, add a DAAPC and a list of advisors as needed to your container configuration. DAAPC then will automatically pickup these advisors and apply them. The following example demonstrates, how to apply our advices using this technique:

[Configuration]
public class DefaultAdvisorAutoProxyDemoConfig
{
public CalculatorWebService TheCalculatorService()
{
  return new CalculatorWebService();
}

public DefaultAdvisorAutoProxyCreator AutoProxyCreator()
{
  return new DefaultAdvisorAutoProxyCreator();
}

public DefaultPointcutAdvisor CacheServiceCallResultsAdvisor()
{
  return new DefaultPointcutAdvisor(
    new SdkRegularExpressionMethodPointcut(@".*Service\.*"),
    new CacheInterceptor()
  );
}

public DefaultPointcutAdvisor RetryServiceCallResultsAdvisor()
{
  return new DefaultPointcutAdvisor(
    new SdkRegularExpressionMethodPointcut(@".*Service\.*"),
    new RetryInterceptor()
  );
}
}

The advantage of this technique is, that whenever you want to apply a new advice, you just need to add new advisors to your definition and DAAPC automatically will pick them up and apply them.

And now the end is near...

What a journey. We started by identifiying cross-cutting concerns, refactoring them into separate classes using the decorator pattern. By introducing interceptors we made those behaviors reusable across different target classes. Using ProxyFactory, we even don't have to write any proxy code anymore. Finally, using pointcuts and Spring.NET's AutoProxy facilities, we can easily apply advices on any set of objects as needed. By following common sense and step-by-step refactoring, we almost naturally ended up at this mysterious technique called Aspect-Oriented Programming and proofs that there is nothing magically behind this concept. Also it proofs, that Object-Oriented Programming and Aspect-Oriented Programming are not mutually exclusive, but perfectly work together to tame today's application's complexities.

Nevertheless we are not done yet. Until now we have only discussed the technical solution, how to implement AOP. In my next post I will discuss, when to use AOP and point out a couple of issues you have to consider when applying AOP.

As usual, you can download the sample code for this post.

January 04, 2010

Spring. NET AOP - behind the scenes (2)

This is the second installment of my series about the internals of Spring.NET AOP. In my first post of this series I described the first step in separating concerns and how we can use the decorator pattern to make our code much better maintainable. Nevertheless we were still left with two major problems:

  • Changing an interface to our service requires all decorators to be changed
  • Lack of reusing decorator logic for other services

A more generic approach: Interceptors

As mentioned, we can do better. Assume we have other services in our application. We do not want to implement the caching or retry code each time and for every method. Code duplication is the root of all evil. Thus we need to improve our solution. First, let's refactor our retry code into a separate class, that can be used to wrap any arbitrary method call. We will introduce a special interface for these added behaviors and call them interceptors:

public interface IMethodInterceptor
{
 object InvokeMethod(Func<object> invokeNext);
}

An interceptor implementation gets passed in a delegate. This delegate can either be the method we are wrapping or even another interceptor. The method we are wrapping is usually called the target method. When the delegate is another interceptor, we refer to this as an interceptor chain, with each interceptor adding its own behavior before calling the target method. Our Retry-interceptor then looks like this:

public class RetryInterceptor : IMethodInterceptor
{
 public object InvokeMethod(Func<object> invokeNext)
 {
   int retries = 0;
   while (true)
   {
     try
     {
       return invokeNext();
     }
     catch (Exception ex)
     {
       retries++;
       if (retries >= 3)
       {
         throw; // retry threshold exceeded, giving up
       }
       Thread.Sleep(1000); // wait a second
     }
   }
 }
}

Notice, that our RetryInterceptor now is absolutely unaware of the target method or its arguments. It just gets passed in a delegate to invoke, which hands over control to either the next interceptor in the chain or the actual target method.

Now we can implement our interceptor chain in a rather generic way, we will call it our CalculatorProxy and hand it our actual target instance and a list of interceptors. The actual method invocation is a bit tricky, but doable:

public class CalculatorProxy : ICalculator
{
 private ICalculator target;
 private IMethodInterceptor[] interceptors;

 public CalculatorProxy(ICalculator target, IMethodInterceptor[] interceptors)
 {
   this.target = target;
   this.interceptors = interceptors;
 }

 public int Add(int x, int y)
 {
   return (int) InvokeInterceptorAtIndex(0, ()=>target.Add(x, y));
 }

 private object InvokeInterceptorAtIndex(int interceptorIndex, Func<object> targetMethod)
 {
   if (interceptorIndex >= interceptors.Length)
   {
     return targetMethod();
   }
   return interceptors[interceptorIndex].InvokeMethod(
           () => InvokeInterceptorAtIndex(interceptorIndex + 1, targetMethod)
       );
 }
}

This proxy implementation accepts calls coming in over the ICalculator.Add() interface method and passes control to the first interceptor in the chain. Initialize our proxy like this:

ICalculator calc = new CalculatorProxy(
                       new CalculatorWebService(),
                       new IMethodInterceptor[] { new RetryInterceptor() });
int sum = calc.Add(2, 5);

Each interceptor will invoke the next interceptor in the list if available or the final target:

calculatorproxy_callgraph

We have just implemented a mechanism that allows us to add any arbitrary number of interceptors to our proxy!

Generating Proxies - Spring's ProxyFactory

Of course we implemented our interception mechanism for one method only yet. Assume we have to extend the capabilities of our remote calculator and add a new Divide() method. How would the proxy implementation of this method look like? Look at this:

public double Divide(double dividend, double divisor)
{
 return (int)InvokeNext(0, () => target.Divide(dividend, divisor));
}

Comparing this implementation to our previous Add() implementation, the pattern becomes obvious. Both methods hand control to the first interceptor and pass in a delegate to the actual method invocation. No matter how many methods we add, this code will always look the same. Let's refactor the common code for invoking the interceptor chain into a base class AbstractProxy:

public abstract class AbstractProxy
{
 private IMethodInterceptor[] interceptors;

 public AbstractProxy(IMethodInterceptor[] interceptors)
 {
   this.interceptors = interceptors;
 }

 protected object InvokeInterceptorAtIndex(int interceptorIndex, Func<object> targetMethod)
 {
   if (interceptorIndex >= interceptors.Length)
   {
     return targetMethod();
   }
   return interceptors[interceptorIndex].InvokeMethod(
       () => InvokeInterceptorAtIndex(interceptorIndex + 1, targetMethod)
     );
 }
}

Our CalculatorProxy then will be:

public class CalculatorProxy : AbstractProxy, ICalculator
{
 private readonly ICalculator target;

 public CalculatorProxy(ICalculator target, IMethodInterceptor[] interceptors)
   : base(interceptors)
 {
   this.target = target;
 }

 public int Add(int x, int y)
 {
   return (int)InvokeInterceptorAtIndex(0, () => target.Add(x, y));
 }

 public double Divide(double dividend, double divisor)
 {
   return (int)InvokeInterceptorAtIndex(0, () => target.Divide(dividend, divisor));
 }
}

Even if we implemented other interfaces, these lines would be the same. Luckily, Castle.DynamicProxy, LinFu and of course Spring.NET come with mechanisms that allow this code to be generated at runtime. Below I will show you, how you can use Spring.NET's ProxyFactory to automatically generate this proxy code.

First, to make our interceptor compatible to Spring.NET, we need to implement Spring.NET's IMethodInterceptor interface for our interceptors (instead of our own IMethodInterceptor interface as described above):

public class RetryInterceptor : IMethodInterceptor // Spring.NET's interceptor interface!
{
 public object Invoke(IMethodInvocation invocation)
 {
   int retries = 0;
   while (true)
   {
     try
     {
       return invocation.Proceed();
     }
     catch (Exception ex)
     {
       retries++;
       if (retries >= 3)
       {
         throw; // retry threshold exceeded, giving up
       }
       Thread.Sleep(1000); // wait a second
     }
   }
 }
}

Notice, that instead of getting passed in a method delegate, Spring.NET's IMethodInterceptor.Invoke() receives an instance of IMethodInvocation and calls Proceed() to hand control to the next interceptor or target method in the chain. In contrast to the simple delegate that we used in our manually coded proxy, the IMethodInvocation interface allows you to access additional information about the current method call:

public interface IMethodInvocation
{
 /// <summary>
 /// Get the proxy instance for the current method invocation
 /// </summary>
 object Proxy { get; }
 /// <summary>
 /// Get the target instance for the current method invocation
 /// </summary>
 object Target { get; }
 /// <summary>
 /// Get the method info for the current method invocation
 /// </summary>
 MethodInfo Method { get; }
 /// <summary>
 /// Get the arguments for the current method invocation
 /// </summary>
 object[] Arguments { get; }
 /// <summary>
 /// Hand control to next interceptor or target
 /// </summary>
 object Proceed();
}

Now that we have our interceptors ready, we can use Spring.NET's ProxyFactory to have the proxy class automatically generated for us. Note, that in the example below the method used to add an interceptor is called "AddAdvice". Advice is the common term to refer to an action to be taken before or after calling the actual target. For a more detailled description of common AOP terminology, please refer to the Spring.NET AOP reference. Here's the code to let Spring.NET generate such a proxy instance for us:

ProxyFactory proxyFactory = new ProxyFactory();
proxyFactory.Target = new CalculatorWebService(); // set target
proxyFactory.AddAdvice( new RetryInterceptor() ); // add interceptor

ICalculator calc = (ICalculator) proxyFactory.GetProxy(); // create proxy instance

The call to GetProxy() will generate a proxy instance, set the target and add the list of interceptors to the proxy. The result is the same structure we showed above and also the call graph of an interceptor chain looks very familiar:

calculatorproxyfactory_callgraph

The difference is, that we didn't have to write a single line of code for our proxy. This means that we now easily can reuse our RetryInterceptor across all kinds of classes in our application!

We want more!

Wow, what a journey. We started by separating concerns into their own classes by applying the decorator pattern, implemented our own proxy with a flexible method interception mechanism and finally saw, how Spring.NET's ProxyFactory can be used to do all of this for us automatically.

Is there anything left on our wishlist? Imagine we have a whole bunch of Service classes in our application that we would like to retry their operations. We'd have to execute the lines to create the proxy, set the target and add the interceptors for each service individually. What about a feature that allows you to just point to a list of objects and tell Spring.NET to wrap those objects in a proxy with a given list of interceptors?

Indeed the AOP framework of Spring.NET comes with a great feature called "AutoProxying" that makes it easy to automatically apply interceptors to a set of objects. Stay tuned to read how this feature works in the next post of this series!

As usual you can download the example code.

December 31, 2009

Happy New Year!

Instead of a technical post, today I just want to wish a happy new year to everyone! The promised follow-up post of my AOP series will go online on January 4 in the next decade.

All the Best and I hope to see you again next year!

December 28, 2009

Spring.NET AOP - behind the scenes (1)

On the forums I see one topic coming up quite often: "Can I advise XY?". In this multipart post series I will describe the motivation for AOP and the way Spring.NET AOP (and most others like Castle.DynamicProxy and LinFu) technically work in .NET to give you a better understanding and provide you the knowledge to help answering such questions yourself.

The example: Retrying operations

Instead of the usual logging example I'd like to show you another useful feature: Retrying operations. For the sake of simplicity let's assume we're calling a webservice method for calculating the sum of two integers.

CalculatorWebService calc = new CalculatorWebService("http:/...");
int sum = calc.Add(2, 5);

Since webservices usually involve calling over the network, they are inherently unsafe and might fail for various reasons. In our application, we would like to retry webservice operations 3 times before giving up, with a 1 second delay between retries.

There are a couple of ways to implement this requirement, the most direct approach probably by deriving our own class from the webservice client class:

public class RetryingCalculatorWebService : CalculatorWebService
{
  public RetryingCalculatorWebService(string url):base(url) {}   

  public override int Add(int x, int y)
  {
    int retries = 0;
    while (true)
    {
      try
      {
        return base.Add(x, y);
      }
      catch (Exception ex)
      {
        retries++;
        if (retries >= 3)
        {
          throw; // retry threshold exceeded, giving up// wait a second
      }
    }
  }
}

There are of course a couple of issues with that approach, the 2 most important are:

  • The code for retrying the operation effectively buries our single line of actual business code. This makes it hard identifying what the code actually does:
public class RetryingCalculatorWebService : CalculatorWebService
{
  public RetryingCalculatorWebService(string url):base(url) {}   

  public override int Add(int x, int y)
  {
    int retries = 0;
    while(true)
    {
      try
      {
        return base.Add(x, y);
      }
      catch(Exception ex)
      {
        retries++;
        if (retries >= 3)
        {
          throw; // retry threshold exceeded, giving up
        }
        Thread.Sleep(1000); // wait a second
      }
    }
  }
}
  • When implementing this requirement across all our webservice clients we not only end up scattering the same lines of code all over our codebase. A change in the requirement might cause us having to change all our webservice client classes causing a huge amount of work.

image

A manually implemented a solution

A structured way for non-intrusively adding behavior to exisiting code is described in the GoF book, the pattern is called "Decorator", the basic idea being wrapping the actual target method with additional code. Thus you do not need to modify any existing code, instead you "chain" the various required behaviours, each behaviour implemented in its own class. In contrast to the GoF-pattern, nowadays composition is favoured over inheritance, thus instead of using the inheritance approach, let's introduce an interface to easily chain our behaviors:

public interface ICalculator
{
  int Add(int x, int y);
}
ICalculator calc = ...;
int sum = calc.Add(2, 5);

Now we can easily implement our business logic and the infrastructure constraint separately and chain them later as needed:

public class CalculatorWebService : ICalculator
{
  public CalculatorWebService(string url) { ... }   

  public int Add(int x, int y)
  {
    // perform actual webservice call
    return ...
  }
}
public class CalculatorRetryDecorator : ICalculator
{
  private ICalculator next;

  public CalculatorRetryDecorator(ICalculator next) { this.next = next; }

  public int Add(int x, int y)
  {
    int retries = 0;
    while (true)
    {
      try
      {
        return next.Add(x, y);
      }
      catch (Exception ex)
      {
        retries++;
        if (retries >= 3)
        {
          throw; // retry threshold exceeded, giving up
        }
        Thread.Sleep(1000); // wait a second
      }
    }
  }
}

Notice how the CalculatorRetryDecorator delegates the actual work to the next calculator in the chain. Now, whenever our requirements force us to retry calculator operations, we just "chain" the implementations together:

ICalculator calc = new CalculatorRetryDecorator( new CalculatorWebService( "http://..." ) );
int sum = calc.Add(2, 5);

Now, when we discover that our performance is to slow, well - implement a caching decorator that caches method results for a certain amount of time using the same approach and add it to the decorator chain:

ICalculator calc = new CalculatorCacheDecorator( new CalculatorRetryDecorator( new CalculatorWebService( "http://..." ) ) );
int sum = calc.Add(2, 5);

When we call the Add() method,  our call graph looks like this:

calculatordecorator_callgraph

This is only the beginning

We already achieved a lot by separating concerns into different classes. Still our solution has some significant weaknesses:

  • When we add new methods to our ICalculator, we need to extend all of our decorators
  • We want to reuse the retry logic for other services

In my next post I will address those issues and show you how we can implement a more generic solution.

Here you can download the example code for this post.

December 24, 2009

A little Christmas present - for .NET

Just read Eberhard Wolff's newest blog post and simply couldn't resist to borrow the idea and show you, how the same things can be done using Spring.NET. First, here's the .NET version of Eberhard's example:

public class MyRepository
{ }

public class MyService
{
    public MyRepository MyRepository { get; set; }
}

Here it is, the smallest possible Spring.NET object. Notice, due to Java's lack of properties the .NET version is even smaller. Still, no attributes, no Spring dependencies - pure code.

How do you wire them? Spring.NET's XML configuration unfortunately lacks Spring.Java's component-scanning as demonstrated in Eberhard's post. But using the new code-based configuration I presented recently, you easily can wire your objects by writing

appContext.Configure(cfg => cfg
     .Scan(scan => scan
        .TheCallingAssembly()
        .Include(t => t.FullName.EndsWith("Service") || t.FullName.EndsWith("Repository"))
        .With<AutowiringConvention>()
));

The example code can be downloaded at SmallestSpringObject.zip

Merry Christmas!