One other quick comment: the suggestion of having a second method getXyz() was meant to be a middle ground idea. In practice, we would not have two methods, rather only one named getXyz()-- having a named defined entirely by the business model not by reactor. The iterator is a completely different issue.
We would be happy to show you some more elaborate examples to help shed light on what we are talking about. - Shannon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shannon Jackson Sent: Thursday, March 23, 2006 7:08 AM To: [email protected] Subject: RE: [Reactor For CF] Reactor R&D Hi Sean, On the contrary, removing the unnecessary "Reactor" appendage does in fact completely abstract Reactor. We are try to explain that by not having that there we can slip Reactor into existing apps with no modifications to the application above the service layer. So, simplifying Reactors embedded bean calls makes a world of a difference when it comes to migration. It is so close to being abstracted as it is, we are trying to suggest that this small change would make Reactor better than perfect. Beans are beans and we should be able to name them what we want no matter what is going on inside of them. - Shannon -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Thursday, March 23, 2006 12:34 AM To: [email protected] Subject: Re: [Reactor For CF] Reactor R&D On 3/22/06, Doug Hughes <[EMAIL PROTECTED]> wrote: > Something that jump out are the point about the "record" convention (is it a > convention or is it just part of the API?) in Reactor. I doubt that you're > going to have much consistency between different ORM frameworks in their > approach to problem solving. This means that another ORM framework would > probably have it's own API and it's own set of issues. Having worked with four of the ORM frameworks - and written them up in my Objects & Persistence talk (download it from my blog) - I can only agree with Doug here. Each framework exposes a different API, a different naming convention. I really don't think it is realistic to expect to be able to simply swap out one ORM for another. I do not think that changing the naming conventions in Reactor will help you here - the naming conventions will be different in each framework so you will still need to either write an adapter for each or modify your code. I think the Reactor naming convention is clear and appropriate - having multiple methods called getXyz() that return a record in one case and an iterator in another case would be a terrible idea. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
