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<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
