June 2005 - Posts

Next to several rumors on support for SQL and XML language elements in C# version 3, a new rumor is releasad in the blog-o-sphere.

According to Jimmy Nilsson it could well be possible that C# 3.0 comes with support for AOP Mixins... Wow!

I assume this doesn’t only cover AOP Mixins (as a way to accomplish multiple inheritance) but also the (far more usefull) AOP concept of advice.

Even though making assumptions is tricky, in al my excitement all give you an idea of what 'Advice' is anyway... :-P

In Aspect Oriented Programming (AOP) Advice is used to implement crosscutting concerns without scattering code (or without loss of a ‘single point of definition’).

In Object Orientation you suffer from scattering if there seems to a specific logic implemented in multiple places across your program, without being able to refactor it out using design patterns.

Imagine that must of the code you write looks like the following method.

public void DoWork(...)

{

    using(TxManager transactionManager = new TxManager())

    {

        transactionManager.BeginCtx();

       

        //do work

 

        transactionManager.CommitCtx();

    }

}


Every time you write a method like this, you are implementing transaction logic somewhere it doesn’t belong (business entity of some kind).

Advice solves this problem by ‘injecting’ the transaction management code around multiple methods across your program logic. 
A piece of advice that injects this same transaction logic into every method named DoXXX could look something like this (somewhat imaginary syntax, based on Aspect#):

 

[Mix(“Do*(*)”)]

public class TransactionAdivce: IAdvice

{

    public object Invoke(IMethodInvocation methodInvocation)

    {

        using(TxManager transactionManager = new TxManager())

        {

            transactionManager.BeginCtx();

           

            methodInvocation.Proceed();

 

            transactionManager.CommitCtx();

        }

    }

}

 

Whenever a method called DoXXX is called -instead of the actual method- the TransactionAdvice is called by the runtime. The original method invocation is passed to the Advice as a parameter and the call can be proceeded from within the advice. With this approach the transaction logic is left out of business entities (where it simply didn’t belong anyway) and defined in 1 place at compile time.

 

Same could be done for Caching, Parameter checking, Logging, Security checking, ...  


If you simply can’t wait till the first C# compilers are available from Microsoft, you can always get your hands dirty on Aspect# (works in combination with C# 1.0)

Have a look at this interesting application for EntLib 1.0 at GotDotNet (http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=41a621e5-3628-4c71-8985-710c4475f347)

Look here for a description of the
Service Locator pattern.

Just came across this (~5 minute) video on Channel 9.

Comments suggests that Anders actually talks about the Comega programming language (that observation was a pretty obvious one ;)).

Have a look over here and here on what I think of Comega.

 

 

Posted Sat, Jun 4 2005 12:17 PM by Olaf Conijn | with no comments
Filed under:

A colleague of mine (somehow known as Obiwan Jacobi) pointed out what I think is a design mistake in EntLibs CacheManager API.

The flaw lies in the publicly exposed CacheManager.Contains(string) method.

Exposing this member almost ‘instructs’ a consumer of the CacheManager to write code similar to:

if (!CacheManager.Contains(cacheKey))

{

      //fill cache

}

object cachedObject = CacheManager.GetData(cacheKey);

You’ve probably already noted the potential bug in the logic above, what if……. there’s a scavenger run in between the first and last line of code.

 

Hardly seems like a good pattern or practice, does it? ;)

Feel like using EntLib on ASP.NET 2.0? Ohad's WebLog contains links to an “unofficial” build (and source) of Enterprise Library 2.0.

In case you wondered whether this EntLib release contains more application blocks than the previous release, it doesn't.