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:
- The “Essence” of the system that satisfies our original business goals
- 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
- 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.
- 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.”
- 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.
- The inevitable backlash against all the RoR “black magic” gets off the ground with the new Merb framework for Ruby web development
- 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.
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.
- 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