Method 2:
I create a folder called "products" inside I have one handler for each
method. And the handler has only a "index" method.
So there are the following event handlers:
products/method1.cfc
products/method2.cfc
products/method3.cfc
I know, it depends of the complexity of each method (it's about 100
lines of code). The reason for splitting into multiple handlers is
readability (I prefer more smaller cfc's than one big cfc)
My question is, if there can be a performance-/memory issue
esspecially with method 2, because there are now 3 cfc's instead of
one (in the final application there'll be maybe 20 cfc's)
Or is this just piece of cake?
With out knowing how its structured from a UML point is hard to say,
but you need to look a few different design pattens. I would
personally would have a master product handler which other product
functions inherited from (i.e. a product always needs a price), not
just for the sake of it but look at restructuring your product.cfc
into smaller reusable bytes of code. You may find out there is no need
to have that many functions in the first place. CB and CF works very
well with a lot of pattens.
I don't know about your level, but for me the CB docs and some of the
head first books really helped me understand how to build better apps
This isn't a bad method and performance wise there shouldn't be much
difference. One thing that I do is create a base handler for per common
functionality, so in your example, I would create a
productBaseHandler.cfc and have the method1, method2, method3 cfc's
extend that and keep any functionally common between them in there.
Perhaps you can inject a productService into the productBaseHandler so
it is available to all your other handlers, etc. I would also shy away
from having only one method per handler, this doesn't seem to make good
sense. If your handler has that much logic in it, perhaps more of that
logic needs to be moved to your model. Luis's book lays out some good
rules of thumb about how to logically divide up your handlers, so if you
haven't, take a look at getting your hands on that.
Without knowing specifics of how your methods differ, I'd recommend
Method 1. One "Products" handler is best to encapsulate multiple
events (methods) regardless of their size/complexity. There seems
little point in creating separate CFCs with one method each. Method
2 looks like it presents more difficulty in maintaining the code as it
doesn't seem particularly scalable or expandable (one change that
affects all methods has to be made across every file - say autowiring
in a new service obj they all need). If it is for readability only,
an editor like Eclipse will have an outline mode where it hides CFC
methods (same thing it does with comments running multiple lines) and
you then show/hide (+/-) them at will.
If you really want to go Method 2, definitely read what Curt was
recommending up thread. Expanding on what he was saying, if you do
need greater granularity for the same Handler functionality, extend
children handlers from the same parent handler (which itself extends
from coldbox.system.EventHandler as required). That way you can
easily modify/expand the methods later - in my example above, if you
wanted to autowire in a new service object that all methods need to
access to, you'd add it to the base/parent handler and all children
would then inherit it.
I've done Coldbox handlers via inheritance with great success - with
bonus of keeping my code DRY and easily maintainable. (Handy for
having a generic set of event handlers for common activities like CRUD
but then any one child handler can override or extend that core
functionality as needed.)