|
Hi Doug, Ok, that helps me formulate my
response. Give me a bit and if I
can get this deadline done in time tonight I will respond with some clear
answers… if not, definitely tomorrow in the a.m. Quick disclaimer– I don’t think
I ever said that I saw a problem with the Iterator naming convention, just
pointed out its dependencies above the service layers and why we wouldn’t
use it. It is a great tool for fast turn-around smaller applications. Only the “record” naming
convention is an issue. I will be back with a response. J From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes 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 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”? From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Hughes 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 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 |
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Kurt Wiersma
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- Re: [Reactor For CF] Reactor R&D Kurt Wiersma
- Re: [Reactor For CF] Reactor R&D Sean Corfield
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Sean Corfield
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- RE: [Reactor For CF] Reactor R&D Doug Hughes
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- RE: [Reactor For CF] Reactor R&D John_Farrar
- Re: [Reactor For CF] Reactor R&D Adrocknaphobia
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Kurt Wiersma
- RE: [Reactor For CF] Reactor R&D Shannon Jackson
- Re: [Reactor For CF] Reactor R&D Peter J. Farrell
- Re: [Reactor For CF] Reactor R&D Sean Corfield
