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