Hello Roland,
Personally I would not recommend the (beta) javaconfig thing to an
unexperienced spring user.
Avoiding XML hell is done by doing the wiring with Spring, and doing
configuration separately (with or without Spring). I know this is a fine
line of distinction, but one well worth
Hi Roland and Erik
Thanks for your replies, notably the best practices provided.
Regarding the way to design, I would sum your answers as following :
- one can follow a Domain Driven Design, with a manager per kind of object.
- In the Spring ApplicationContext file, I should only define
Hi,
ZedroS Schwart wrote:
- one can follow a Domain Driven Design, with a manager per kind of object.
That is a major simplification, but yes, that is true.
- In the Spring ApplicationContext file, I should only define
implementations and in my Java code I should only use interfaces.
Is
Thanks a lot. I definitely have to learn more of it :)
ZedroS
On 3/9/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Hi,
ZedroS Schwart wrote:
- one can follow a Domain Driven Design, with a manager per kind of
object.
That is a major simplification, but yes, that is true.
- In the
Hi all
As said earlier, I'm beginning with Spring and I find it a bit hard to
know how to design my application with it.
Let me give an example : in order for the end user to register, I've a
registration form. Up to now, I've a registrationBean which isn't
managed by Spring. On the form submit,
Hello ZedroS,
You ask very difficult questions which are not easy to answer. The
ability to answer comes with years of practice and learning. I can
recommend reading some books on design patterns.
I /can/ provide some very rough guidelines:
- put similar things in the same place (do not
Hi ZedroS,
you could check out the wicket pastebin at
http://developer.berlios.de/projects/wicketpastebin/ which uses wicket
and spring.
I personally think using only the interfaces in your code is usually a
good idea. If you want to avoid XML and don't mind dabbling with
experimental code then