I don't usually blog...

...about code, but with me starting a new job on Monday, I might start. It's something I'm quite passionate about.

So, here goes:

I've spent this job (the one I'm leaving :D) increasingly writing more complex code, thinking I'm writing 'proper' n-tier applications. I've got all my business objects defined. I'm using NHibernate to map these to my relational database system. I have some gel sitting between my application and NHibernate, that I've called a Data Access Layer. I've used interfaces, and have some config files that allows me to plug-in different parts of code. All is happy.

Then, two days ago, I stumbled across Jeremy D. Miller's Blog.

WOW!!!

The first article I read was about how most unit tests are actually integration tests. Some of the code on the site, and Jeremy's beloved Structure Map examples, illustrate how to really write loosely coupled code.
By coding to interfaces, rather than to concrete classes, and then using dependency injection, a really loosely coupled, and highly flexible, system can be created.
One of the offshoots of this is that you can then write much more granular tests, using mock objects for the dependencies. Suddenly something clicked. I've been doing it all wrong.

Then, last night, on the train home, I happened to have Martin Folwer's Patterns of Enterprise Application Architecture with me, and I happened to be flicking through it. Like with the original patterns book, I'd never really looked at this much, just bought it because it looked good, flicked through most of the content, and never really took the time to understand it. Perhaps, even, like with the patterns books, I wasn't in a place to understand it.

Anyway, I happened to open the book at the Transaction Script page. I read the description, never having looked at this pattern before, heading straight for the Domain Model. In association with the transaction script's description, I turned to the Data Transfer Object page. Things were starting to look a little familiar.

Perhaps there's a blurry line between the two, but my Data Access Layers look more like a mess of Transactions Scripts and a Table Data Gateway.

Perhaps, some time ago, I should have studied the Service Layer pattern. I think that by using a combination of this, programming to interfaces, and a proper Domain Model, I can start to see a far more flexible system developing.

It's all falling into place, and I want to write some code to play with these ideas. See if I can write some code that uses a database, yet doesn't require a database to test the application logic. See if I can write Controllers for the domain model, and implement different interfaces from them without having to rewrite either business rules or application control logic. See if I can program all this using Test Driven Development. And, of course, try out the most recent build of ReSharper 2.0.

Perhaps the new job will provide me with this opportunity. I certainly hope so.

*I also hope they've stopped using SourceSafe. I've had enough of it.