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