One-Pot MVC

I’m going to be giving a talk at “The Stack” in August. If you’ve never heard of it, this is a monthly user group for developers in the Liverpool area who use Microsoft technologies. I’ll be talking about some of the extensibility points in the ASP.NET MVC framework, and hopefully my summary for the evening’s agenda will give you a “taste” of what I’ll be covering:

One-Pot MVC: Deliciously Extensible

“Take a rich stock of MVC, and stir in some validation rules. I suggest regular model annotations are substituted with FluentValidation libraries, for added flavour. While your controller is simmering prepare unit tests, but be careful your project manager doesn’t boil over! Choose your favourite IoC container (NInject works well) and mix in concrete dependencies as required.
Finally, add a pinch of MvcContrib and serve on time and in budget.”

I’ll provide another update with dates and details of other speakers as it gets finalised.

DevWeek 2009

On Tuesday I caught an early train to London and arrived at the Barbican estate for ‘DevWeek’, a 3-day series of technical seminars. Let’s get one thing out of the way; the Barbican estate is architectural lunacy. I never expected such an entertaining venue. Huge modernist residential blocks enclosing an open precinct, with yet more flats erupting out of a vast central lake on concrete pillars. In theory, it’s a monstrosity. In the flesh, it was a tranquil backdrop for some inspiring tech-talk.

Tuesday’s highlight was the ASP.NET Model-View-Controller framework, which was released at the Mix ’09 conference last week. There’s nothing new about the MVC pattern, which was first conceived and documented in the 70’s, and a large number of web frameworks already operate around this pattern. Microsoft seem to have been ‘watching the tail lights’ of others such as Rails before committing to an implementation of their own. The same could be said for the ADO.NET Entity Framework as an O/RM toolset and ASP.NET Dynamic Data for scaffolding, all of which featured during the conference. As regards the MVC framework I was surprised by the number of speakers, even from within Microsoft, who conceded that the ASP.NET web forms model is not well suited to delivery of clean, accessible HTML markup, and makes unit testing extremely difficult. They may be late to the party, but the ASP.NET MVC framework is a massive leap in the right direction for ASP.NET developers and makes all these problems go away.

The high point of Wednesday was a seminar delivered by ThoughtWorks’ Neal Ford on the mechanics of programmer productivity, although in fact most of the subject matter was applicable to non-programmers. I’d urge anyone who has an opportunity to attend one of Neal’s talks to jump at the chance. The piece that really struck a chord was the reference to the psychological phenomenon of flow (aka being ‘in the zone’), and what practical steps can be taken to aggressively guard this most productive, and most fragile, states of mind.  Neal also gave a raft of practical advice to accelerate the process of getting stuff out of your head and into your computer, such as memorising keyboard shortcuts and switching your mouse to the opposite hand to discourage yourself from using it!

The take-home message from Thursday was Kevin Jones’ session on designing code to facilitate unit testing. Kevin demonstrated how to recognise code which would make unit testing difficult, and how to refactor to avoid this problem. He also covered design patterns such as inversion-of-control which can make code unit test-friendly from the ground up, and tools such as Microsoft’s Unity which take the legwork out of dependency injection.

Interestingly, a lot of people were Twittering during and after the seminars using the #devweek hashtag. Despite being initially sceptical of the micro-blogging platform, I was fascinated with the way a small virtual community sprung up around the physical event and I was able to read their session feedback in real time. My only regret from the whole conference is that I couldn’t be in all 8 sessions which were running at any one time, so I’ve already started reviewing the slides from the ones I missed. See you at DevWeek 2010!

Referencing parent repeater items from server controls

This is something I’ve had to do a couple of times in the past, and someone else in work had the same requirement last week. The situation this resolve is that you’ve got a repeater on your page, but within this you have other controls which need to be aware of their context, for example to amend their behaviour according to which item is being rendered.

In this example, I wanted the last item in my unordered list to have a different look/feel to the other items, which was achieved using a couple of different placeholders and attaching a different style to the last item only. The “Visible” property of each placeholder is then set accordingly:

<asp:Repeater id=”myRepeater” Runat=”server”>
<asp:PlaceHolder ID=”normalItem” runat=”server” Visible='<%#Container.ItemIndex != ((ICollection)((Repeater)Container.Parent).DataSource).Count – 1%>’><li><%Eval(“SomeField”) %></li></asp:PlaceHolder>
<asp:PlaceHolder ID=”lastItem” runat=”server” Visible='<%#Container.ItemIndex == ((ICollection)((Repeater)Container.Parent).DataSource).Count – 1%>’><li class=”last”><%Eval(“SomeField”) %></li></asp:PlaceHolder>

Web.config security issue

A colleague raised an interesting security ‘gotcha’ related to web.config files last week. Apparently this particular gem was raised at a recent Microsoft conference in London Village and there was a collective ‘gasp’ from the audience as a roomfull of developers realised that at some point they’d probably left at least one of their web applications open to the world’s easiest hack.

In a nutshell, never rename your web.config files to web.config.old, or web.config.bak etc. Unless you’ve explicitly prohibited access to files with this extension, IIS will quite happily serve these files up as readily as it would .html or .jpg files, potentially leaving all the database connection strings, server addresses and other goodies you put in your config files unprotected. Apparently hackers are already well onto this one, and have developed bots to scour sites looking for these renamed files. You have been warned!

What’s in a name(space)?

I was reviewing the MSDN guidelines on naming your namespaces, which hints at the solution to an issue I see a lot, namely “in which namespace do I put non-specific members”? If you’re wondering what I mean by that, take a look through your own hierarchy of namespaces and look for any that end .Common, .General, .Generic, .Core, .Universal, .Wherethehelldoesthisgo etc.

The MSDN guidelines state “A nested namespace should have a dependency on types in the containing namespace”, so to turn this on its head, members which are used throughout many nested namespaces should go in the parent. To give an example, say you’ve got some classes to deal with accountancy business rules in these namespaces:

  • Mycompany.Accounts.Payroll
  • Mycompany.Accounts.Invoicing
  • Mycompany.Accounts.Receipts

and you’ve got some helper methods in a static class which help you work out taxes, which would potentially be used across all three of these namespaces, don’t put them in

  • Mycompany.Accounts.Hmmnotsureaboutthislot

instead put them in

  • Mycompany.Accounts

You’ll find your namespace hierarchy is much cleaner and suddenly makes a whole lot more sense.

User controls and rabbit-hole syndrome

User controls (.ascx files) are a great way of re-using chunks of HTML and logic, easing maintenance overheading and ensuring you don’t repeat yourself, but used poorly they have exactly the opposite effect and vastly overcomplicate applications.

Take this scenario; you open up an .aspx page to fix a reported bug, only to find only a set of references to .ascx files. Undeterred, you open the control you believe contains the offending code, only to find… more .ascx references! In a page I came across recently, not only were there multiple levels of nested user controls, but in some cases those controls were used only once in the entire application. As a general rule, if you’re not going to re-use it, don’t extract it out into a separate file.