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