RE: [Reactor For CF] Reactor R&D

[Doug Hughes]

I just wanted to say I’ve read this, I’m thinking about it and I’ll respond at some point in the future.   Doug   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Jackson Sent: Wednesday, March 22, 2006 3:46 PM To: reactor@doughughes.net Subject: [Reactor For CF] Reactor R&D   Hello everyone,   Over the last month, we have been building a prototype application-skeleton using Reactor in conjunction with Mach-II, & Coldspring and have made lots of interesting discoveries.  I would like to share these with the list to both praise Doug and the contributors for the amazing advancement in the area of Coldfusion persistence as well as raise a couple of concerns for debate to the great minds here.   To begin, it is important to understand that we build very large applications and have been using Mach-II and Coldspring to reinforce an application architecture that promotes reusability, scalability, & extensibility.  Most of our applications we would consider “enterprise applications” and the following ideas are based in that context.  The applications typically consist of a service layer (managed by Coldspring) from which Mach-II listeners, Flash Remoting, and Web Services interact with.  The service “beans” delegate tasks to an underlying CFC library consisting of component packages that deal with specific business objects.   These business object “beans” are generated initially by a CRUDGEN application that is tuned for our development pattern; after the initial objects are generated (business object beans, gateways, DAOs, Listeners, and service beans) we add the custom code that brings the components together.   Reactor presented itself as a fantastic way to remove the “generate once” approach and database dependencies, as well as, a further reduction in labor costs.  Initially we were hesitant to pursue a prototype because of the lack of table aliasing; however, Doug graciously added that and a few other key features recently.  These additions tipped the scales here and were enough to convince management to allow time for a prototype.   We took our standard pattern and inserted Reactor under-the-hood.  Very carefully, we worked our way through each layer and evaluated the potential influences Reactor would have on future applications as well as those we have already created (retrofitting).  After roughly three weeks of discussion, testing, and tweaking we have come to a very pleasing discovery… Reactor only had three issues that raised concerns across the department; all three technically could be avoided by customizing Record objects—but one we feel needs to be addressed because it is fundamental to application patterns in general.   To start, let’s talk about the one critical issue.  Using Reactor forces a naming convention on embedded Record objects within the application.  Instantiating a Record object allows you to use your own naming convention (i.e. – myBusinessObject = reactorFactory.getRecord(‘myBusinessObject’)) and that is great; however, if “myBusinessObject” has a hasOne relationship to “myRelatedObject”, no matter what you alias your “myRelatedObject” in the configuration file it will force you to call that object like this: myBusinessObject.getMyRelatedObjectRecord().   Ok, so what is the big deal?  Well, essentially when we evaluate frameworks we look for anything that requires us to use techniques that are specific to that framework (dependencies) that might interfere with potential replacements in the future –or those that require lots of retrofitting.  When it comes to beans, it is important that we can call them what we want and use those names to call embedded objects.  We feel that beans should not be “typed” by a naming convention anyways because it should not matter to the application what goes on inside of the bean as long as it does what it is supposed to.  So, for the previous example, to remove the Reactor-related naming dependency it would be myBusinessObject.getMyRelatedObject()—notice that “Record” is not there. This is how all of our existing applications look.    One could argue that we could customize the Record object to have a getMyRelatedObject() method that calls the getMyRelatedObjectRecord() method but it is common enough principle that I would like to request a dialogue about it.  The remaining two items—we have no argument that is valid as to why we can’t work around them, and they are: the iterator, and the query API.   The Query API, as we all know, is a little slow and that is the only beef we had with it.  If the performance were better it would be an outstanding syntax to use for CRUDGEN in that it is much easier to build Query API statements as opposed to the raw SQL.  We will simply choose not to use that API yet (but will likely auto generate the commented out code for future use).  As for the iterator, it simply creates to strong of a dependency above the service layer for us therefore we will opt to not use it; rather, we will direct our query requests to the service layer and have it get them from gateways. So, all-in-all Reactor slips right into our application pattern relatively painlessly.  For those who choose to use the iterator in layered applications, they should be aware that it does bind them to the Reactor framework, or at the very least, requires them to replace it should they migrate to another persistence framework in the future.   With that being said, Reactor rocks (bravo Doug) and we would like to hear feedback regarding the myBusinessObject.getMyRelatedObjectRecord() naming issue.  One idea we have is that the framework provide a clean named method in addition to the “Record” appended method if people are already using Reactor in production.     Sincerely,   Shannon Jackson     -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/