Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Kent Tong
Hi,

I've written a tutorial on this topic. You may check it out at
http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread James Carman
Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
not just uset a {spring.version} property in your POM so that it all
stays in synch?

On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong k...@cpttm.org.mo wrote:
 Hi,

 I've written a tutorial on this topic. You may check it out at
 http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread James Carman
Why do you have page - service - dao?  Why not just talk directly to
the DAO for the getAll() method.  This level of indirection just
causes more code (and confusion) in your simple example.  Is this just
a best practice that you've devised?  I've never really understood
folks' aversion to talking to the DAOs from the view layer, especially
when it means you have to have duplicate methods in your service layer
to do so.  It just doesn't make sense to me.


On Sat, Jun 19, 2010 at 8:01 AM, James Carman
ja...@carmanconsulting.com wrote:
 Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
 not just uset a {spring.version} property in your POM so that it all
 stays in synch?

 On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong k...@cpttm.org.mo wrote:
 Hi,

 I've written a tutorial on this topic. You may check it out at
 http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Kent Tong
Hi James,

 Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
 not just uset a {spring.version} property in your POM so that it all
 stays in synch?

Thanks for your good advice. I've updated the tutorial.

 Why do you have page - service - dao?  Why not just talk directly to
 the DAO for the getAll() method.  This level of indirection just
 causes more code (and confusion) in your simple example.  Is this just
 a best practice that you've devised?  I've never really understood
 folks' aversion to talking to the DAOs from the view layer, especially
 when it means you have to have duplicate methods in your service layer
 to do so.  It just doesn't make sense to me.

I agree that if the service is simply delegating to the DAO without
adding anything, then it is probably be a good idea to merge them.
However, this sample application is meant to demonstrate how to do
it in a general case where the service does more than simple delegation.




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread James Carman
On Sat, Jun 19, 2010 at 10:10 AM, Kent Tong k...@cpttm.org.mo wrote:
 I agree that if the service is simply delegating to the DAO without
 adding anything, then it is probably be a good idea to merge them.
 However, this sample application is meant to demonstrate how to do
 it in a general case where the service does more than simple delegation.


If you use a more domain-driven approach, you don't need services as
much.  Your entities can have the repositories (daos) injected into
them via Spring's @Configurable/@Autowire support.  So, you can move a
lot of your business logic into the entities themselves.  Now,
sometimes you just have to use services because there's just no good
way to do some things, but for a lot of the usecases you'll encounter,
you don't.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Brian Topping
The best reason for me to keep a service/business layer talking to the DAO is 
to provide a clean transactional boundary.  Then, all I have to do is add a 
Spring @Transactional annotation to the method and I'm fully atomic.  

If my view logic is calling a half dozen DAO methods to effect an update, 
there's no way to have a single method demarcate the transaction.  Without a 
single method, no use of @Transactional, and I have to maintain complex 
transactional code by hand.  This is way more error prone and complex than 
taking (what are admittedly attractive) shortcuts to remove the service layer.

As a bonus, with well-defined service layer interfaces, I can easily generate 
SOAP or REST interfaces and expose them to other fat clients like mobile 
devices in the future.

On Jun 19, 2010, at 8:07 AM, James Carman wrote:

 Why do you have page - service - dao?  Why not just talk directly to
 the DAO for the getAll() method.  This level of indirection just
 causes more code (and confusion) in your simple example.  Is this just
 a best practice that you've devised?  I've never really understood
 folks' aversion to talking to the DAOs from the view layer, especially
 when it means you have to have duplicate methods in your service layer
 to do so.  It just doesn't make sense to me.
 
 
 On Sat, Jun 19, 2010 at 8:01 AM, James Carman
 ja...@carmanconsulting.com wrote:
 Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
 not just uset a {spring.version} property in your POM so that it all
 stays in synch?
 
 On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong k...@cpttm.org.mo wrote:
 Hi,
 
 I've written a tutorial on this topic. You may check it out at
 http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicket.html
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread James Carman
On Sat, Jun 19, 2010 at 11:54 AM, Brian Topping brian.topp...@gmail.com wrote:
 The best reason for me to keep a service/business layer talking to the DAO is 
 to provide a clean transactional boundary.  Then, all I have to do is add a 
 Spring @Transactional annotation to the method and I'm fully atomic.

 If my view logic is calling a half dozen DAO methods to effect an update, 
 there's no way to have a single method demarcate the transaction.  Without a 
 single method, no use of @Transactional, and I have to maintain complex 
 transactional code by hand.  This is way more error prone and complex than 
 taking (what are admittedly attractive) shortcuts to remove the service layer.


You can also annotate your Wicket pages/components methods with the
@Transactional annotation if you use the AspectJ compiler.  They have
to be public or protected in order for the compiler to pick them up
and weave them I believe.  No big deal, in practice, really.

 As a bonus, with well-defined service layer interfaces, I can easily generate 
 SOAP or REST interfaces and expose them to other fat clients like mobile 
 devices in the future.


Agreed, but having one method that merely delegates to another is just
plain silly, IMHO.  You'd probably generate custom services that are
tailored to the different view implementations so that you can
aggregate things correctly for optimization purposes.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Tim L Casey


That’s ok.  I never understood folks who don’t use layers.

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
Behalf Of James Carman
Sent: Saturday, June 19, 2010 5:07 AM
To: users@wicket.apache.org
Subject: Re: Getting started with Scala, Spring, Hibernate  Wicket

Why do you have page - service - dao?  Why not just talk directly to
the DAO for the getAll() method.  This level of indirection just
causes more code (and confusion) in your simple example.  Is this just
a best practice that you've devised?  I've never really understood
folks' aversion to talking to the DAOs from the view layer, especially
when it means you have to have duplicate methods in your service layer
to do so.  It just doesn't make sense to me.


On Sat, Jun 19, 2010 at 8:01 AM, James Carman
ja...@carmanconsulting.com wrote:
 Why is spring-orm version 3.0.1.RELEASE and not 3.0.3.RELEASE?  Why
 not just uset a {spring.version} property in your POM so that it all
 stays in synch?

 On Sat, Jun 19, 2010 at 7:23 AM, Kent Tong k...@cpttm.org.mo wrote:
 Hi,

 I've written a tutorial on this topic. You may check it out at

http://www.dzone.com/links/getting_started_with_scala_spring_hibernate_wicke
t.html




 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread James Carman
On Sat, Jun 19, 2010 at 12:06 PM, Tim L Casey tca...@cataphora.com wrote:


 That’s ok.  I never understood folks who don’t use layers.


I do use layers, when it makes sense.  It's just a matter of taste, I
guess.  Some folks like to stick with their paradigm no matter what.
I guess I've just become a bit more flexible when it turns out to save
me some code (like having pass-through methods just to have them).  If
I need to introduce some logic in between my view/data layers later, I
can easily do so.  Using services too much is a symptom of an anemic
domain model.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Tim L Casey


The reaction comes from years of watching UI centric people, who have a
different design goal, use dao code poorly; and then watching dao type
people use UI code poorly.

I guess I view the layering as inevitable.  Even if it is as simple as
moving a tag, I am not sure I want anyone to have that choice. 

-Original Message-
From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
Behalf Of James Carman
Sent: Saturday, June 19, 2010 9:12 AM
To: users@wicket.apache.org; tim.ca...@cataphora.com
Subject: Re: Getting started with Scala, Spring, Hibernate  Wicket

On Sat, Jun 19, 2010 at 12:06 PM, Tim L Casey tca...@cataphora.com wrote:


 That’s ok.  I never understood folks who don’t use layers.


I do use layers, when it makes sense.  It's just a matter of taste, I
guess.  Some folks like to stick with their paradigm no matter what.
I guess I've just become a bit more flexible when it turns out to save
me some code (like having pass-through methods just to have them).  If
I need to introduce some logic in between my view/data layers later, I
can easily do so.  Using services too much is a symptom of an anemic
domain model.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Brian Topping

On Jun 19, 2010, at 12:05 PM, James Carman wrote:

 On Sat, Jun 19, 2010 at 11:54 AM, Brian Topping brian.topp...@gmail.com 
 wrote:
 The best reason for me to keep a service/business layer talking to the DAO 
 is to provide a clean transactional boundary.  Then, all I have to do is add 
 a Spring @Transactional annotation to the method and I'm fully atomic.
 
 If my view logic is calling a half dozen DAO methods to effect an update, 
 there's no way to have a single method demarcate the transaction.  Without a 
 single method, no use of @Transactional, and I have to maintain complex 
 transactional code by hand.  This is way more error prone and complex than 
 taking (what are admittedly attractive) shortcuts to remove the service 
 layer.
 
 
 You can also annotate your Wicket pages/components methods with the
 @Transactional annotation if you use the AspectJ compiler.  They have
 to be public or protected in order for the compiler to pick them up
 and weave them I believe.  No big deal, in practice, really.

Sure, but AspectJ can be a machine gun in the hands of babes.  I try to avoid 
requiring team members be that qualified just to work on basic code.  Because 
once something like AspectJ is in the source base, it starts getting used, and 
before you know it, you have to start making solid experience with this new 
esoterica a hiring requirement.  Too expensive.

 
 As a bonus, with well-defined service layer interfaces, I can easily 
 generate SOAP or REST interfaces and expose them to other fat clients like 
 mobile devices in the future.
 
 
 Agreed, but having one method that merely delegates to another is just
 plain silly, IMHO.  You'd probably generate custom services that are
 tailored to the different view implementations so that you can
 aggregate things correctly for optimization purposes.

It's a pattern, and sticking with one pattern is very smart.  Especially 
because very few screens in a reasonably valuable application are only going to 
call a single DAO method.  It happens, but I'd question the value of the app at 
that point, and whether it needs transactions at all.  In that case, you are 
right, kill the service layer.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Getting started with Scala, Spring, Hibernate Wicket

2010-06-19 Thread Erik van Oosten
The latest and greatest in the domain-driven world would be CQRS where 
the UI code needs two types of dependencies: the command bus and a 
repository. No more need of a 'services' layer.


I adore CQRS because it provides a simple and clear view of what code to 
put where. Though the amount of code stays the same, it will be simpler.


Regards,
Erik.

PS. Kent, thanks for taking the time to write this tutorial.


Op 19-06-10 17:39, James Carman wrote:

On Sat, Jun 19, 2010 at 10:10 AM, Kent Tongk...@cpttm.org.mo  wrote:
   

I agree that if the service is simply delegating to the DAO without
adding anything, then it is probably be a good idea to merge them.
However, this sample application is meant to demonstrate how to do
it in a general case where the service does more than simple delegation.

 

If you use a more domain-driven approach, you don't need services as
much.  Your entities can have the repositories (daos) injected into
them via Spring's @Configurable/@Autowire support.  So, you can move a
lot of your business logic into the entities themselves.  Now,
sometimes you just have to use services because there's just no good
way to do some things, but for a lot of the usecases you'll encounter,
you don't.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

   



--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org