I’d like to hear some thoughts on the advantages, and disadvantages, of both convention and configuration.
It would seem to me that having configuration files (xml or similar) that exist outside the compiled application would actually be preferred over anything else. Changes can then be applied to a live application, without the need to recompile. However, with the recent movement towards a convention based setup, changes will almost always require an edit, followed by a recompile.
Having the ability to setup the elements of an application using pre-defined conventions, and other systems (like a fluent interface) obscure a lot of the work involved in editing some types of configuration files (xbm’s for example). However, it occurred to me earlier that making assuptions like that just might be a bad idea. We use interfaces so that we don’t make any assumptions about how an implementation works, so why would this be any different? Convention based systems may be easier to use, but is it worth making assumptions like that?
Please post your thoughts on these things. Tell me which you prefer and why you do so over the other.
Back when I was a really green newbie, I found configuration a bit confusing, and often only learned about parts of it when something didn’t “work” as I expected it to. As for convention, hah, I was all over the place. I would often copy/paste and follow whatever the last tutorial I had read did. Changing all the time monkey-see monkey-do.
Over time I’ve gotten more comfortable with configuration, and don’t feel intimidated by about:config or ini files any more. And I like to think my coding style and structure have settled down into some semblance of consistancy.
I don’t work with others as a rule, so I prefer not to be constrained by conventions now that I’m comfortable with configuration. As for the need to reboot/recompile, I take it in stride, no big deal as far as I care either way.
But if I was working with a team, I think following an agreed upon convention would be vastly more important.
I think the key is what you said “easier”. Once the convention is learned, the rest can be “trusted”. But I’d rather have a broad understanding than ease.
After reading your post, I have to wonder if you understood my usage of the word convention. Perhaps you did, and it is me that didnt’ fully understand your post. But just to be clear, what I am talking about is configuring your application via code, rather than an ini / xml file, and not a generalization such as: table names shall all be plurals and all identity column shall be of type int.
What’s the end result of all our efforts anyway? We give a product to somebody right? Unless you designed something for in-house use. These people aren’t programmers, but may still need to tweak a few options and settings here and there. They should be able to do so without re-commissioning you to perform those changes.
I’m a great believer in Convention over Configuration. The less configuration you have the better, and when you do have to have any configuration, it should be the exception, not the norm. But defining conventions and writing your applications to work with them, you reduce the amount of ceremony you need to accomplish a task. By having a standard conventions for things like IoC component registration, Mvc routing, Domain entity mapping, you reduce the time it takes to add to an application and for other developers to start working with your code.
I’ve just finished an internal project at work that will be used for all our propriety code and applications for clients. The “framework” makes heavy use of conventions we agreed as a team, and we’ve found it’s already greatly reduced the amount of time people need to get projects completed.
Xml configuration files are a maintenance nightmare and a legacy from the bad old days and should be avoided.
@Mittineague makes some good points, making use of and complying with conventions will makes things easier, and will be trusted more as it’s the norm and others are using it, but unless you dive into how the conventions worked and a wired up, you do lose a lot of the understanding of what happens.
Our CoC is for everything: IoC registration, Mvc routing and areas, controller/filter configuration, etc. When use the app, no on so far has had to actually do any of their configuration, our sensible defaults have been agreed by the team and has been working well.
I can’t do torrents. I’m a purist, and don’t install extra things like that. I have my os, my ide, and one game installed. Oh, and Firefox for testing.
On second thought, this very well may be the heart of a lot of my concerns. You see, I am still very much old school. I like as few external references as possible in my projects, as few projects per solution as possible, and as few classes as possible per project to get things working. I’d rather have a single xml config file with 20 settings in it than a whole set of classes designed for the sole purpose of duplicting that in code. An example would be my preference to use NHibernate over FluentNHibernate. The extra later just seems superfluous to me. Now if I could get NHibernate, itself, to do what I want, then I’d be good. But I can’t.
There is a semantic model under the XML in most cases anyway, by not using XML and sticking with conventions, you actually greatly reduce the amount of code required, which is a win for me.
We use FluentNHibernate to avoid having to write any manual mapping. 99% of our mapping is automatic, meaning a far less code to maintain and worry about.
Another plus of us complying to strict conventions istheability to move parts of applications to other project without changing a single thing. In fact, our CoC was designed with this a goal and it’s beginning pay off as we can get projects done far quicker.