The benefit of those layers is never really apparent in the simple examples. In fact, if that’s all your app is doing, I’d venture to say it is overkill. (Heresy, I know!)
I fought with the same issues myself when I first starting using beans, daos, and services. It just felt like a bunch of empty layers. It makes a lot better sense when your beans and services start filling with business logic and the separation is more apparent.
This is the way I see the breakdown and the benefit it gives:
- DAO: store and retrieve data for a specific business entity, or a set of tightly coupled entities.
- Bean: contains all logic and attributes DIRECTLY related to a specific business entity
- Service: contains all logic for a set of inter-related business entities and handles their interactions together. Also CAN a good place to enforce security or persistence. Your services are the “gateway” to your models.
-
Controller: Directing the flow of the pages on your site and what data is coming in and out. Deciding what views to display, what layouts to use, etc. This is where it can be easy to stick business logic, but you shouldn’t. My test is that you should be able to do most everything the core of your app does (as far as loading, saving, and processing your models) with using nothing but the Services. The controller is just there to direct traffic.
Anyway, that’s just my 2 cents based on my experiences. Other people might see the break down differently, but the main point is each layer has its own job and that job isn’t necessarily apparent (or necessary) unless your app is large enough to have some meat on it. Oh, and for the record, I’m for fat beans, thin services, and thinner controllers, but that’s really a matter of preference.
Thanks!
~Brad