Re: [Springframework-developer] Re: Annotations

[Martin K. <Mar...@St...>]

Hi ya,

>> Speaking as a non-Spring developer....(i.e. wait for Rod, Juergen, etc..
>> comments)...
>>
>> Is this something that you really want?   There are valid uses of
>> Annotations...(i.e. transactions, security)...
>> but I dont think its a good idea to use it for everything (i.e.  IoC)
>>
>> EJB3 is annotation-"crazy"... for lack of a better word.... I still 
>> really
>> do not think @Inject is appropriate.
>
> Inject is probably one of the things I'm looking for. That is being able 
> to do the assembly level stuff using annotations. The reason that we have 
> the XML configuration file is because we can change assembly level things 
> easily (right?). However, this can just as easily be achieved using 
> annotations which retain code locality. Majority of applications are 
> pretty static in nature and there's no need to change the assembly stuff 
> once the app if finished. And if you do need to change something you need 
> to tear open the WAR archive anyways which is not far from doing a full 
> recompile.

It is an interesting topic. Annotations are highly interesting stuff. But
I dont know if the 'Annotation for everything' speech will hold in the
future. But it is still amazing how far you can push things with
annotations (beside the @SupressWarning and @Override annotations
of cause (I dislike them)).

There is also something like a counter-movement  going on. Skip
all the xml / IOC things and go for the hot cake first. For example
Tapestry, Trails and Rails mostly favour annotations instead of
xml files or even hard-wire the application within the code.

I find hard-wiring it, is the least preferable to do. But it is all
we always do. I always fail by getting where the border is. You
know methods are hardwired, some objects are hard-wired.
For the next granularity level (moduls being formed by
collaborating objects) I would clearly favour annotations. And
on application level, I strongly tend to favour xml.

The fun part is, that by having a complete annotation support,
it would be more relaxing for find the best way to wire everthing
together.

Level     -> Type
Objects / Classes -> hard-wired
Packages/Modules/Layers -> hard + soft (Annotations mainly)
Layers / Application -> soft (XML + Annotation)

Where to apply which kind of wiring depends on the
requirements. But as nearly always, the test-cases are your
saviour in the storm here. I - for example - mostly push
everything from hard-wired to soft to ease my test-cases. That's all.

Using Spring I mostly go for either hard-wired or xml. I would
like to go for complete annotations first.

And about the introducing the logical names stuff to the code, I don't
buy this one fully. I guess I know what the implications are but
it is like the property names. Having a get/setPropertyName method
introduces the logical name propertyName of the property (which
can even be virtual (logical)). So for wiring we mostly end up with
the class DomainModelService implicating the logical name
domainModelService for a service object.

So I think a annotation with that smart thinking, which works
by referring Classes rather than logical names (or better being
able to derieve the names from the class name) would be nice.
But I truely lack knowledge and experience here. It is
just what I feel would ease everyday's pain overhere... .

So I really would appreciate a near to complete annotation support
being able to substitute nearly all the xml-beans definition file(s)
(as best as possible).


Cheers,

Martin (Kersten)

>
>> I still think there will be some sort of level of configuration that you
>> cannot get away from.
>
> Ofcourse.
>
> * Janne Kario
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer