PostSharp

It's time again to have a look at PostSharp4EF, a project of the excellent Ruurd Boeke. PostSharp4EF turns your plain C# or VB classes into full-featured domain objects for client-server applications backed by an SQL database. Once you understand what it means, you understand it is actually very cool.

What is PostSharp4EF?

So what is it all about?

On the server side, PostSharp4EF binds your domain objects to the database. It uses the ADO.NET Entity Framework for that job, but implements automatically all the plumbing code during the project build. The result: you can use clean and lean C# or VB classes as your first-class asset. And since the plumbing code is generated at compile time, you still benefit from excellent performance.

On the client side, the challenge is different. We don't need domain objects to be bind to the database, but to user interface components. And GUI components have two requirements to domain objects: they should be editable (the interface IEditableObject makes it possible to accept or reject changes), and they should be observable (interface INotifyPropertyChanged). Additionally, we want the domain objects to remember that they have been modified, so we can send them back to the server when we press the 'Save' button. So we are actually in a disconnected, stateless model.

Well, if you have to implement IEditableObject and INotifyPropertyChanged by hand, it's again a lot of plumbing code!

Of course -- as you've guessed -- PostSharp4EF rescue us by implementing the interfaces automatically.

How does it work?

We've seen that the server and the client have different requirements to the domain objects. So PostSharp simply adds different aspects for the server-side assembly (persistence aspects) than from the client-side assembly (GUI aspects). That is, from the same source code, two different assemblies are created.

Clean C# code as first-class artifacts

What I like with PostSharp4EF is that it shows how aspect-oriented programming can let your domain objects really clean. If all binding code is "outsourced" as an aspect, what's left? Well, simply: the real domain object definition and the real business logic! So C# code can be a first-class artifact, even for domain objects.

The Economics of AOP

Another thing this project illustrates is how you can actually save money in your company with aspects. If you don't agree that it costs less to have tools generate the plumbing code, stop reading here. But if you agree with me so far, go on.

Of course, AOP has some costs. One of these are the cost of developing the aspect. Ruurd has done a great work, but I know it was a demanding one. A software shop with all the overhead of design documentation, meetings and reports would take maybe one month to implement that feature. So it's not exactly cheap. But what was produced exactly? Actually, Ruurd has produced a great production asset: a tool that makes the process of software production less expensive and of higher quality... So it's just like when a company invests in a new machine: yes, it costs some money to acquire it; yes, it costs some time to learn it; yes, there are risks. But how much money the machine will allow you to save, during the whole lifetime of your product family, by reducing development effort and improving quality? The job of a software engineer is to improve the process of software production, and aspects are one of the tools he should consider!

With PostSharp4EF, you have that production asset for free: both PostSharp and PostSharp4EF are open source.

But even in case that this particular project does not fit your needs, think one minute about what kind of code production could be appropriately replaced by an aspect-oriented tool.

Happy PostSharping!

Gael

I'm finally back from the AOSD 2008 conference, the principal conference of the Aspect-Oriented Software Development (AOSD) community. This is an academic conference, which means that most people are either academic researchers, either researchers in R&D departments of big companies. So I was a kind of stranger there, but this time I did not suffer too much from that.

I have delivered my speech on Wednesday 2nd April in the industry track. Slides are available for download. Note that the speech was designed for an audience who is comfortable with AspectJ, which I guess is not the case of the majority of readers of this blog. You can also download the paper, the most systematic and complete description of PostSharp Laos so far. It was published in the proceedings of the conference. If you need to convince someone that PostSharp is serious, you can put the paper on his table!

The conference was not only about PostSharp, of course. I mostly attended to the industry track and to some demonstrations. Here are the topics I was most interested in:

• Daniel Wiese, Software Architect at Siemens Medical Solutions, presented how AOP was used in a huge project (SORIAN, a Hospital Information System) of 400 developers spread in 4 different countries. AOP was used principally to handle the "non-functionals", i.e. logging, auditing and so on. What's interesting with that? Well, the scale of course! It shows that AOP has already grown from its youth phase when it was used only in prototypes. Daniel cited some practical problems they met with AOP, principally the increased build time. The selected solution was to weave the code only for nightly builds, so developers do not loose time waiting for the weaver in local builds. Siemens also wanted to enable/disable aspects after deployment (for instance to enable monitoring in a part of the solution when it is in production). Therefore, they used load-time weaving in WebSphere, a Java application server. Since the built-in weaving solution of WebSphere was not satisfying (it was an old version of AspectJ with bad support of load-time weaving), they developed their own weaver: FastAOP. Thank you Daniel for this great show, and let's hope it will convince companies to adopt this technology!
• SAP integrated AOP technologies in the new version of ABAP, the SQP programming language. True, it is not AOP in the sense we usually mean, but if SAP is getting interested in AOP, what are all the others waiting for? Another proof that it's useful!
• ASLM, a producer of semiconductors, developed their own solution to weave hundreds of thousands of lines of code in C.
• Hitachi developed an AO extension to COBOL. Yes, you read well: the old good COBOL.
• Siemens team presented a funny show of Aspect Manager 2010, a plug-in to Eclipse allowing easy discovery of aspects and their injection into projects. An excellent source of inspiration for PostSharp! Indeed, it convinced me that we should design a standard packaging for aspect libraries to streamline the installation process.
• M4JPDD, a tool to express quite graphically complex pointcut. Very interesting, although IMHO not backed by a sufficient demand.

The conclusion for me is that there is real interest for AOP in industry, and AOP has already proved itself in huge projects. Why would the .NET world make exception? Experience shows that people are currently mostly interested in the "easy" aspects like caching, auditing, security, and so on. But it is precisely what PostSharp Laos is good in! So it seems I am on the good track. On the other side, there is a lot more in AOP than what PostSharp is able to do! If you follow the blog and the work of Ruurd Boeke, you will find out that PostSharp does not perform well with complex tasks. Of course, you can do everything you want (which gives an amazing feeling), but it results in much more aspect code than what would be the case with AspectJ.

In other words, the conference was a great opportunity to assess the design choice of PostSharp Laos: make simple things easy, knowing that the market is currently at 80% interested in easy things.

Happy PostSharping!

Gael

Today I'm packing for one week of vacation followed by the AOSD 2008 conference, the principal conference of the AOP community

I will be presented PostSharp in a session academically named User-friendly aspects and compile-time imperative semantics in .NET with PostSharp and you can already download the paper in PDF format.

But that's not all. If you are to attend the conference, you are invited to the Microsoft.Community.Dinner that will take place the 2nd of April (the day of my speech) after the reception. Info and reservation at gael at fraiteur dot net.

During the

I am happy to announce that I started this week a long-term partnership with Starcounter AB, a Stockholm-based software shop producing a next-generation object database management system (ODBMS) that will make you understand the benefits of 64-bit hardware. I am not allowed to give too much details, but I'll sure do it once it will go public. Believe me, it sounds cool!

The good thing for PostSharp is that the partnership plans to reserve 40% of regular working time to PostSharp development. To be more precise, I will work in the average 3 days a week for Starcounter, but at a rate that allows me to invest the rest of the time in PostSharp.

Starcounter is already a old partner of PostSharp. Contacts started in June 2006, when they started considering PostSharp in their product. In November 2006, they sponsored the development of the hosting infrastructure, which allows to host PostSharp easily in server environments. In May-July 2007, they hired me to implement PostSharp in their product. The money allowed me to pack and publish the first release candidate, which was a really great step!

PostSharp just took too more time to be done in spare time (do you realize the time it takes to support users, correct bugs, and promote the project?). I am happy that our agreement will guarantee the future of PostSharp.

A great new for the community expecting long-term project viability!

Happy PostSharping!

Gael

If you belong to those who don't like global installations, the latest release candidate should make you happy: there is now a binary distribution without installer.

This distribution should remove much of the mystery about how PostSharp integrates in the build process. Actually, since the installer does not modify the MSBuild target files for you, you have to do it yourself. The interesting thing is that you can do it in a per-project basis: instead of modifying global MSBuild target files, you can just import PostSharp in the projects that actually need it.

If you think this kind of installation is for you, download the 'Binary - No Installer' package, and read carefully the installation instructions in the file doc/Build-Instructions.html.

Since this kind of distribution is quite new, I am looking forward for your comments.

Happy PostSharping!

Gael

I have just checked in a library (actually, only two classes) allowing to use PostSharp in ASP.NET projects. The stuff is hosted at http://code.google.com/p/postsharp-user-plugins/. The reason why it did not work previously is that ASP.NET compilation does not go through MSBuild, so PostSharp was simply not invoked.

Indeed, MSBuild has its own compilation mechanism. Fortunately, it has an extension point that seems just done for PostSharp: the IAssemblyPostProcessor interface. As you may imagine, it allows to post-process the compiled assembly.

So I simply developed an implementation of this interface (one class). The second class is a configuration handler.

Here is how to use this preliminary version of the library (from the documentation):

In order to use PostSharp in a web project, specify this class as an assembly post-processor in web.config:

<configuration>
     <system.web>
       <compilation debug="true"
         assemblyPostProcessorType="PostSharp.AspNet.AssemblyPostProcessor, PostSharp.AspNet"/>
     </system.web>
</configuration>

Additionally, you have to add the <postsharp ... /> section in the configuration file:

<?xml version="1.0"?>
<configuration>
 <!-- Add a configuration handler for PostSharp. -->
 <configSections>
  <section name="postsharp"
                         type="PostSharp.AspNet.Configuration.PostSharpConfiguration, PostSharp.AspNet"/>
 </configSections>
 <!-- PostSharp configuration -->
 <postsharp directory="P:\open\branches\1.0\Core\PostSharp.MSBuild\bin\Debug" trace="true">
  <parameters>
   <!--<add name="parameter-name" value="parameter-value"/>-->
  </parameters>
  <searchPath>
   <!-- Always add the binary folder to the search path. -->
   <add name="bin" value="~\bin"/>
   <!-- Then add the location of plug-ins that are not installed in standard locations. -->
   <add name="laos-weaver" value="P:\open\branches\1.0\Laos\PostSharp.Laos.Weaver\bin\Debug"/>
  </searchPath>
 </postsharp>
 <appSettings/>
 <connectionStrings/>
 <system.web>
  <!-- Note the 'assemblyPostProcessorType' attribute. -->
  <compilation debug="true"
                             assemblyPostProcessorType="PostSharp.AspNet.AssemblyPostProcessor, PostSharp.AspNet">
  <authentication mode="None"/>
  <trace enabled="true" pageOutput="true"/>
 </system.web>
</configuration>
 

In all configuration parameters and in search path elements, the tilde character (~) is replaced by the physical path of the application.

Be prepared that the compilation will be much much longer, especially if it is fine-grained...

This is a preliminary version, feedback is welcome!

Happy postsharping!

Gael

PostSharp4Unity modifies assemblies after compilation to make objects self-configurable: you don't need to call a factory method; you can use the default constructor. All you have to do is to decorate your class with the custom attribute "Configurable". It smells like Spring, isn't it ;-). It is available from http://code.google.com/p/postsharp-user-plugins/. I have updated the StopLight sample. The first change is on the StoplightForm class:

[Configurable]
public partial class StoplightForm : Form, IStoplightView
  {

Then, in Program.Main, you can use the default constructor:

Application.Run(new StoplightForm());

Unfortunately, that's not all. Since Unity has no notion of context registry (i.e. no notion of "current container"), you have to build a basic one:

public sealed class UnityContainerProvider : IUnityContainerProvider
{
   private readonly IUnityContainer container;
  
    public UnityContainerProvider()
    {
       this.container = new UnityContainer()
         .Register<ILogger, TraceLogger>()
         .Register<IStoplightTimer, RealTimeTimer>();
    }

    public IUnityContainer  CurrentContainer
     { get { return this.container; } }
}  

Then tell PostSharp4Unity to build your container:

[assembly: DefaultUnityContainerProvider(
  typeof(UnityContainerProvider))]

As you can see, there is a little of set up to do, but it's only once per assembly. (And would be useless if there were some Unity-wide notion of context registry or default container.) At this price, you can use Unity with any object without having to construct them using a factory method. Pay attention that your 'configurable' objects are now configured before the constructor is executed, and not after. So, in the class StoplightForm, we have to move the view initialization at the end of the constructor:

[Configurable]
public partial class StoplightForm : Form, IStoplightView
{
   private StoplightPresenter presenter;

   public StoplightForm()
   {
      InitializeComponent();
      presenter.SetView(this);
    }

   [Dependency]
    public StoplightPresenter Presenter
    {
      get { return presenter; }
      set { presenter = value; }
    }

There are still some problems being discussed, but at least you have the first bits. Happy PostSharping! Gael