Hi Dan, I don't think we ever did! It's a useful set of J2EE patterns. I personally use a service class and DAO per business object as it allows me to gen apps much faster than creating a custom set of mappings between service classes, business objects and DAOs. I like the service and DAO patterns as I find a good separation of concerns. I implement a custom data mapper in my base DAO and all works well for my use case. That said, look in Smalltalk/Ruby/Python and you'll see class methods used in place of Service singletons and you'll see some apps which abstract db access and some that don't. I think it is great to look at the various patterns. I personally think they're a little more evolved in Java than in C# and in Ruby than in Python (Python, like CF isn't *that* OO - 2.5 still has a couple of different ways of creating objects, a bunch of headless functions, primitives, etc), but you can learn something from every community. Looking forward to your postings!
Best Wishes, Peter On Jun 24, 2008, at 1:49 PM, Dan Vega wrote: > I have a good friend who is a Python developer as well so I hope to > pick his brain. I am just saying that I think Adam has the right > mind set, we really need to stop talking about DAO,Gateways & > Service layers as the end all be all. > > Thank You > Dan Vega > [EMAIL PROTECTED] > http://www.danvega.org > > On Tue, Jun 24, 2008 at 1:45 PM, Peter Bell <[EMAIL PROTECTED]> > wrote: > Well, if you want to see OO in different languages, I'd look at: > Java - high ceremony, good for large apps > Ruby - low ceremony - very dynamic. Just remember not to blow your > leg off > Smalltalk - The granddaddy of OO languages but still used in some > domains. Check out seaside for a continuation based web server. Very > interesting and I'm hearing it scales better than I'd have expected. > I think it'd dabbleDB that was written in Seaside. > > Best Wishes, > Peter > > On Jun 24, 2008, at 1:38 PM, Dan Vega wrote: > >> Adam, >> I am sure you going to hear some slack for that but I am huge fan >> of what you just said. In Hal Helm's presentation he noted that we >> really need to quite being so data centric when thinking of OO >> development. MVC is a great start for people to solve a specific >> problem but everyone really needs to stop following everyone and >> thinking that 5 cfcs are OO development. I am doing a lot of >> research at the moment about OO in other languages and hope to >> share my findings soon. >> >> Thank You >> Dan Vega >> [EMAIL PROTECTED] >> http://www.danvega.org >> >> On Tue, Jun 24, 2008 at 1:34 PM, Adam Haskell <[EMAIL PROTECTED]> >> wrote: >> At the end of the day we all need to stop talking about DOA and >> Gateways and all this Database crap as much as we do. Its old, >> trite, and quite honestly doesn't make a hill of beans difference >> most of the time. Honestly, ask yourself, "How many applications >> would I have been completely screwed if I chose to split my gateway >> and DAO up, or vice versa?" If you have a use case for that please >> by all means share it I'd love to hear it. If all we are concerned >> about is DAO or gateway then chances are something else, much more >> important, is being overlooked (not pointing fingers at anyone >> here :) ). If all you are doing is a large reporting app chances >> are you don't need to be doing complete OO anyway, yes I know >> sacrilege. Its true though ColdFusion is perfect for reporting >> without the heavy OO we try to apply to it in too many cases. >> Thinking back through some of the reporting apps I did and >> shoehorning them into an OO architecture I can confidently say I >> should have stuck with a light version of MVC and moved on. >> >> Adam Haskell >> >> >> >> >> > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
