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 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
--
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
