RE: [Reactor For CF] Reactor R&D

[Doug Hughes]

Shannon,   The reason I think the “record” moniker is important is because it’s consistent with the rest of the framework.  (Call me on this if you think I’m wrong.)  For example, getXyzIterator indicates that the method returns an Xyz Iterator.   Ultimately, it’s not an “Xyz” you’re returning it’s an “Xyz Record”… in the same way that it might be an Xyz Iterator or Gateway or whatnot.   I feel strongly that adding a second method, getXzy which simply calls getXyzRecord is a mistake.  It unnecessarily complicates the interface.   Doug   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Jackson Sent: Wednesday, March 22, 2006 7:33 PM To: reactor@doughughes.net Subject: RE: [Reactor For CF] Reactor R&D   Hi Doug,   These are some good questions, and I am going to try to get a response in tonight or tomorrow.  However, to supplement my response I would like to first reverse the question and ask why it is necessary to append these methods with “Record”?   Shannon   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes Sent: Wednesday, March 22, 2006 6:20 PM To: reactor@doughughes.net Subject: RE: [Reactor For CF] Reactor R&D   Shannon –   I’ve been thinking about this and, to be brief, I’m not convinced by your arguments about the naming of the getXyzRecord methods or the Iterator methods.  Of course, you could use the framework without either, but you’d loose a lot of the real power.  Furthermore, I don’t see why you’re concerned about the implementation details of your persistence framework when you’re not about, for example, Mach-II.  With Mach-II you have certain interfaces you need to code against and certain framework-specific conventions.  I don’t see the difference.    Can you make any more persuasive arguments as to why the getXyzRecord method should be renamed?    It sounds to me like these two arguments really come down to things you can get around by customizing the generated objects, though I don’t see why you would.    With regards to OO Queries, have you tried them within the past few days?  Last week Sean set the query objects to be pooled.  His implementation made the pool, more or less, optional.  Within the past few days I made this the default behavior and, if I can be trusted as an objective judge, I think it’s markedly faster.  (Note: simply running one query won’t show the improvement.  You’ll get the best results running them in an application under load.)   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/ -- 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/