I respect your point of view. This is more of a wondering-out-loud than a “do it like this” blog post.

I myself am still feeling out this style to see whether I like it or not.

Thanks for your comments.

Add to that the fact that convention over configuration is really creating silent choices. If the configuration is stated, you can see plainly what it is. If the configuration is not stated (i.e. uses the convention) then you have to know what the convention is, or go look it up, which reduces maintainability. That means that the convention has to be as simple and obvious as possible, or it is going to make the system less maintainable, not more. Now you want to change the convention depending on the circumstances, essentially magnifying the complexity of the convention and making it even less likely that anyone will be able to keep track of it. In my opinion this is just creating a nightmare for developers and administrators. I would rather see the configuration stated plainly than have to guess what it is while I am trying to solve a problem.

I’d suggest joining the NServiceBus discussion group for getting your questions answered:

http://tech.groups.yahoo.com/group/nservicebus/

Thanks for your kind words.

Over the last 2 yrs I’ve built a custom solution(Mysql/.NET based) to solve a complex (domain boundary crossing)problem in distributing custom Datasets between Domain apps(different kinds of Db’s in different departments with different “business rules being handled by the Event-handlers at the endpoints(message subscribers)”) at a certain domain event occurence, a so called: “Domain Event Service Bus”, if you could call it that way. A pain at first but with many benefits, I keep trying to make it better or move to a more proven solution, perhaps NServiceBus as one of the components to make it more robust.

Been reading your blogs and tips on how to make things simpler and to be able to make an easy/simple solution(possibly with NService Bus) to easily deploy in production on different platforms(windows/linux etc)
I am currently evaluating NserviceBUS and learning.
We are all still learning as we go along and NserviceBus is a great tool in simplifying complex solutions I think.

Any advice or pointers to gather more info on these technologies and implementations and to point me in the right direction?

Keep up the good work!

I may get another post up on this topic as we progress with its implementation in NServiceBus. It probably won’t be coming in the next day or two, though

The current place where I’m contracting is about to roll out a staging environment for the first time along with the rest of a development department’s processes. So far, we will be leveraging Castle Windsor for IoC. We are looking at the possibility of dropping in configuration to parts /should it be necessary/. Can we expect a follow up to this article that touch on the various comments made here?

Thanks,

Adam

You’ve got it – it’s convention *over* configuration, not *instead of*. We’ll probably always need both. The thing is, as more developers use more frameworks – an ORM, MVC, message bus, etc – we’d serve them well by formalizing which combinations work best together and under which circumstances those combinations should be used.

10x

The more there are of us interested in this, the more likely Microsoft will be to come along for the ride

Spread the word.

Always nice hearing encouragement – thanks

I had thought of environment variables, it just that they’re not particularly convenient to change though that may be more easily solvable than trying to making web apps accept parameters some other way…

Will definitely keep thinking this one through.

I fully understand where you’re coming from – I felt that pain myself. What I can say is that even the stuff that seems static may need to flex a bit now and again, and it may need to do that in coordinated ways that we’d like to give a name to.

I’m not saying that command line parameters are the ultimate solution, I’m just trying to get deeper clarity on what the problem we’ve all been feeling actually is.

Best regards.

Hmm – that’s an interesting perspective. I guess that as long as we attempt to improve, we’ll learn something along the way, better preparing ourselves to understand and take the next step.

Thanks for sharing your opinions.

I think you’ve got it, just you might not have internalized the result. We’re looking at raising the level of abstraction that developers work at, say what you want – not how it should be done. As frameworks get more and more features, configuration options, etc – we need a way to say “you see this combination here? use that in this scenario”.

Does that make sense?

Good stuff!

Chris

Of course, flexibility to change the convention is also needed, but an initial and sensible convention makes the barrier to entry much smaller for a particular technology – ASP.NET MVC comes to mind.

Developers have a smaller barrier to entry as they become familiar with the technology and if they out grow the default convention, they can dig into configuation to learn how to change it.

Nice post Udi.

Thank you for submitting this cool story – Trackback from DotNetShoutout…

Later on we got the advice that config files should only include stuff that the sysadmin wants to configure – never internal static unchangeable stuff like the typical IoC setup.

What is needed is some way to split the stuff that changes from development to release and keep that separate from all the more static stuff. Doing this helps deployment a lot: you can always copy the static config files, and only need to modify the dynamic file.

So I am all for splitting dynamic and static stuff. But doing it through command line parameters? Nah, not really – then I would probably write a batch file for starting the servers so I wouldn’t have to remember all the command line parameters when installing the system … and I would actually rather edit a config file than a batch file – the intent of the config file is, of course, *configuration* – whereas you never know what a batch file does.

/Jørn

Being able to store environmental deltas in files like nServiceBus does is incredibly useful. Extending these to be standardized would obviously help e.g. “This is the standard production delta”.

More sophisticated tweaks require a proper programming language/DSL. I think that IronPython and IronRuby look like better candidates for a workable format than XML. This also allows you to just write your configuration API the once.

The fewer admin settings there are, the better. Sooner or later, someone’s going to have to enter the connect strings, the queue names and so on.

Finally, different firms have different workflows. The “Dev/Integration/Production” split is only appropriate for those with that workflow. I think, ultimately, this is a function of the installer. There isn’t really a workflow-aware install framework for .NET, though.

Developer chooses the integration config. The framework has all sorts of smarts to figure out if MSMQ is installed, if not maybe choose a different messaging system, check if SQLite is installed, etc, etc – so this is the goal you’re talking about, right? Which would require us/the-framework-developers to have already thought about all these scenarios and configured these checks and choices.

So if you find yourself in a situation that the framework setup hasn’t anticipated or you want to point to a different system than what the framework wants to point to, then you’ll need a config for that.

So what this boils down to is… ummm… I can’t quite figure out what you’re advocating Is it just a more comprehensive set of steps that the framework takes so that the chances of you needing to tweak something is reduced? Or is there something deeper I’m not quite getting?

That’s a solution I see many people using so I’m glad to hear it’s working for you too. I hope that when you see the steps that we’ve taken that you’ll enjoy that we were able to whittle away a little bit of complexity.

Do let me know if you have any ideas on how we can make things simpler for you and the rest of the NServiceBus community.

I’m not saying we should take control away from developers and put it in the hands of the framework, but that we add some context to the conventions we’ve already put in place.

We don’t even have to anticipate all scenarios if we leave the door to configuration open. Anything we can simplify incrementally is a nice win and we should take what we can get as we figure out what steps to take next.

Thanks for your comments.