directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Toward 2.0...
Date Wed, 18 Mar 2009 00:40:34 GMT
Emmanuel Lecharny wrote:

> That's the main issue... Xbeans is trying to alleviate the pain it is to 
> manipulate class names in a Spring file. As I already said, it creates a 
> decoupling which is painfull, as you have no clue about what is what in 
> the Spring file when you have decoupled those two parts. We have more 
> than 2500 classes in Directory (not counting Studio), and even after 5 
> years working on the project, I can't easily remember where all of them 
> are located.

The name of the principle you are currntly violating by using Spring is 
called the "Don't repeat yourself" principle:

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

By storing class names in two places (the Java class file, and the 
Spring bean definition XML file) you are adding 2500 different 
opportunities for the classes and spring configs to go out of sync.

And there is nothing in the class to suggest that a spring bean is 
somehow relevant, making refactoring impossible, and that kills code.

> To be frank, and we discussed that ad nauseam with Alex, using Spring 
> was one of the biggest mistakes we made. We don't need Inversion of 
> control/Depenency Injection/whatever Fowler call it. This is useless in 
> our case. What we need is a configuration which can be loaded at 
> startup, and that's it. what we had before (a property file) was just 
> plain ok. OpenLDAP is now storing the configuration in the DIT, and it 
> works perfectly well.
> 
> And if we don't want to go back to a property file, or config in the 
> DIT, then JSON can be an intersting option. Everything but this infamous 
> brackets all over the configration !!! Die, XML, die !

When I use XML as a config, I define that config as an XSD, throw the 
XSD through xmlbeans to write all the parsing code for me, and then I 
make sure the config file is properly validated on load.

If the end user does something wrong, the end user gets proper error 
messages telling them what they did wrong, and what line they did it 
wrong on.

Regards,
Graham
--

Mime
View raw message