NHibernate here we come !

Currently we are starting up a project to rewrite the security service.  The previous version was build using data sets (argh it even gives me the creeps just writing this word), relying heavily on the database.  For every change (big or small) on the user profile the entire thing was deleted out of the database and the new version was inserted.  It even came this far that with large profiles, the timeout of the web service was hit and the application refused to work altogether.  Lessons learned from this debacle, we decided to build a clean domain model and use a UnitOfWork to decide what needs to be saved into the database.  We added features like lazy loading and caching as well to avoid database payloads.  Then we decided, based on the patterns already examined, we would need an ORM.  We looked at some possibilities (Allors, NHibernate, ...) , did some spikes and decided that when building a Persistence Ignorant domain model, Nhibernate was the best choice.

We presented our findings and spike results along with our proposed solution to the enterprise architects.  It was turned down for no apparent reason.  Their solution was to align with the rest of the organization and go for a data-driven approach (they even mentioned data sets) and thus avoid complex domains that need mapping through a tool.  In case of caching, we were told to write it in stored procedures (because that is why they are there for :-)).  "Why on earth did we even have a complex domain model" was the last question of the meeting.  This coming from a team  that believes that writing unit tests is more time consuming than it is beneficial.  Wait until they have to maintain one of these data-driven applications :-). 

We lost the battle, but we didn't surrender.  We already assembled some followers:

• The DBA team loved the caching and the reduced database hits.
• Other development teams were experiencing the same problems so were asking for similar solutions. 

Long story short, the decision to use it or not was postponed until a meeting were both us and the A-Team would present our cases.  The meeting was last Monday and given this blog posts title our arguments have won it.

Thank God because we already started on the ground work of our own ORM and it would take a lot of work to build the features we are now getting for free!  We've worked about two weeks on it and I think we could cover about 75% percent of our basic CRUD operations.  We didn't yet added support for collections the UnitOfWork, but we already had ideas about how to do it (build a custom persistent collection for it).  Our implementation depended heavily on the dynamic proxy of castle project and was inspired by the NHibernate source code.  Writing it ourselves made me think about this scene from the matrix were Morpheus asked Neo to take the blue pill and stay ignorant (about persistence issues) or take the red pill and see what really going on.  We were forced to take the red pill or doom the project before it even began.  It was fun to experiment with it, but when your problem domain is security, that should be the focus of your development all time you spent on infrastructure code is time wasted!

Anyway we are going to test NHibernate in our project, then it will be evaluated and eventually rolled out to the rest of the development teams. Lets start reading about it!

See ya next time.

Accounting (part 1)

As explained in my previous post I am going to demonstrate the potential of Allors by building a sample application.

I'll be building an invoice application which has the following domain model:

Blog changed

Okay, this was my 'test' blog.

Please continue reading at my new blog or register at my feedburner

Blog test....

Please ignore this post, just testing some of my live writer stuff...

Quoting: Can be done like this.

   1: public class MyClass 

   2: {

   3:     /// Constructor of My Class

   4:     public MyClass() 

   5:     {

   6:     }

   7:  

   8:     /// Action Method

   9:     public void Action() 

  10:     {

  11:     }

  12: }

Think you are a serious developer? Think Resharper...

I am using Resharper

since version 2.0 and VS2003.  Back then I had major problems with my studio crashing because of the memory consumption the application took.

It improved a lot when moving to version 2.5 (and 3.0) and studio 2005. 

Currenlty I am evaluating the 4.0 EAP version (actually 4.0.775.22) Jetbrains is releasing by their nightly build.  Currently I haven't found any major issues with it.  So to the nice people of Jetbrains, keep up the good work.

By the way, thanks to Ilya Ryzhenkov for providing a list of nice plug-ins for resharper.

EDIT: Apparantly one of my solutions failed to load now.  So I shifted back to the 3.1 version of resharper. 

Tags van Technorati: Resharper,programming

TFS 2005 upgrade to TFS 2008

We are experiencing problems upon upgrading our TFS to the new 2008 version.  All is going magically well, but when we are converting our Scrum template from conchango, we hit the problem.  We already reported it on their portal and currently they are working on a solution for it.

Anyway, since only the portal does not work I am willing to take that loss (we didn't use it anyway :-)).  Next checks are that our customized Work Items and Reports are correctly converted to 2008.  I don't see lots of issues coming our way since all other templates converted perfectly.

When we originally updated our work items I did it manually.  Exporting the the WIT, changing the XML and then importing it again.  Now apparantly it is all incorporating in the team foundation server power tools.  Making life a little bit easier.

 

Tags van Technorati: TFS,Scrum,Conchango

'Trac' - ing Allors

We have just created a trac website for allors.  Both the platform and the applications have a seperate website to track its progress.

By doing this we have as well released the code to the community.  The platform is nearly 1.0 ready, thus this means we can begin shifting the focus the applications section.

Currently I'am integrating simple workflow features in the Core Domain.  Although some of my collegues do not believe in workflow (sometimes including me).  I think, when used carefully, it can simplify your overall project structure.

Tags van Technorati: Allors,Workflow,trac

How to seperate Domain and infrastructure logic?

Tags van Technorati: Castle,Domain,Mixin

Today I struggled with the fact that some infrastructure code drippled into my domain while building the ORM features ourselves.

The problem was that I had to load a bunch of objects as a Tree Collection.  So the easy solution was to add an extra Id field to the class to store the parent/child object Id and after all where loaded, iterate an link to the correct solution.  Now I polluted my domain with some infrastructure fields (I had to add some more...).

Because we are already using the Windsor container as our dependency container and the dynamix Proxy Interceptors for lazy loading on the project, I thought about using the mixin functionality they offer.  I created an extra data object in the infrastructure layer and then wanted to 'mix' them.  Bummer, dynamic proxy 2 does not support this functionality (although ayende claims he added support for about a year ago)!

So I went for the second solution, much simpler in my opinion.  Instead of creating an seperate data structure to hold the extra data, I decorated my domain object.  My mapper object now creates the decorated objects (which are internal).  After I loaded all my objects into memory, the repository uses the extra data to build up the tree and voila we're done.  My domain remains mean, lean and clean, but I have the extra information at my disposal.

Till next time...

Our Service Architecture: Why oh why....

On my current job we (me and Jan) are currently building an security service.  It will be a WCF Service who's primary use will be for authenticating users on the intranet.  Another service is currently under development to manage the permissions of these users.

We are having huge fights with the architecture team (indeed we still have an architecture team) about how we should build the services. Me and Jan are firm believers of domain centric applications while architecture thinks it should be data driven.  It shows that they do not need to maintain and give support for it.

Anyway we have won the fight and have already built the domain (in a TDD driven manner of course).  Yesterday I started with the infrastructure layer which is primary targetting a DB2 database. 

A second battle we had with the A-Team was about the use of an ORM to take care of the persistence, the features for caching, unit of work and lazy loading were a nice extra. Since I told you I was already started with writing this code myself you know we lost this time (at least we put up a fight to improve things....). 

During the last two days I find out why ORM are so popular.  It takes so much out or your hands that you take otherwise for granted.  Have you ever tried writing a unit of work yourself?  Not the most fun job if you know it has absolutely nothing to do with the core of the application we are writing. 

Anyway hopefully in one of the upcoming months someone sees the light and gives us a boost in our productivity.

Tags van Technorati: Architecture,agile,orm,unit of work

Open Source

Together with Koen and Martien we are building on a framework (called Allors) that enables domain driven development. 

With Allors you build a meta domain with a repository tool, where you describe your objects.  At runtime you have access to the meta information, this means you can ask it for information about your domain. 

The following posts will be a tutorial on how to use Allors for your projects and what are the benefits!

Getting started (about me...)

Here goes.....

As this is my first blog ever, I'd like to start with introducing myself.  My name is Patrick De Boeck and I live with my girlfriend in Merksem, a small city next to the center of the earth, Antwerp.  I am the proud father of a two year old little girl, Amber.

Professionally I am developing software since the year 2000 (that's right just after that millennium fuss thing).  I started out as Java developer by doing consultancy work across Europe (Antwerp, London, Luxembourg and Frankfurt).  In 2003 I had to opportunity to become lead developer/architect of a major software insurance project in Eindhoven.  I had to switch to the .NET world for it though, but so far I haven't regretted that.

In 2004 I decided to make a leap in the dark and become a freelance software developer.  My company is called PDBC - Systems and is specialized in .net consultancy.  I also participated in Allors.  In future blog post I will elaborate on this. 

Domain Driven Development will be the major theme of this blog.  I strongly believe that any development team should focus on their problem domain instead on infrastructural and persistence problems.  There are tools (see Allors) to take care of that for you.

That's enough about me now, but I promise the following blog posts will be more interesting.