Ian Cooper

MVC or WebForms: It's more about client side vs server side

Ian Cooper — Wed, 27 Jan 2010 03:34:00 GMT

Scott Guthrie has posted on the growing debate over Webforms vs. MVC, a debate that seems to be raging everywhere (although there is more that one MVC framework out there too). I agree with Scott's point about the nature of technical debates, and the acceptance that there are different schools of thought. However, that does not always imply that all schools are equally good solutions to a given problem.

The issue has been though I think not solely about the MVC pattern, it is also about the shift from providing rich client behavior server-side or client-side. In this area the renewed interest in AJAX and the emergence of Javascript libraries like Prototype, script.aculo.us and JQuery have been game changers. And for me those RIA paradigms dovetail better with MVC apps than with Webforms applications. At the same time the growth of REST has meant many have re-engaged with the HTTP protocol and its resource oriented model, have turned attention away from page based approaches to web development toward resource oriented ones. There is a correspondence here, because as the use of client side scripting grows so does the perspective of the server as a resource provider used by the client.

It is in many ways this shift of paradigm that MVC supports better and why using MVP approaches with WebForms is not a 'seperate but equal' answer to modern web development. Its not simply about better conformance to Single Responsibility Principle.

What our frameworks do for us

Our average web framework has some pretty basic requirements - handle requests for resources from the server by returning an appropriate response. In our case this is HTML. The simple nature of this model underlies the success of the web.

To support this model our framework needs to route to an appropriate handler in our code that can read the request. Now we could just interrogate that request to pull out post data or query strings, but writing a lot of that code would get old fast, so it helps if our framework can map between form, params and query string values and part of our object model. That way we can manipulate the variables of the request more easily. Now we have to take an appropriate action in response to the request. Generally this is where most of our code plugs in. We get some data and compose a response, in HTML to return in the response. Now just using Response.Write() to output our HTML becomes hard to maintain, so most of us expect our framework to give us some sort of template so that we can separate the static and dynamic portions of our response.

The MVC pattern enters the fray here when frameworks separate the responsibilities of template to provide view, model to provide response to action, and co-ordination between the two for a request. Criticism of Webforms as lacking effective separation cf concerns is because the aspx file is both responsible for rendering the HTML used as a response and providing the controller for the request. It thus has two reasons to change, because the template changes or because the co-ordination of handling a request changes. These may be orthogonal concerns and make maintenance harder. Some patterns such as MVP try to alleviate this by enforcing separation of these two responsibilities within the framework. this criticism is valid but not complete issue; the significance of 'MVC' frameworks is not solely their better separation of concerns.

Now for sure the devil is in the details, but that's pretty much it.

Bare Bones

'MVC' frameworks such as ASP.NET MVC or Monorail ttend to have a bare bones approach to meeting these requirements. The framework takes requests and calls an action to service them, mapping request to action parameters. We then carry out the appropriate task and render html through a view engine. MVC frameworks add little on top of this paradigm. The big win here is that this makes them simple to learn and easy to use, because the surface area of the API is small. The surface area for ASP.NET MVC is smaller than that for Webforms and is easier for new developers to learn. It also works in harmony with http and thus expectations. The principle of least surprise is important to APIs because it makes them easier to discover. Understand the problem and you are likely led in search of the solution.

Rich Internet Applications

Now ASP.NET MVC etc. allow you to return an HTML response, but HTML has its limitations in that it is static. You need to post a request to the server each time you want some new action to occur. In some cases this 'complete form and submit' model works, but we have become used, from smart clients, to a more dynamic model that provides feedback as we make selections. We expect choosing from one dropdown such as country to restrict choices such as US State vs. UK county or Post Code vs. Zip Code.

Out-of-the-box support in web browsers for dynamic behaviour came in the form of Javascript and manipulation of the DOM. The browser is the smart client in this approach. The issue here is that Javascript development was a challenge for many developers and consequently many development shops. Why? Because folks found client side behaviour did not just require switching to another language, but also learning the DOM, which was also sometimes uncomfortably close to metal for developers weaned on smart client Forms frameworks like Windows Forms, VB, or PowerBuilder. In addition the browser wars meant that the model for programming against the DOM was not the same from browser to browser, further complicating the code that was needed to implement a rich client in the browser. In truth it was expensive. Finally the debugging experience was poor. We were back to tracing the state of variables in order to isolate and fix problems in the browser. For many MIS departments writing sites with a rich client, heavy on javascript, was out-of-reach in other cost or skills.

To solve this problem WebForms introduces the concept of server side controls - essentially shifting the rich interaction to the server. The server side control abstracts the html control from the client side. The benefit is that it allows you a development approach familiar to forms based programmers. You set and get control properties and write handlers to react to events. But as the events are raised client-side you need effectively mirror all of the control state from the client side to the server. The problem here is that html does not share this with you on a post. You also need to record the event raised for the server side too, as a post is all you know about from http. This brings in ViewState, which captures all the state which a post is not giving you. But once it is implemented I can provide all that dynamic behaviour on the server, skipping and jumping over issues like knowledge of Javascipt and the DOM, as well as browser compatibility issues.

Of course we can quickly see that with any complex enough page ViewState will grow. As it is embedded in a page it increases the page weight which can hamper performance In addition because we must do an http post to transfer the state of our application back to the server, and then display the response, events are handled by a page refresh. This has the consequence of making the system slower than one which handles the event locally, giving rise to user complaints of flicker or slow response. In addition if you try to cope by adding some AJAX callbacks from your client the question quickly becomes 'who owns this state' as you may have copies of the state both on the client and in ViewData being marshalled back and forth to the server.

Webforms is also a more complex API than MVC and thus harder for developers to learn. Most of us have been at an interview where we have asked, or been asked the question - what is the Webforms lifecycle? Understanding the stages, where viewdata is available and modifiable is not an insignificant learning challenge.

Given that, for some time I used to recommend building applications using WebForms server-side control model over building applications with client side behaviour. Why? Because of the cost and difficulty of building rich client behaviour in Javascript with the DOM outweighed the cost of learning Webforms.

What Changed?

MVC trades the complexity of server side controls for a simpler programming model, supported by client side controls. The emergence of the new breed of Javascript frameworks like Prototype, JQuery, and script.aculo.us, made it far cheaper to code the client behaviour on the client. The elegance and simplicity of these frameworks, their abstraction of browser API differences, and their rich ecosystem of control providers, lowered the barrier to entry for client-side development providing solutions to common needs such as grids . The availability of many free controls lowers the cost of common UI widgets that have often been the preserve of expensive vendor solutions.

In addition the debugging experience for Javascript has significantly improved from the old trace and dump model with browser plugins such as Firebug and Visual Studio.

With a lower cost it has become commercially viable for more development shops to build rich client applications. Best of breed applications do not suffer from the postback flicker issue because they manipulate state locally on the browser and use AJAX calls to the server. With effective client side development, the user experience is akin to smart clients of yesterday, with none of the distribution problems for central IT departments. This rich experience available for the web lies at the heart of the SaaS revolution.

The MVC model truly shines with AJAX where the target for an AJAX call is just an action on a controller. The affinity to http’s resource based model allows for easy definition of the server side support for rich clients. The advatange of MVC frameworks is the ease with which they dovetail to client-code using frameworks like JQuery. Client-side programming is back, using modern Javascript libraries!

It is this, IMO, which has shifted the balance in favour of MVC. I do not think it any accident that the ASP.NET team shipped JQuery with ASP.NET MVC. I think it was essential to shipping an ASP.NET MVC application that a modern Javascript client library was included to support rich client behaviour on the browser instead of server side.

From my cold dead hands

The attitude of many developers may be ‘you will pry Weforms from my cold dead hands’. The march of progress is threatening to do just that. Much of theresistance is based on prior experiences with the cost of client-side development using Javascript, without understanding that the new frameworks available have significantly lowered the barrier to entry there. In addition, Silverlight opens a second front against Webforms by offering rich client development using XAML. If Javascript does not replace Webforms, then XAML will. Server-side controls had their day. They built careers, companies, and fortunes but they are legacy applications now. Client-side controls have returned with fresh offensives that will see their end. If you are building a new web project today you should be looking at an MVC framework.

For my part the question of Webforms vs. MVC is already an irrelevance. That is yesterday’s fight and victory has been declared despite a few units continuing to fight on. The next war is likely to be between Silverlight and Javascript for ownership of the smart client…

Whither Alt.Net?

Ian Cooper — Tue, 19 Jan 2010 13:00:00 GMT

Rage, rage against the dying of the light

The lack of visibility for the idea of "Alt.Net" of late has led me to ask myself the question whither Alt.Net. Or perhaps is alt.net withering? A couple of years ago the alt.net meme had real traction in blogs and events. It had become a cri de coeur for the disaffected members of the .NET community. For many who felt there was a 'better' way, that solid principles and practices that alleviate the pain of some software developers ills were available if you looked up and far enough around, the knowledge that like-minded people were out there gave a sense of strength and purpose. We were not alone in the dark, others like us were out there. At the first altnetconf we ran in the UK, inspired by those in the US, what was overwhelming was the feeling of 'community' between like-minded people who suddenly found others they could communicate with about the ideas that burnt so very brightly within them.

At the time there were warnings and criticisms of the new community. Some reasoned it would become an 'echo chamber'. Other critics suggested that it could be ignored as those involved would just burn out leaving only silence.

Today as I ponder the state we are in I wonder if the critics have not triumphed in there soothsaying over the enthusiasm that once fired our souls. Blogs wane in fire and passion. We seem tired from the fight.

I for one say "Do not go gently into that good night, rage, rage against the dying of the light".

What is in a name?

First I want to step aside from the question about name. David Laribee's original manifesto set out the stall of ideas clearly whatever you want to call it.I think that all these remain true, but perhaps the heart of the movement for me is that "You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc."

Call it what you will. The point is not the name, but the passion for better software development. Objecting to the tag should not blind you to agreement on the ideals. I accept people might not like some of the baggage associated with alt.net. But let's move on and accept that we all agree on the need for a movement that expresses the desire to be ill-content with the status quo, to rebel against the orthodoxy, to rage against the machine.

"There's a time when the operation of the machine becomes so odious, makes you so sick at heart, that you can't take part, you can't even passively take part, and you've got to put your bodies on the gears and upon the wheels, upon the levers, upon all the apparatus, and you've got to make it stop! And you've got to indicate to the people who run it, to the people who own it, that unless you're free, the machine will be prevented from working at all!" - Mario Savio

Is the movement needed any more, and should we just declare victory and bring the troops home?

Scott Bellware recently bemoaned on Twitter that .NET developers doing web development should be using MVC and not webforms. He pointed out that attempts to pander to some developers by suggesting that WebForms and ASP.Net MVC were separate but equal were disingenuous "As more good web devs move to MVC, the WebForms camp looks ever more like paint-by-numbers web development. The shifting demographics of web development in .Net should be a clarion call for everyone to go back into learning mode. The paint-by-numbers crowd is feeling the heat of all the learning that Microsoft told them they didn't have to pay attention to. The amazing thing: rather that pour on the learning, ungodly efforts are being spent on perpetuating uninformed justifications. Dumb. No. Squarely. Definitively. ASP MVC and WebForms are not equals. Here, I'll say it: better web developers use MVC. The ultimate destructive force in .Net development: Microsoft convincing developers not to worry about deepening their skills".

This is not academic. I regularly meet people through London .NET user group that tell me this or that senior developer has blocked use of ASP.NET MVC at this or that company because it would require learning something new. People are still struggling with this issue at development shops all around us. The 'senior' developer invested in maintaing his position through better knowledge of a framework or tool over transferrable skills like patterns & practices shuts down introduction of new technologies by junior developers out of fear that it might level the playing field and bring their authority into question. I hear from junior developers that entrenched senior developers unwilling to learn try to kill attempts to adopt TDD/BDD because they do not understand and worry it will undermine their authority. Further hint, your authority has already been undermined with those junior developers who have long ago worked out that your fear and ignorance is keeping you from implementing. They already understand that it is not genuine judgment that it is not needed in a given circumstance or you have adopted and alternative like Design By Contract.

I still hear people suggest that TDD is too expensive, and yet complain that developers are not producing quality code and they have too much re-work. Hint the cost of re-work is greater than the cost of doing TDD to prevent re-work (or the cost of manual testing to prevent defects exceeds the cost of TDD by a large margin). I still hear people object to story tests but complain about developers building software that does not match customer expectation. HInt, the cost of adopting a BDD approach to building the right thing is less than the cost of re-work from incorrectly fulfilled requirements.

People talk about having adopted agile at an organization but are often practicing cargo-cult agile, scrumerfall or waterscrum or worse agile as no-process at all.

We have by no means won this struggle. It is still being played out every day, despite the fact that the solutions may seem obvious to us.In some ways we have only reached the point of witnessing the creation of evasions, half-truths,and lies as to why such practices are inappropriate to an organization or covering up incorrect adoption.

Alt.Net was always about challenging these 'comfortable lies'. As a community we cannot become content to live with the 'comfortable lies'.

Sometimes effecting change can seem like a war. There are a lot of people who have established comfortable positions for themselves as prophets of a technology and do not want that comfortable home disrupted. Unfortunately we cannot accept the lure of that comfortable position without our skills eroding and failing to keep pace with the wider industry. This necessitates conflict between the prohets of the new and the saints of the old: "The tree of liberty must from time to time be refreshed with the blood of patriots and tyrants. It is its natural manure." If you have not engaged with ASP.NET MVC you need to be, now. If you have you need to be exploring the new alternatives to understand their implicit criticism.

I don't think we can declare victory in any sense. We may be tired of the casualties, but walking away from the fight right now just lets the other side know that they can outwait us. Someone told me a story recently of an IT department that went agile and became extremely productive. But when the thought leadership behind the change, the nay-sayers moved in to crush the agile practices and return to their old safe comfortable world. There is a group that reckons it can outlast the adherents of change and return to mediocrity when those agents tire or move on. You just can't quit the fight if you don't want that to happen.

Did the movement simply become the new orthodoxy

One criticism raised against alt.net is that it would simply become the new orthodoxy. It could be suggested that the decline inalt.net activity is because people have simply become comfortable with a new set of orthodoxies: Scrum, TDD, NHibernate etc, that they will not challenge.

However, nothing stands still. The orthodoxies of Agile development Scrum, XP, and Crystal amongst others, are being challenged. Kanban grows rapidly as an alternative to agile storyboards sometimes provoking debate. The notion that we ahve adopted Scrum or XP and can rest on our laurels is to fall into the trap.

Many find limitations with ASP.NET MVC's implementation, which has led to projects like FubuMVC and OpenRasta let alone MonoRail.

Source control seems to be leaving behind the centralized model of CVS and SVN for the distributed model from GiT.

Many of the people involved in championing these alternatives, championed thier predecessors. So I don't think the movement is doomed to become the new orthodoxy provided it continues to embrace investigating and adopting these alternatives as they emerge. The goal is to do the best we can, and what is 'best' will keep changing. Sure alt.net might pause for a period, absorbing one revolution before seeing its shortcomings and starting another, but I don't believe the community incapable of moving forward, mired in some new orthodoxy.

Did we scratch the itch of 'people like us' and just move on to Twitter?

There is a danger that the biggest need we had was to feel less alone, and once we found people who thought like us moved into an echo chamber where we could moan about everyone else. In some ways Twitter is the ultimate example of this echo chamber. We can follow like minded people and hold conversations with them, ignoring everyone else.

I like Twitter, please don't get me wrong. It has enabled the kind of informal social activity for altnetuk and the London .NET user group that I found difficult to support through mailing lists. But a lot of the discussion around practices, tools, ideas seems to have moved there. Twitter has become a great radar for seeing what folks think is important and interesting out there that merits further research. However, I think there is a danger for the community here for two reasons.

First Twitter is a passable medium for conversation, but not a good vehicle for a comprehensive discussion of ideas. The length of tweets is too limiting, the ability to construct argument too limited. I am as bad as anyone for having spread a reply or opinion across a half-dozen tweets. But we should recognize that Twitter is ineffective at explaining complex ideas. It's great that snapshot comments have somewhere to go and don't crowd the blogosphere, but we need to continue to blog or write articles about the ideas for clarity.

Second Twitter relies much more on you knowing about the person with the key ideas and following them. Blogs are easier to find by searching, or by following links. They have far more discoverability. The rise of blogs represented a phenomenal democratization of software development knowledge. Previously such knowledge had often been hoarded by cliques as an exploitable resource through books, training, or consultancy. Blogs shared knowledge in a way that meant best practice ideas were widely available. The danger is a drift back to cliques as bloggers, tired of criticism, return to narrow cliques to disseminate knowledge and practice. Ultimately this becomes self-defeating and prevents wider acceptance of standards and practices.

The danger of Twitter becoming an echo chamber is far greater than the danger of blogs becoming such. So I believe alt.net needs to continue to blog to reach out beyond the echo chamber. But more than this, alt.net represents confort and support to other people making the journey. All those developers looking for someone to say 'I believe in being the best developer that I can' too'. That moral support can mean a lot to people struggling with obstinate colleagues and managers. It can mean a lot to point to a group and say "but I'm not the only one that thinks this way".

Was struggle replaced with co-operation

We might be hopeful and consider that it is possible we moved from opposition and rebellion to cooperation and inclusion. Did we achieve its goals and simply become incorporated in the mainstream. Is the rise of ASP.NET MVC, MSTest, POCO options for EF just a sign that the movement has been incorporated in the mainstream? Whilst I think engagement is positive, after all it is the only way to succeed and driving change, I don't think that engagment means there is no need fo alt.net any more, because I think the movement was about more than just a few "poster-child" issues. I also don't think it is about rebellion against co-operation with MS or anyone else. I think it is about driving forward the quality of our own practice.

Software Craftsmanship

Many of the ideals of Alt.NET seem to be shared with the Software Craftsmanship movement. In some ways Software Craftsmanship seems to be the generic form of the alt.net movement. For me key texts in Software Craftsmanship are those like The Pragmatic Programmer, Software Craftsmanship the New Imperative, Clean Code, Agile Principles, Patterns and Practices in C#, Test Driven Development By Example to name just a few. Indeed the XP movement could be seen as a call to craftsmanship.

I talked about the asset of looking back to craftsmanship for models when talking about master builders instead of architects back at the beginning of 2008. One quote from Goldthwaite is worth repeating

"a mason could operate as an architect only if he became head of a works staff. ...he had to prove himself also as an administrator and supervisor who could be responsible for procuring materials and equipment, hiring and supervising workers, and, in general, directing all the technical operations of the construction enterprise".

This idea that a journeyman becomes a master by understanding the whole enterprise is particularly appealing as an ideal. You cannot just focus on code, you need to understand the whole enterprise of construction.

I think that the manifesto is something that many who consider themselves alt.net would agree with. It is also an indication that the passion to improve on a community's existing practices does not reflect unique problems in the .NET community but is parter of a wider agenda in the software development community to improve the standards of our industry.

I'm not proposing dropping the alt.net moniker in favor or Software Craftsmanship. The Software Craftsmanship movement has specific goals and practices which align with alt.net, but it is not alt.net. What I am suggesting is that the alt.net movement intersect with broader movements like software crafstmanship. I think that engagement with broad movements like Software Craftsmanship would help many of us to broaden our horizons to the initiatives within the wider software community to improvement. Attending dojos or katas for different languages would help us all. I don't think alt.net engagement needs to be replaced by Software Craftsmanship engagment, I think membership of both communities should not be orthogonal or exclusive in our minds at all.

Wither ALt.NET?

So I don't think Alt.Net needs wither or be replaced by something else. I think its spirit ou’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc." remains alive. I think the value in a community that supports those who practice that within the .NET community remains, even if needs to re-invent its passions on a regular basis.

Where is the next Access?

Ian Cooper — Thu, 19 Nov 2009 17:26:00 GMT

Ted Neward recently posted a response to a talk by Biily Hollis, and asked "Where is this decade's Access". I think it is a great question, if only because I asked Scott Guthrie practically the same thing the other week.

Like many of the people Ted refers to, I started my professional career in FoxPro (I always find it amusing that productivity aspects of that tool, such as manipulating data as part of your 3GL, has only made it into the mainstream with LINQ To SQL, many years later). FoxPro had a passionate following, indeed I have heard it suggested that much of what we consider developer community today, was started by the FoxPro user base. For a whole class of scenarios, particularly a small workgroup of about a dozen users, FoxPro made it very quick to rapidly code and deploy applications. Even Visual Basic and Access, those other poster children of the 'long tail' (as Ted puts it) developer market, did not have the capabilities that came with FoxPro for many years. FoxPro was ideal for applications that were essentially CRUD based. FoxPro was one of the XBase family of programming languages, a basic derived dynamic language but with a heavy slant to data retrieval and manipulation. When I used it, there was no RDMS attached, but the flat file DBF data format. In many cases that was ideal our customers could not support the RDBMS solutions available at the time, and utlizing a file server was the easiest way to a networked database. Fox was an ideal tool for the time, when PC applications targetted less than a dozen users working on a LAN.

I have to agree with Ted's assertion that today, professional development tools, targetted at RAD application of solutions for small businesses do not seem to engender the same passion and commitment that FoxPro once did. Nor do they seem to offer the same productivity. And that may be a gap, because there is probably still a market for applications that target a dozen people in a workgroup.

Now before anyone worries I'm not about to have some damscence conversion to point-and-click development. When I used it FoxPro was certainly not a point-and click too anyway. But there is still a place for a toolset that makes it easy to knock up CRUD based sites. In a previous post I talked about DDD's idea of strategic design, dividing up into generic domain, supporting sub-domain, and core domain. RAD tools are often ideal in the supporting sub-domain development (by duct tape programmers).

A lot of the Ruby enthusiasts I meet seem to love Rails for exactly the same reason I loved FoxPro. The ability to knock out usable applications quickly and with little fuss, yet still produce something professional. Rails works 'out-of-the-box' to deliver CMS like systems to a wide range of customers. No one is suggesting the Rails crowd is dumbed-down, but their tools do embrace simplicity. 37 Signals embraced the principle of keep it stupid, simple, for Rails to enable folks to build just this kind of applicaiton easily with configuration and outright reject attempts to add complexity.

So when Ted talks about simplicity he is chanelling the spirit of the Rails crew with their focus on keeping it stupid and simple.

The closest thing we have today would seem to be ASP.NET MVC with jQuery and LINQ-To-SQL. That MVC should that level of simplicity may be no suprise because both it and Monorail take influence from Rails. Both pick up on the cleaner abstraction of MVC over the page controller approach that WebForms uses with its byzantine server side control model. I would agree with Jeffrey Palermo that the triumph of MVC is of simplicity over features. Still MVC lacks some of the convention-over-configuration that gives Rails its edge. LINQ-To-SQL wins by a simple ORM. In this field its shortcomings when compared to NHibernate are its strengths, it is simpler and therefore more approachable to a mass audience. Finally jQuery makes JavaScript programming approachable, without the kind of effort that made dynamic behaviour on web sites so expensive in the past.

The question is whether there is the commitment to take this combination forward or not from MS.

The catalogue metaphor and command-query seperation architectures

Ian Cooper — Thu, 08 Oct 2009 07:47:00 GMT

Command-Query separation is being popularized today with architects like Greg Young and Udi Dahan as a way of architecting systems. It can be hard to grasp as a concept, even if we understand command-query seperation as a design pattern that influences the methods on our classes. It can be difficult to see how the principle scales to the level of architectures.

Pat Helland's article Data on the Outside vs. Data on the Inside remains key for me in trying to understand this model. Pat distinguishes between operators and operands. Operators are commands, things we can do like order a meal, or order a book. Operands are the data that we use for that command. So order a Thai Green Curry, or orderDan Bropwn's The Lost Symbol. This implies that we have to publish those operands so that people can discover them to use in the command. A way to think of this list of operands is as catalogue data.

I find that the XP idea of an architectural metaphor helps me to understand the seperation between operator and operand when architecting a solution.

If I want to order a take-away from the Thai restaurant I need a menu that tells me what they deliver and how much it costs. The menu is not the food itself, it’s just an number, a name, and a price I can use to order the food with. Catalogue data has some interesting characteristics such as often being cacheable because it changes infrequently, or being versioned if we can deal with different varieties of it. But the key to this discussion is to appreciate that in order to carry out the task of ordering a takeway I need first to have a menu that lets us communicate about what I can order. In patterns terms I need to query for the food menu, and then issue the command to order the food.

Now in software we have the same need to present a user with catalogue data so that they can carry out a task. We have to tell them what operators are valid for our operands. This is where the query side of command-query comes in when thinking about command-query architectures. The query builds the catalogue - it grabs the list of acceptable operands for our operators.

This is often easy to comprehend in the context of MVC architecures. When I get a request for a page that allows you to perform a task, I want to populate it with my operands. For example, if I want to enable the task of ordering food I need to give you a menu. I do not want to load my food or customer entities for this, because all I need is the name for you to display in a pick list (and possibly an id). When you perform the task, ordering the food, then I may need to load the customer or food entities from their repository, create an order entity etc.

Now the nature of the operands creates some interesting opportunities architecturally. At the simplest leve, instead of using repositories we might just use queries. I think this is some of the answer in the repositories vs. queries debate - it also explains why FindAll on a Repository is often seen as a smell, because we are using to obtain a collection of catalogue data and that is not a repository concern. We might use a different strategy altogether to make these queries such as NHibernate report queries or even ADO.NET (In a previous project we created a generic DataRader for reading objects with an ID and Name, called a SmartReference that we passed a stored procedure to load our catalogue data and then loaded into picklists). The objects you deal with here will often be anaemic, exactly the kind you fear in your domain model. But that is fine here, you are not creating domain objects but the operands for the operations you will perform on the domain. Some will indeed be catalogue data for items within your domain, and you load the full object in response to the command.

We might even query against a different relational store to obtain our catalogue data. This may simply be to reduce load, but it might also be because our catalogue data might be published to this store from another application. In that case the catalogue data might well not be consistent with the current state of the publisher, if there is a delay, so our catalogue data might even be versioned.

The important point is to realize that an application may have a healthy mix between domain data and catalogue data, and should handle each appropriately.

Beating the duct programmer with generic domains, subdomains, and core domains

Ian Cooper — Mon, 28 Sep 2009 03:27:00 GMT

There has been a certain amount of noise and comment around Joel Spolsky's post on the duct tape programmer.

This is, for me, just another manifestation of the hero coder - the guy the business love because he 'gets things done'. He is the guy who is turning out the features to the customer while you are still implementing top down from your acceptance to your unit tests. While you are trying to build a domain model, focusing on the ubiquitous language, and trying to create a model expressed in software, he has hacked out some procedural code that just works. While you create your ORM mappings in Fluent NHibernate, his DataReader has grabbed everything he needs from a custom stored procedure and pumped out the web page. In the customer's eyes he is responsive, he gets their needs, and you don't.

The trouble with the hero programmer is that the customer does not know he uses duct tape, and your explanation of why it is an issue anyway is so complicated they lose interest. The truth is they just don't care about your engineering principles. And the worst of it is that he will go on to write new features, while you fix up his last duct-tape special, because he is the guy the customers want, the hero programmer. He is the guy they think of when they used the word agile - responsive, adaptable to new requirements.

Eric Evans has a fair amount to say about engineers being beaten by the duct tape, or hero programmer, and how those of committed to strong engineering priniciples can thrive in this presentation. We talked this over at our development book club, con-incidentally the day after Joels' post broke.

The presentation draws on the 'second-half' of the DDD 'blue' book, , the Strategic Design section, a part that is tragically overlooked in favor of the patterns in the first. Tragic because some of the strongest insights of Eric's work are in this second half, but everyone focuses on aggregates and repositories in the first.

The key idea here is that we need to focus on dividing our solution up into three areas: generic domain, supporting subdomain, and core domain.

Generic Sub-domain: This part of the software can just be bought off the shelf, or found from open source, because it has become ubiquitous and is comoditized. It might be a generic application such as accounts, document generation, CRM, ERP. It might be a generic framework such ORM, RDBMS, Reporting etc. Your customers are not doing anything here that gives them competitive advantage. In some cases they make want to work in a different way to that supported by the generic software; even so, in this case there is no return on supporting their way of working, so they need to conform to the generic model. Note the inclusion of both inftrastructure frameworks and applications. You might think you can build a better ORM or BUS, but unless your customer gains competitive advantage from that, do not tackle it.

Supporting Sub-domain: This is not commoditized, but your customer gains very little here. There is no special sauce, no clear case on return on investment. Identifying this area can be hard, because this is often specific to your customer's domain, and you can't find it off the-shelf. The key is that there is little competitive advantage to this code. The code here might be non-customer facing admin utilities such as user administration, but it also might be code that faces your customers, but provides little competitive advantage for you to get right. This is an area where use an off-the-shelf model if one exists. It is the area where you might outsource your requirements. It is the area where you deploy your hero programmer, because you just need it done and you don't care if it is done with duct-tape. Often when there is change here your strategy is just to throw away your existing implementation and start again. This is highly disposable code.

Core Domain: This is where your customer gains competitive advantage. it is where custom development has a high return on investment. This is where you deploy your best programmers to build a domain model, make sure you use disciplined engineering approaches like automated tests and CI. This is where you don't deploy your duct-tape programmer, you are worried about total cost of ownership here, because you don't want to throw this code away and start again. It is a strategic investment.

The core domain is almost certainly not the whole solution, but perhaps more suprisingly it may not even be a whole application. If your cutomer's special sauce is a better rating, shipping, or pricing algorithm then that is your core domain. The web site that collects the data which you pass to that engine may not be - it might just be a supporting sub-domain your hero/duct-tape coder hacks out for you while your engineering team focuses on the core domain.

You may well need an anti-corruption layer between your core domain and generic and supporting sub-domains, to prevent their model bleeding into your domain model. That anti-corruption layers also allows you to be defensive to quality concerns.

The key here is working smarter, figuring out where the team focused on a costlier but disciplined engineering approach, can get return on the investment. With this approach you get to deliver the parts that make a difference to the customer instead of expending your effort on the supporting infrastructure.

We watched Eric's presentation above for our Developer Book Club and the war stories agreed with Eric. This pattern seems to be ubiquitous and we need to fnd a smarter way out that simply sticking our heads in the sand and denying the problem while pursuing an 'ivory tower architecture' that the customer will never remain committed too.

Agile is never 'no process'

Ian Cooper — Fri, 11 Sep 2009 08:19:00 GMT

David comments that agile is about discipline. I could not agree more.

Having encountered organizations that failed in a previous attempt at agile, one consistent story seems to be that agile was brought on board as a developers initiative in response to 'lack of process' complaints. However, agile seems to have been chosen by those developers as an answer not to up their game, but to give them an excuse for continuig with a low discipline approach to development. It's the agile as a pseudonym for "we don't want no stinking engineering practices paradigm". It is for me, a big reason why agile has a bad name with some CTOs.

It is usually a shock for developers at those organizations when they encounter genuine agile, with a high-discipline approach to software engineering. That is not what they believed it to be. A lot of them balk, commenting that the high-discipline approach cannot be agile, because it seems to involve them in a lot more software engineering than they were used to. A lot of them resist BDD style approaches as taking time which they could use to deliver, at planning and retrospective sessions as getting in the way of 'writing code'. For them agile means 'everyone gets out of my face and I hack code as fast as I can'. There is often a corollary here with developers who have a background in waterfall projects that get handed over the fence once live. They never had to support the project once delivered, so only care about 'time to market' over 'cost of owneship' so cannot see the value of these practices.

The problem here is usually predicated not by classical waterfall approaches but organizations with homebrewed approaches to software engineering. (By homebrewed by the way I don't mean the adapt the methodology to fit the project approach of the Crystal family, I mean the voodoo like approach of a collection of rituals to software delivery whose purpose or origin is usually shrouded in time or some incident). The term agile refers to the ability of the methodoligies to react to feedback, not their process cost by contrast to those homebrew approaches to development.

The problem her eis often that the term agile (or even lean) don't recognize the fact that these homebrew methodologies are usually lightwieght and that agile practices seem heavywight by comparison. Some term that implies high responsiveness to feedback might well have been better, because it is more honest at describing their benefit.

It's turtles all the way down

Ian Cooper — Fri, 11 Sep 2009 07:14:00 GMT

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

Classically an ORM persists an object model to a relational model. Typically just use it to retrieve or persist the state of the objects in our model, not provide integration through models. Though obviously there is some translation between the models in the act of persistence, the greater distance between the two models the greater the effort we have to expend on the persistence mapping.

This becomes an issue when we are tempted by using a shared database schema as a mechanism for system integration. The approach is simple in concept: two systems with differing models, communicate by virtue of the fact that they share a relational schema. In Hohpe's Enterprise Integration Patterns, Martin Fowler calls this integration style Shared Database. The two systems don't exchange information, they share information.

Shared Database seems an attractive way to integrate systems within your enterprise at first. You do not have the complexity multiplier of distributed systems and the skills sets required to make them work. Corporate MI does not have to map between models to report, it just points to an reporting store created from the shared repository (or in poor implementations to the transactional store itself).

There are a number of problems that flow out of shared database approaches.

The applications have both data and behaviour. Interpreting what a field such as premium means to source systems often requires an understanding of the behaviour to eliminate ambiguities. Is a field called premium net or gross of tax, for example? Looking at the source system may be required to determine the properties of the field. The source system will also contain rules about the validity of records, information that we often can't capture with constraints. We can try to work around this by ensuring that we document the usage along with the schema, but documentation tends to fall behind a system which leads to an insidious growth in inaccuracy. If we are to create a schema that multiple applications can use to store their data, we need to remove any ambiguity. If that was not hard enough, we need to have a schema that is both a superset of all their data, and this often makes the representation complex. Those complex representations are not just hard to comprehend, they often perform badly.

In addition the database schema now has multiple owners, so we need to negotiate how changes to the model impact consumers. We might have an adequate test suite to allow us to use continuous integration, but often the systems involved in shared database include legacy applications that have no such ability to understand the impact of changes across all consumers of the model. That makes change very expensive and so tends to lead to software atrophy as we are no longer able to keep our software in synchronization with business needs.

These complex models prove difficult for developers and domain experts alike. Domain experts may find that they do not represent the model of the problem domain. In Domain Driven Design (DDD) terms we have two bounded contexts, the model for the application and the model for the shared database. The developers is then confronted with some unpalatable choices. Does he conform to the model in the Shared Database, hydrating an object model that is essentially an OO representation of the ER model? This will prevent him from using the principle of ubiquitous language to share the same model as the domain expert within the implementation of the software. This is not just an academic issue, it becomes a significant overhead to translate the requirements from the domain expert to their expression in the model, and is often lossy and error prone. Even something as simple as responding to a live issue becomes more complicated when the model bears little relation to the problem experienced by the end user. "My broker's address details are not being refreshed correctly" becomes much more complicated if you do not have an entity called broker in your system but a Party with a PartyRole of Broker. Someone needs to understand the translation to solve the issue.

So it can seem tempting to try and use our ORM tool to elide this problem, by mapping from the ER into the OO model. After all an ORM tool allows model-to-model mapping, so why not leverage it? So ORM tools such as Linq to SQL are not really sophisticated enough to handle this kind of translation. Others are though and this kind of sophistication can be tempting. Indeed, this seems to me to be one of the supposed benefits of the EF is its ability to put some kind of anti-corruption layer between the relational schema and the OO model.

The problem is that this leads to a growth in complexity that seems contradictory to our supposed benefit for using shared database, low cost, in the first place.

Eric Evans points out in Domain Driven Design that:

"Technically, the relational table design does not have to reflect the domain model. Mapping tools are sophisticated enough to bridge significant differences. The trouble is, multiple overlapping models are just too complicated. Many of the same arguments presented for MODEL-DRIVEN DESIGN—avoiding separate analysis and design models—apply to this mismatch. This does entail some sacrifice in the richness of the object model, and sometimes compromises have to be made in the database design (such as selective denormalization), but to do otherwise is to risk losing the tight coupling of model and implementation." - Eric Evans, Domain Driven Design

The danger with better tooling is that it can sometimes make approaches that we once have found to difficult to swallow seem more digestible. However, just because the cost to implement drops does not mean that the cost of ownership drops along with it, in fact it often increases.

Try to keep the idea that it is ‘turtles all the way’ down and keep the design of your relational model the same as your object model. In addition, avoid the use of shared database as an integration strategy within the Enterprise and prefer messaging. What you gain in implementation cost you will lose many times over in ownership cost.

Agile Fails Better

Ian Cooper — Tue, 14 Jul 2009 08:57:00 GMT

One overlooked aspect of agile is that it fails well. People tend to talk about this obliquely referring to the feedback mechanism as being an important part of the agile process. I suspect the reason is that people do not like to talk about project failure when discussing agile; because, they want to give the idea that agile is somehow innoculated against failure. I believe that agile is instead better at reducing the damage of failure and increasing the chance of recovery from the failure. The goal in agile is to fail fast, when you can still react positively to that failure. Now I would agree that 'agile engineering processes' (really just 'good enginnering practices') can help reduce the chance of failure, but no project is immune to failure or atl least being considered challenged.

Consider a project that requires six man-months to deliver. Let us presume, for the purpose of argument that this is two months each of analysis, development, and testing regardless of our decision to use a waterfall or agile approach. Under a classic waterfall model we would plan this as two months of analysis, followed by equal periods of development and testing. Under a classic agile model we might plan this as twelve iterations of two weeks. Now assume that we are going to uncover an architectural problem during QA that we do not see in developer testing. Under the waterfall approach the earliest we are going to learn about this would be 4 months into the project when we begin testing. More likely we might find it 5 months in or later. Under an agile project we might find this within two weeks. This is especially true if we plan our iterations with an early release targetted as walking skeleton (Lean calls this a spanning application and the Pragmatic Programmers a tracer bullet). If we had opted for an initial walking skeleton release with agile iterations we could have flushed out architectural failures early.

If I fail within say six weeks as opposed to within five months I dramatically increase my range of options. I could decide to abandon the project. Because my sunk costs are probably lower my capacity to walk away improves.

Early failure is positive for more than just avoiding waste here. It is useful because it modifies my perception of risk. Because my risk is lower I may feel more able to make the decision to begin a project, so I may spend less on 'due diligence' up front, increasing my ability to sieze market opportunities. I also have much more ability to assess what is wrong, re-plan and re-commence, because telling the customer this far in advance of any delays or increased costs gives them much more ability to react. Especially if the customer knows that I am trying to get the suprises out of the way up front.

Kent Beck said in an interview with ComputerWorld

No. I think software projects are still going to fail because there still [will be] the promising ideas that don't work out in practice. One thing that agile development can give you is to make sure those projects fail faster, sooner, cheaper, so you can get on with the next thing

Embrace Pain

Ian Cooper — Tue, 07 Jul 2009 11:38:00 GMT

Agile is about surfacing pain. It's not about roses, perfume, and happy candlelight dinners together. Traditional project management methodologies made it easy to sweep the pain under the carpet, lying about how you were doing up until the end of the project, when you hoped everything would just go away emerged to haunt or kill you. Traditional project management methodologies are all about denial. Why do predictive methodology plans fail so often? The release plan correctly goes out of alignment with the reality. A task overruns, a task underruns, a dependency holds up delivery. Sometimes people re-plan, but the effort mean most just ignore it, burying technical debt to stay on track, ignoring opportunities to take on more work, lying to their stakeholders about where they really are. Agile uses an adaptive approach, because that allows you to surface the truth about when and where things are failing, or where there are opportunites that could be exploited.

Being agile hurts. It exposes you before your peers with all your insecurities, wounds, failures and weaknesses. But accepting those problems lets you take steps to fix them.

So if you think you are an agile project and you are not constantly surfacing nasty, miserable pain, then you might not be doing it right.

What are generally called agile development processes are best practices for fixing the pain that agile can surface, without creating more pain in turn. Now Scrum gets a lot of ragging for not including engineering processes. But I think that the point here though is that heart of Agile is about the surfacing of those problems, not the fixing of them. We want to fix them, and you may want to go to your XP, Crystal or Scrum library and pull out remedies for your pain from those cupboards. You might even want to vaccinate your project from them. These engineering processes are in important part of your methodology, but they are a response to the pain that agile surfaces. You do continuous integration because you don't want the pain of integrating code streams after days of effort, or taking several days to do the build.

The key to agile is that you are bringing down the pain. Because then you can deal with it.

I suspect that the reason a lot of Scrum implementations seem to be failing is because the attitude of those using them is to hide the pain, not to surface it. That is self-defeating, but emerges because the stakeholders of the organization become scared when they see so much pain early in a project's lifecycle. They are not used to that level of honesty. So they think something must be wrong. In fact something is terribly right. However, you have to set expectations to understand that you intend to bring down the pain so that you won't be finding it all when its too late or too expensive to do anything about it.

Everything always done , every sprint always 100%, no defects? These are often lies we tell ourselves to defer the day of reckoning. Maybe you're getting it right, but don't lie to make it look like success, because it isn't.

Making your code easier to understand context/specification style unit tests

Ian Cooper — Mon, 29 Jun 2009 04:08:00 GMT

When we started our current project we did not use context/specification style testing, instead we used testcase-per-class with a four-phase test model (also known as arrange-act-assert). Although we followed story-test driven development (STDD) we were not explicitly Behavior-Driven Development BDD when we set out. Over time I began to see the path between STDD and BDD we shifted toward a BDD approach.

That is really background for what comes next. As part of this shift we started writing more context/specification style tests. We did not re-write our existing testcase-per-class fixtures (then and still now I would see the possibility of using multiple test organisational patterns within a project; some of our tests still seem better with testcase-per-class). Recently we have had new developers join the team. One interesting, if anecdotal, observation has been that those developers find it easier to use tests as a source of documentation for what the software is doing when they are in the context/specification style. This is a useful observation, because the rest of the team is able to supply much of the context for testcase-per-class fixtures by virtue of having worked on the codebase and so do not see the lack so easily.

To build a maintainable system you have to build one where the behavior can be understood. Tests offer this promise, but often we have found that tests failed us, because the tests were no easier to comprehend than the code under test. Context/specification style tests seem to be better on this account. Of course there is no silver bullet in software. You still have to put the effort into making your context/specification tests readable, but the form seems helpful toward achieving that goal.

I'll try to post more on my experiences with BDD style approaches as they come out. I would also recommend that anyone interested in the topic look at the RSpec book from the Pragmatic Programmers which offers a great overview of the topic.

Should you learn frameworks or principles

Ian Cooper — Thu, 11 Jun 2009 02:12:00 GMT

Normal 0 false false false EN-GB X-NONE X-NONE MicrosoftInternetExplorer4

There was a comment on the On Learning Boo post along the lines of : I only focus on learning frameworks, because they increase my marketability, learning new languages, ideas like DSLs just takes time away from that effort. It is a fairly common attitude. I have spoken to people who have told me that their focus is on learning the Microsoft .NET toolset, commenting that they feel that is enough of a challenge and one that translates best into career opportunities. I have seen recruiters and companies assessed with statements like 2 years of ASP.NET MVC as some means to indicate the competence of a developer to join a team.

At the same time for many developers the number of new frameworks tumbling out of Redmond makes it seems like a struggle to keep up. Those who feel that they must keep up, naturally feel overwhelmed. Restricting their focus to just what comes out of Redmond seems like a good strategy to manage the problem. Unfortunately, focusing on learning vendor frameworks is a trap. There will always be another new framework to learn to do what you were doing yesterday. Look at the churn in data access frameworks in the Microsoft space. Knowledge gained is quickly outdated. You end up on a treadmill, learning one vendor framework after another. You fall into the trap of appraising your next job solely on the criteria of what frameworks your prospective employer is using, just so that you can gain some experience using that new framework and keep your C.V. up to date.

Assessing developers by their knowledge of them, especially through certifications is an equally bad trap for employers to fall into. At best it is deceptive about what skills developers actually need. At worst it is a prison because the investment of knowledge in a particular technology becomes a ball-and-chain that makes individuals and corporations resistant to change. Having hired all those skilled Webforms developers and learnt all those vendor control kits, how could you rationally adopt ASP.NET MVC for your next project? After all you don't have any experience with it. Should you now dismiss your entire team and hire experienced ASP.NET developers? Or if you do change, what good did it do you to recruit people based on their understanding of the ASP.NET page lifecycle. Would it not have been better to hire people who had the skills to learn new frameworks?

When I was younger, I used to focus on learning the latest toolkit because I saw that as the best way to improve my marketability. I spent ages poring over the internals of MFC, ATL etc. I could talk about the details of the STL, Boost, Loki with the best of them. I wanted to be an expert on those libraries. I looked for new jobs when old ones did not offer me the opportunity to use the latest and greatest frameworks. Did it make me better developer? Maybe, but not in the way I expected. What I gained from poring over those frameworks eventually was an appreciation of the common underlying patterns. I might have learned something from understanding how the internals were implemented too, but it was pattern recognition of ideas like iterators, factories, template methods that gave me the most benefit. The next time I tried to learn a library, seeing how it solved problems I understood, seeing how it use patterns and principles I recognized, meant that I was able to being working with the framework faster. But I did this hard way, not by recognizing patterns I was aware of and seeing where they were implemented, but by discovering them seeing them repeated.

The reason so many of us get excited by books like Fowler's Patterns of Enterprise Application Architecture, his work on GUI Architectures of DSLs (and the work of others) is that they capture those patterns and principles. A solid knowledge of the principles relating models, views, and controllers would enable you to learn a range of web frameworks ore quickly because you look to see how they solve problems.

Learning new skills such as how to write a DSL in Boo will give you the breadth of aproaches that enable you to deliver better architected applications. The burden of maintenance is greater than the burden of writing, so a better architected application is always a good investment for a company. Far more than squeezing some obscure feature out of your latest framework is.

If anything the industry has moved on from those nuts and bots frameworks, and the abstractions have gotten better. Less and less do you need to understand the how and more and more the why? Knowledge of the patterns and principles provide continuing value to you as frameworks change. It also helps you understand how to use the frameworks, how to judge their quality against some kind of best practice yardstick and how to manipulate them when they fall short of best practice

As someone who interviews people I look more for understanding of the principles than the minutiae. The problem is that there will always be a new 'better' framework, a new popular paradigm. There is always the possibility that a new language comes along that we want to use instead for a given project. People who understand the principles can adapt. People who focus on the detail are intransigent to change, because they have too much invested in the framework that they have become an expert in.

Now before someone suggests otherwise I am not implying that people do not need to know how to use their tools to get the best out of them. Of course they do. But you will find a more efficient path to assessing and learning new frameworks through understanding the principles behind them than through learning each one in isolation.

Introduction to NHibernate, pt. 7

Ian Cooper — Thu, 04 Jun 2009 03:56:00 GMT

In earlier parts of this series we looked at mapping via XML mapping files. I wanted to look at some alternatives to the angle bracket tax. First up is the Castle project's Active Record. Next time we will look at Fluent NHibernate.

Active Record Support for Attribute Based Mapping

While mapping via an xml file allows access to the full range of options that NHibernate gives us, it can be slow, because it forces us to context switch between C# and XML. Both NHibernate and Castle have attribute mapping options. NNHibernate.Mapping.Attributes is an add-in for NHibernate contributed by Pierre Henri Kuaté. Active Record is part of the Castle project, originally intended to support the Active Record pattern favored by Ruby On Rails.

We'll just discuss how to use Active Record's Attribute Support here. Essentially ActiveRecord contains attributes that are the equivalent of elements from the mapping file. For example to map the Customer class we mark it up as follows.

Adding the required references

We need to reference a number of assemblies to get ActiveRecord support:
Castle.ActiveRecord.dll
Castle.Core.dll
Castle.Components.Validator.dll
Castle.DynamicProxy.dll
NHibernate.dll

We also need to change our configuration file to configure ActiveRecord instead of NHibernate (ActiveRecord configures NHibernate from this information). We an configure either by a stand-alone xml file or through the app.config. For simplicity we configure through the app.config file here.

We need to add a config section handler for the active record section of our configuration file:

    <configSections>
        <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" />
    </configSections>

The configuration mainly tells NHibernate how to access the Db. There are two key attributes of the <activerecord> element. We need to set the IsWeb attribute to true if we are an asp.net web application. We need to set the IsDebug attribute to true, if we want to see the generated mapping files (see below).

Note that when working with NHibernate 2.0+ the sample code given on the Castle site for Active Record uses incorrect key values that are prefixed with NHibernate. You need to change these to omit the "hibernate." from the name. If you forget to do this you will get messages about invalid key from log4net. This is because the hibernate.* keys are no longer in the schema.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
    <section name="activerecord" type="Castle.ActiveRecord.Framework.Config.ActiveRecordSectionHandler, Castle.ActiveRecord" />
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
</configSections>

<activerecord isWeb="false" isDebug="true">
    <config>
      <add
          key="connection.driver_class"
          value="NHibernate.Driver.SqlClientDriver" />
      <add
          key="dialect"
          value="NHibernate.Dialect.MsSql2000Dialect" />
      <add
          key="connection.provider"
          value="NHibernate.Connection.DriverConnectionProvider" />
      <add
          key="connection.connection_string"
          value="Data Source=.;Initial Catalog=nhibernate;Integrated Security=SSPI" />
    </config>
</activerecord>

<log4net>
    <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender, log4net">
      <layout type="log4net.Layout.PatternLayout, log4net">
        <param name="ConversionPattern" value="%m" />
      </layout>
    </appender>
    <root>
      <priority value="DEBUG" />
      <appender-ref ref="ConsoleAppender" />
    </root>
</log4net>

</configuration>

Using attributes to peform our mapping

We mark the entity with an [ActiveRecord] attribute to indicate that we want NHibernate to persist it. We can add the table name if it does not match the entity name [ActiveRecord("MyTableName")]. We can indicate that we want the entity to be loaded, by adding the Lazy attribute as in [ActiveRecord(Lazy=true)].

We can declare that our class inherits from ActiveRecordBase if we want Active Record pattern semantics, i.e. the entity knows how to retrieve and persist itself. We want true seperation of concerns, so we do not intend to mix CRUD mechanics with our entity. For this reason we do not derive our class from ActiveRecordBase.

We mark up the identity of our entity using the [PrimaryKey] attribute. The default primary key type is native, so we do not need to mark this up, but if we have a different strategy then we have to explicitly indicate that. For example to use a GUID we would use: PrimaryKey(PrimaryKeyType.UuidHex, Params="format=D,seperator=-")]

We can mark up a property using the [Property] attribute. In addition, we can use [Field] if we want to map a private member of the class. If we need to map to a column with a different name to the property then we can pass it as a parameter to the attribute [Property("MyColumnName")]. If we have a large object then we can set the column type - see the the Active Record documentation.

We use a [HasMany] attribute to represent a one-to-many relationship, attributing the collection on the parent class i.e. [HasMany(typeof(Post), Table="Posts", ColumnKey="blogid")]. We use the RelationType enumerated value to specify the type of the relationship i.e. RelationshipType.Set. We also set the Inverse parameter as part of the HasMany attribute if this is a bi-directional relationship to avoid generating the insert and update statement, and creating an insert only. We can indicate if this relationship should be lazy-loaded using the Lazy parameter on the HasMany attribute. As with XML mapping we can also set the action NHibernate should take when we update or delete the parent using the Cascade option. In addition, we can set the index if we use one of the ordered types for our relationship or the sort order.
We use a [BelongsTo] attribute on the reverse side of the relationship to indicate a Many-To-One relationship. We need to pass the name of the foreign key column as a parameter to the attribute. Again there are options that reflect those available from the xml mapping file.

ActiveRecord also provides support for more advanced scenarios that are outside the scope of this article (it is meant to be an introduction and most of this is documented elsewhere):

HasAndBelongsToMany
OneToOne
Any and HasManyToAny

ActiveRecord also supports inheritance, supporting both the table Table-per-class hierarchy and Table-per-subclass strategies.

Mapping the Table-per-class hierachy strategy is straightforward, just set the parameters on the superclass ActiveRecord attribute to indicate the discriminator column to use i.e. [ActiveRecord("companies", DiscriminatorColumn="type", DiscriminatorType="String", DiscriminatorValue="company")] and then indicate the value for each of the sub-classes i.e. [ActiveRecord(DiscriminatorValue="firm")].
Mapping the Table-per-subclass strategy requires us to use the JoinedBase attribute on the superclass ActiveRecord attribute i.e. [ActiveRecord("entity"), JoinedBase] and then use the [JoinedKey] attribute on the shared key value of the sub-classes.

ActiveRecord also provides support for fine grained object models. We declare the [Nested] attribute on the property declaration in the containing entity, and then only mark up the component class with [Property] attributes i.e. not with [ActiveRecord] or [PrimaryKey] attributes.

Configuring Active Record

Before using ActiveRecord we must invoke the method Initialize on ActiveRecordStarter to configure NHibernate for us.There are a range of options to use when configuring, depending on where your configuration information is found. Because we added our configuration to the app.config file we can use the ActiveRecordSectionHandler to retrieve our configuration information.
ActiveRecordStarter also provides the functionality to generate our schema from our code.

            log4net.Config.XmlConfigurator.Configure();
            IConfigurationSource config = ActiveRecordSectionHandler.Instance;
            ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);
            ActiveRecordStarter.CreateSchema();

Switching from attributes to mapping files

Active Record generates XML mapping files at run-time from your attributes, so this is using the same mechanism as the XML configuration, the complexity is just hidden from you. If you want to see the mapping then you can set the Debug value to true on the active record configuration (see above). This will tell NHibernate to keep the files around when your application ends, instead of deleting them.
This allows you to pursue a strategy of beginning development by using attributes, and then switching to .hbm.xml files later to fully utilize all options and keep your domain model clean of mapping information.

Active Record support for Session Management

Active Record removes the need to initialize a session factory explicitly, instead we use the ActiveRecordStarter.

IConfigurationSource config = ActiveRecordSectionHandler.Instance;
ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);

For a web based application best practice is that we initialize within the Application_Start method of the global HttpApplication object.

Active Record operations try to get a session from the current thread, but create one if it is not extant, perform the operation and then release the session. So by default Active Record is session per operation. Active Record also gives us the ability to use a SessionScope to keep the session alive for the scope of our business transaction. Best practice is always to use a SessionScope.

            using (new SessionScope())
           {
                const string COMPANY_NAME = "CompanyOfWolves";
                InsertNewCompany(COMPANY_NAME);
                int companyId = FindInsertedCompany(COMPANY_NAME);
            }

For a web application the usual pattern is to create a SessionScope with request affinity

Active Record and Repositories

The problem with the Active Record pattern, where the entity exposes CRUD methods is that it does not enforce a clean separation of concerns. (We have not shown this but to get Active Record working this way we need our entities to derive from ActiveRecordBase). Knowledge about persistence is coupled with knowledge about domain responsibilities. This increases complexity and thus makes maintenance harder. So good design strives for persistence ignorance within its domain model. The repository lives within the domain model and represents a collection of entities from an aggregate root.

We call the repository from our domain level service to persist the object graph.

Support for Repository within Active Record

Active Record provides ActiveRecordMediator to allow you to use ActiveRecord to implement a repository.

   public class CompanyRepository
    {
        protected ActiveRecordMediator<Company> mediator;

        public void Add(Company item)
        {
            ActiveRecordMediator<Company>.Save(item);
        }
        public virtual this[ int id]
        {

get { return ActiveRecordMediator<Company>.FindByPrimaryKey(id); }
        }
        public Company[] Find(IActiveRecordQuery query)
        {
            return (Company[])ActiveRecordMediator<Company>.ExecuteQuery(query);
        }

        public Company[] Items()
        {
            return ActiveRecordMediator<Company>.FindAll();
        }

        public virtual int Count()
        {
            return ActiveRecordMediator<Company>.Count();
        }

    }

A quick example of using this repository (domain services etc. elided to remove complexity) would be:

     public static void Main(string[] args)
        {
            log4net.Config.XmlConfigurator.Configure();

            IConfigurationSource config = ActiveRecordSectionHandler.Instance;

            ActiveRecordStarter.Initialize(typeof(Company).Assembly, config);

            ActiveRecordStarter.CreateSchema();

            //Comment out the session scope to see lazy load lack of scope issues
            using (new SessionScope())
            {
                const string COMPANY_NAME = "CompanyOfWolves";
                InsertNewCompany(COMPANY_NAME);
                int companyId = FindInsertedCompany(COMPANY_NAME);
            }
        }

        private static int FindInsertedCompany(string companyName)
        {
            IActiveRecordQuery query = new SimpleQuery<Company>("from Company org where Name = ?", companyName);

            CompanyRepository companyRepository = new CompanyRepository();
            Company[] companies = companyRepository.Find(query);
            Company company = companies[0];
            Console.Out.WriteLine(company.Name);

            foreach (Customer customer in company.Customers)
            {
                Console.Out.WriteLine();
                Console.Out.Write("First Name: ");
                Console.Out.WriteLine(customer.Name.FirstName);
                Console.Out.Write("Surname: ");
                Console.Out.WriteLine(customer.Name.Surname);
            }
            return company.Id;
        }

        private static void InsertNewCompany(string companyName)
        {
            Company company = new Company();
            company.Name = companyName;

            Customer customer = new Customer();
            customer.Name.FirstName = "Neil";
            customer.Name.Surname = "Jordan";
            customer.DateOfBirth = new DateTime(1950, 2, 25);
            customer.Company = company;

            company.Customers.Add(customer);

            CompanyRepository companyRepository = new CompanyRepository();
            companyRepository.Add(company);

        }

AltNetConf UK London August 2009

Ian Cooper — Fri, 15 May 2009 07:02:00 GMT

It feels as though sufficient water has passed under-the-bridge for us to have another altnetconf in London. We tend to organize them when the 'mood' seems right in the community. That usually means that we think folks have something to discuss. This time we are planning on the weekend of 1 August (31 JUL to 2 AUG). Registration should open on 12 May. Don't be alarmed if you see an old version of the site before then.

Numbers are still limited. The wider economy means that we are unlikely to get the sponsorship for a bigger venue this year. We'll keep trying though.

That said Alan Dean, Ben Hall, and myself have been plotting in secret, and roped in Sebastian Lambla and Michelle Flynne to help so that we can hold a bigger event in terms of the amount we do. So this time the plan is:

31 JUL Evening: Alt.Net Beers: Yes we are integrating Seb's alt.net event to warm you up with a chance to relax with like-minded individuals

1 AUG Day: Open Space Coding: Alan Dean's Open Space Coding Day event joins our weekend. the emphasis is on writing code over jawing.

2 AUG Day: AltNetConf: Open Space discussion about the topics that have grabbed you today. Be prepare to be surprised.

UPDATE: We had a request from attendees at Progressive .NET to delay registration, as they are a key attendance group. I'll update with the new time, likely to be Thursday lunchtime or evening.

UPDATE: We have now opened registration: http://www.altnetuk.com/registration.en.html

I'm looking forward to this one. It feels as though it has been long enough that we ought to have some things to talk about, not just re-hashing the old saws.

Finding out about London .NET events

Ian Cooper — Wed, 06 May 2009 08:47:00 GMT

We have a rich .NET development scene in London and the organizers of a number of communities and events are going to try and make sure everyone knows how to get the best out of the community.

The first question for most people would be how to find out what is happening. For now the key site for you to bookmark is the UK .NET event site. The London communities are going to make sure that we all advertise our events their so that you can go to one place and see what is coming up.

As some quick examples of what is happening there I wanted to show you two events that you can find there which I am involved in. One is the Progressive .NET tutorials, which you can find on the calendar here. For those of you who can't fly out to events like Alt.NET Seattle it is a great opportunity to catch people like Ayende, Hammet, Bellware (and me).

On the 12th you can catch up with a lot of the same people down the pub as Seb has cunningly arranged the next Alt.NET beers to coincide with so many people being in town.

On Learning Boo

Ian Cooper — Tue, 14 Apr 2009 03:18:00 GMT

Learning Boo

As part of my commitment to The Pragmatic Programmer's exhortation to learn a new language every year, I decided to tackle Boo. My interest has been piqued by the work Oren is doing in DSLs with Boo. Learning Boo seemed to be an important first step to getting to grips with that.

The first step was to get an environment in which I could write and compile Boo programs. Now this is possible using a decent text editor like Vim, and command line tools like booc and booish, but it is also possible to use an IDE for this. I downloaded SharpDevelop which has support for authoring, building and debugging Boo projects.

To give myself a starting point I have decided to work through the Boo Primer as a way of getting to know the language

One aspect that jumps out is why Boo is called 'wrist-friendly'. There is a lot of effort expended on giving you less to type. Although it is a statically typed language, Boo does away with the need to declare types before use. Instead Boo infers the type. C# programmers will find this similar to te use of var, without the need for the var keyword.

greeting = "Hello World" //This declares a string
houseNumber = 42 //This declares an integer

I'm always typing code of the form:

var myString = string.Format("Hello {0}", name);

in C#. Boo makes this a lot easier with string interning. I get to skip the string format statement, along with the seperation of placeholder and variable for

myString = "Hello ${name}"

The use of whitespace (Boo has a Python inspired syntax) to indicate a block is one of the early aspects of the language that strikes me. It makes for great natural language syntax, because it requires no block markers, but coming from a curly brace language "{}" like C# it takes a little for the fingers to get used to. I also seem to keep missing the colon off the end of the conditional

i = 5
if i > 0:
	print "i is greater than 0"
	if (i < 10):
		print "i is less than 10"
		if (i==5):
		      print "i equals 5"

One issue that hit me when working through the Boo Primer was that SharpDevelop disliked me trying to declare a list as follows:

L = List(range(5))

which gave me the error

ERROR: Generic types without all generic parameters defined cannot be instantiated.

Some digging on the Boo Programming Language mailing list established that Boo now has generics and it looks like the Boo interpreter in SharpDevelop uses that type over the non-generic type. Switching to use the generic collection instead, removed the error messages

L = List[of int](range(5))

The built in list initializer syntax seems to work in SharpDevelop though:

barfoo = ['abcdefghijkl']

I like the provision of initializer syntax for arrys, lists, and hashes within the language which provides for concise syntax

Overall I have spent an enjoyable half-a-day familiarizing myself with Boo's syntax so far. One immediate advantage to learning Boo over say learning Ruby is that you are dealing with .NET libraries. So when you see Console.ReadKey(true) in a line of Boo code your existing knowledge tells you what it is doing. You are able to leverage existing framework skills and apply them to a new language. This speeds up the learning process, because having learnt the new syntax you can to put it to use fare more quickly.

Next time I'll play with Boo's methods and classes. Looking forward to it.