Archive

Posts Tagged ‘Unity’

Aspect Oriented Programming

November 27, 2010 3 comments

Aspect Oriented Programming or AOP as it is so-called is an interesting technique to employ cross-cutting concerns such as logging, exception handling, security and others into your applications with hardly any effort at all.

AOP vendors such as SharpCrafters use an interesting technique at build time to ‘weave’ aspect code in with your methods. The result is that your methods are in a sense altered to incorporate these ‘Aspects’.

For example consider the proverbial ‘Foo’ method…

public void Foo()
{
     // Do something here
}

Now consider that you have the need to log when you are entering and exiting from the method. You could add the following code…

public void Foo()
{
     Trace.TraceInformation("Entering the Foo method.")
     // Do something here
     Trace.TraceInformation("Exiting the Foo method.")
}

This code works well if you need information about this one specific method. But, what if you need this information for all methods of a class? Writing this code is not only tedious, it detracts from code readability. Now imagine that you want this level of information on several classes, perhaps the entire project.

Enter Aspect Oriented Programming and a product such as PostSharp. To accomplish the logging capability at the method level, you would simply add an attribute as so…

[Trace]
public void Foo()
{
     // Do something here
}

[Trace] is an Aspect. Aspects are classes that you write in order to execute code within the boundaries of the method. In this example, code was written to perform some action on entry and another prior to exiting the method.

As mentioned earlier, you could apply this Aspect to the entire class or even an assembly with a single line of code…

[assembly: Trace( AttributeTargetTypes="SomeApp.YourBusinessRules.*",
  AttributeTargetMemberAttributes = AttributeTargetElements.Public )]

This works because a product like PostSharp uses a post compilation step to inject code into the IL. The code can be seen with a decompiler product such as Redgate Reflector.

If you’re interested in serious logging and performance monitoring you can combine the power of PostSharp with a product like Gibraltar for amazing results with almost no effort at all.

AOP – The Other Side of the Coin

If your thinking that you don’t want post compile code to be modifying the compiler-generated IL, you’re not alone. It is probably the single biggest argument against utilizing this technology. My personal opinion is that I consider many variables such as the application’s life-cycle. Is it a mature piece of code, is it legacy, or are we beginning a new project?

Certainly it is a compelling story to be able to gain much-needed cross-cutting concerns that were left out of a legacy code base with such little effort. In fact, it could even extend the life of the application dramatically.

However, if I’m starting a project from scratch, I tend to look at other alternatives such as code generation or policy injection with Microsoft Unity.

Summary

AOP is a very interesting technology that can yield almost immediate benefits with very little effort. Like any other pattern or technology, it has a time and place and you as the architect should weigh the risks and benefits before a single line of code is written.

Frameworks – A Domain Specific Language

November 24, 2010 3 comments

Domain Specific Languages (DSL) can be a tremendous performance boost for many software development environments. When used properly, it can dramatically reduce tedious hand-written code, decrease defect rates and increase code readability. They can also help bridge the gap between the developer and business personnel.

I have been working with a DSL named Frameworks that brings forth an entire architectural framework into focus. It has been used in several enterprise-grade products and development is continuous and on-going.

Frameworks, while easy to use, deserves an in-depth discussion on its philosophies, artifacts, coding techniques and limitations. For these reasons, this blog will be multi-part, addressing a different topic with each post.

What is Frameworks?

It is a DSL that utilizes a Model first approach to development. There are some excellent writings on this subject and I encourage you to explore it if you have not already done so. The Domain Model provides a soft transition of knowledge from domain level expertise to developer ‘speak’. It is a model that business analysts digest quite easily and one that the developer can use in most every phase of a project. Domain Models look similar to a class diagram as shown below.

Frameworks loosely uses the Domain Model as the hub for many artifacts. Amongst them are business objects and their interfaces, data-access objects and their interfaces, ORM and dependency injection configuration and others.

The goal of the Frameworks is therefore several-fold:

  1. Help to bridge the gap between business analyst and developer roles using the domain model.
  2. Use the domain model to generate artifacts so that the developer does not have to write tedious, error-prone code.
  3. Generate the code utilizing best practices that build on the work of others.
  4. Allow the developer to choose between NHibernate and Microsoft’s Entity Framework to achieve object-relational-mapping (ORM).
  5. Take advantage of dependency injections (DI) systems such as Microsoft Unity into the generated code.
  6. Allow for internal caching of ‘category’ type data upon simple declaration.
  7. Allow the developer to declare database partitioning (‘sharding’) without having to write the code to do so.

As you can see, the project is quite ambitious. This series of blogs will attempt to describe in various levels of detail, how these goals have been realized.

The next blog in the series will discuss the domain model in detail and setup some of the philosophies around the architecture.

%d bloggers like this: