rc is available in handlers, interceptors, layouts, views-- pretty much everywhere BUT your model. (They should be a bit of a black box to your framework) I don’t use services very often in a view, but when I do need them I set the service (which is injected into the handler by WireBox) into rc as rc.myService = variables.myService; and then just hit rc.myService in the view.
If I don’t need methods (behaviors) from the service, and just data, then I’ll usually set the data into rc in the handler like so:
rc.data = variables.myService.getData();
All that being said, you can call getModel(“myService”) from within the view if you really want to or are just testing things.
I inject things into both my handlers and my (domain) model all the time. Typically, whatever that object needs to do it’s job.
For a handler, it’s whatever service it needs to delegate to for processing of that action. For a model object, it’s whatever other model objects are required to do its job.
Just try to keep “business logic” in model as much as possible. There’s many schools of thought, but my motto is fat beans, thin services, and even thinner controllers (handlers).
A good litmus test is that when you are building a new piece of functionality (say a shopping cart), your model should be able to completely perform all actions related to a shopping cart without any controller code:
I was wondering what were the boundaries for the functions in a fat bean and whether it communicates directly with the DAO or the service. Also, what logic should be put in the service. I found a small post from Brad which gave me the answers:
"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.
