I am trying to use my service layer in my own front-controller style
framework and I've always been taught to decouple the service layer
from the controller layer, so that service layer is decoupled.
This is causing me issues as I need to access important front-
controller methods from my services, so I'm jumping through hoops to
try and make this happen.
I noticed when looking at Coldbox however that the actual framework
regularly passes the Coldbox controller through to its own services.
Can and should this really be done, and if so why is this ok?
The ColdBox framework and toolkit abstracts many complexities for a developer including the front-end controller. I believe it has every right to pass references to the controller, because, from a developers application it’s all “coldbox”.
My service layer is unique to my application and completely decoupled. I only pass in data input and get data output. The service layer can work in ColdBox, FW/1, no-framework other than ColdFusion or the custom framework you are rolling on your own.
I think you may be confusing your service layer with the responsibility of your front-end controller. For example, if you have a service which manages a bank account, the service should only need an input of an account number to respond with the total funds available. Your front-end controller should be responsible for controlling access to the service. You may create a security service to help your front-end controller with this task, but, the security service should only ask for the username/password and respond with a true/false (or array of accessable roles). Still, none of these services need to know about ColdBox.
Because ColdBox is a framework and toolkit, it does offer dependency injection–but, that is a completly different story than worrying about the Framework Cotroller within your service layer.
I am referering to system.web.services.requestservice.
It has an instance of the controller associated with it.
That's what I'd like to do in order to be able to reference controller
methods, but have always been under the impression that services are
just data in/data out (no controllers etc).
system.web.services.requestservice is part of the front-end controller framework–not a true service. It’s responsibility is to facilitate capturing a request and providing a unique context for the request throughout the application livecycle.
It is a “private” service of the framework. It is not an “application service”. Don’t let the appearance of the word service fool you.
To second Puc’s question… I’m interested in this and some of the other architectural decisions that have been made around how the overall Coldbox codebase is structured. Maybe the subject of “Architecting ColdBox” would be a good topic for a ColdBox Connect session.
In the context of a web application built on ColdBox, I don’t believe passing around handler/controller references is a good idea. It’s probably a better idea to take a look at the way your front-controller is structured. I can’t think of a reason why you would need a master/front controller that your other controllers need access to. I tend to think of ColdBox as the front-controller itself and try to work within the best practices / structure that ColdBox encourages.
If you have any specific examples of what you are trying to accomplish, maybe someone on the list can make some suggestions on an easier/cleaner way to structure the application.
Which brings me to my next suggestion for a ColdBox connect session… It would be great to have some high-level architectural best-practices for how to structure a ColdBox application. While there are some good sample applications, I find that these are all pretty basic apps. I would like to see the ‘coldbox’ way of building an advanced application that has restful services, AMF remoting, a mobile interface, a web interface, ajax interactions, a management interface, etc. While I understand how to accomplish these independently, my code tends to lose structure/focus as I add more and more functionality.
The application is basically a widget rendering engine. A request
(webpage) can have 1 or more widgets on it, which are self contained
modules of functionality (like iGoogle).
I have each widget setup up as a controller as each one has many
methods and each method has one or more model calls for data, and then
a view for display.
therefore to render a request I currently need to:
1] run the request controller (for the entire request/webpage)
2] run a process method which gets a list of widget assignments from
db for the current webpage, then loops over the widgets and runs each
widget's default method.
Each widgets default method then needs to use model and view to get
data and display.