Convention over Configuration in MSDN Magazine

The February ’09 edition of MSDN Magazine includes my latest article entitled “Convention over Configuration.”  Personally, I think this is an exciting topic and I really enjoyed writing on this subject.  I hope this article can help to spawn some ideas and conversation about how we design configuration intensive frameworks. 

When we build systems, we’re trying to accomplish certain business goals, but to get there, we have to jump through hoops to satisfy infrastructural concerns.  You could say that there are two types of code we write: 

  1. The “Essence” of the system that satisfies our original business goals
  2. The “Ceremony” we have to go through to satisfy infrastructural requirements, the compiler, configuration mappings, and other drudgery

I think that one of the next frontiers for .Net development is adopting and experimenting with techniques that allow us to accomplish the Essence of the system with less effort devoted to Ceremony code. 
This article largely takes on increasing the Essence vs Ceremony ratio by examing some of the ideas popularized by Ruby on Rails with real life technologies and concepts taken directly from my current project (because that made writing the article easier ;-):

  • Sensible Defaults
  • Convention over Configuration
  • Once and Only Once (DRY)
  • Opinionated Software

Length considerations made me cut my planned discussion about Language Oriented Programming — arguably the single best way to improve your Essence vs. Ceremony ratio.  I might come back with another article later in the year on writing and using Internal DSL’s in .Net.  I’d love to have some feedback on both this article and the DSL topic, and whether or not you think that would be appropriate/useful to be published in MSDN.

Also, check out David Laribee’s Introduction to Domain Driven Design in the same issue.

The next article in April is on “Presentation Patterns” to fit the theme of that issue.  After that, I’m thinking:

  • Composition over Inheritance
  • More Persistence Patterns – Unit of Work, getting much deeper into Repository alternatives, Specifications
  • Continuous Design
  • Internal DSL’s in .Net



A Sarcastic History Lesson

  1. In the late 90’s the Java guys had the first EJB Container technologies that promised better productivity than ever, and that was good.  However, the EJB runtime model was very unfriendly towards the newer Agile practices coming on line like Test Driven Development because of the very tight coupling between the Container infrastructure and your code.
  2. In the early 00’s parts of the Java world rebels against the EJB model in favor of the “POJO” technologies like lightweight IoC containers and ORM’s like Hibernate that generally isolate business objects from infrastructure concerns, and that was good for adopting TDD and developer sanity.  However, all those Hibernate and Spring mappings spawned a new kind of hell affectionately known as “XmHell.”  Eventually, Scott Bellware makes the classic statement that “Java is a DSL to transform big Xml documents into long exception stack traces.”
  3. About 3 years ago, Ruby on Rails bursts onto the scene with this new idea called “Convention over Configuration,” which roughly translates to “follow these strict naming conventions and the framework will just figure out what to do by itself.”  The “CoC” model promises better productivity by removing much of the repetitive explicit configuration and mapping that the first versions of the POJO tools required.  In ’06, a pre-ALT.NET Jeremy sees an RoR demonstration that requires much less code than what he was forced to write in MVP with WebForms, and he transitions from merely disliking WebForms to absolutely despising the technology. 
  4. The inevitable backlash against all the RoR “black magic” gets off the ground with the new Merb framework for Ruby web development
  5. 2008-, the .Net OSS community finally starts to apply Convention over Configuration to our own work.  I add some CoC stuff to StructureMap.  Fluent NHibernate starts the work on “Auto Mapping” to reduce or even end the drudgery of creating NHibernate mapping files.  FubuMVC is trying to apply CoC in a big way to MVC web development. 
  6. 2008:  MS tries to recreate the entire EJB problem with their new data access technologies.  The .Net community by and large ignores the rest of the world and is blissfully unaware that they’re about to make some of the same mistakes as the Java community did years ago.
  7. 2009-, a backlash against CoC in .Net tools gains steam because we pushed CoC farther than we should have — but at least then we’ll know the practical limits



About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jeremy D. Miller


    *If* you own both sides of the wire, I’ve found the “shared library of DTO’s” to work very well in usage.

    ” Anyway, anything obvious I’m missing here?”

    Not obvious, but if you’re going to do that, there better be something in your CI build that would detect errors in either end of the messaging if the common DTO library changes. This solution can be much less risky / more effective with a good automated build strategy.

  • SteveJ

    You’ve kinda touched on this with Entity objects, but I’m curious about sharing even DTOs between two systems. I run into the following alot:

    I’ve written a system that has a set of Entity objects, those objects are accessed via an external interface. Think protocol interface here, SOAP, CORBA, SNMP, etc.

    On the other side of the interface I basically recreate those objects in an entirely different system. The only things the two have in common is that they share data and happen to be written in the same programming language.

    What I always run into is trying to strike a balance between independence and avoiding rewriting the same objects twice. I don’t want to make an enforced dependency on the first system, the second doesn’t require it to do it’s job, it just uses that data as a supplement if it’s available. I don’t want to write the same validation logic twice, especially since that external interface (SNMP, CORBA, SOAP) changes weekly. I’ve tried to look at this as a Dependency Inversion type thing, but then I’m introducing a third component, essentially a shared library that both then depend on, which doesn’t really make it more maintainable and still feels dirty to me. Anyway, anything obvious I’m missing here?

  • alberto

    Yeah, that abuse of css is really cool. 😀

    Thanks for the feedback!

  • Jeremy D. Miller


    “Doesn’t lazy loading cause you problems with that?”

    We haven’t seen any issues yet with lazy loading, but we haven’t done load testing / optimization yet.

    “Do you also pass them when you use web services?”

    We don’t have any web services other than Json gets/posts per se, but I would definitely say DTO all the way in that case. That’s most definitely a “bounded context” issue.

    “Re jQuery, yeah, it probably can do most stuff out of the box, but there’ll be cases in which you have to duplicate logic too.”

    Duplicate implementation of the actual validation logic, sure. But what I’m most worried about is the single place to say “this field must be a valid email address,” and we’ve got that problem solved.

  • alberto

    Regarding passing entities. Interesting that you think that way. Doesn’t lazy loading cause you problems with that? Do you also pass them when you use web services?

    Re jQuery, yeah, it probably can do most stuff out of the box, but there’ll be cases in which you have to duplicate logic too.

  • Jeremy D. Miller


    Go google for the “AltOxite” appliction. It’s still in development, but that’s the best example out in the open that I know of.

  • Jeremy D. Miller

    @David Mc.,

    I’m not touching Oslo with a 10 foot pole for at least another year. The point of discussing Internal DSL’s is almost to make sure people know that there are alternatives to Oslo that are available now, and potentially much, much cheaper to implement.

  • David Mc.

    I read the current article which I think did a good job showing MY own evolution from the fantastic VB5 programs I thought I was writing to where I hope to arrive someday. And the article coming in April sounds even better…

    Regarding your request for feedback about your future article for using Internal DSL’s in .Net – I think that many people are going to be taking a look at Oslo, so if you could at least show the potential for using it, and its pros/cons, that would make for a good intro and and something for Google to bubble up to the top of its results!

  • Manoj Waikar

    Thanks for the nice article, Jeremy. Would you mind keeping a separate link for all of your (till-date, and keep updating that for upcoming) MSDN magazine articles?

    Also, a reference application showcasing Asp.Net MVC, DDD, Unit of work, Repository pattern (anything and everything you feel is the recommended way) would be much helpful for so many of us. This reference application should help to show all that you Alt.Net and / or CodeBetter folks practice (as opposed to so many of the MS released reference apps. which you guys don’t recommend).

    Btw, I love the point no. 6 above :)


  • Jeremy D. Miller


    We send the actual Entity objects to the view. We own both the view and the rest of the code, we can refactor both together, we’ve got feedback cycles in the build to find mismatches in the API, and most importantly, it works with minimum fuss.

    IMHO, the whole “thou shalt never expose your entities to the view” is a load of ideological crap from the DDD nazis. Sometimes it’s necessary/valuable to put the View and business logic in separate “bounded contexts,” and sometimes its not.

    We don’t do every type of validation on the client side. We use Fowler’s Notification pattern to send server side validation messages to the client. I think that all the validation types you mentioned are supported by jQuery Validation.

  • alberto

    Nice article. Two questions:
    – Are you passing entities or DTO’s to your views? If the latter, how do you avoid repeating validation attributes?

    – How do you deal with more complex validations (e.g. dates and date ranges, valid id/ssn, email,…) in the client side?

  • Peter Bromberg

    I don’t despise webforms, but the contributions you’ve made with Fluent.NH and related offerings have got me religion. Thanks for the great stuff!

  • Liam McLennan

    Nice article. It seems like it would have been nice to reference Brooks.

  • Claudio Lassala

    Definitely looking forward to the article on Presentation Patterns, as well as something on the “More Persistence Patterns…” one.

  • Jeremy Wiebe

    I’m very much looking forward to an article on Composition over Inheritance. My thinking about inheritance based class hierarchies is already changing somewhat because of our use of an IoC container on my latest project but it would be nice to see an article really taking on that subject.

    Write on!