Well I think that most of us are glad to know that this very issue is not one that just the CF community faces.
Thank You Dan Vega [EMAIL PROTECTED] http://www.danvega.org On Tue, Jun 24, 2008 at 2:37 PM, Brian Rinaldi <[EMAIL PROTECTED]> wrote: > Hal made some great points that philosophically I agree with but that I > think you'd be hard pressed to find a company willing to implement it > (mostly talking about larger companies with established IT depts). For > instance, he said the model should drive the database and not the other way > around. Great, I agree....but the reality is that most companies you are > working with a database that pre-existed the web app or a database dictated > by a DBA group that is not closely tied to the developers...etc. The point > is, we can talk all these very high-minded ideals but they tend to run > aground when put up against the entrenched system at a typical company > (which is probably why OODBMS's never caught on in the first place). That > separation of database expertise and programming expertise was probably > created for a reason...though don't ask me to explain why (we programmers > tend to think we should have domain over everything...and though I agree I > am fairly certain I am wrong ;). > > Anyway, it is, to me, a matter of understanding the difference between the > "best solution" and the "best available solution". 9 time out of 10 > (especially at big corps or govt) these two don't match. Depending on your > organization the best available solution may be many degrees worse than the > best solution but its generally better than the "current solution". Its a > matter of understanding the limits of ideals. > > This is the piece I told Hal at dinner I thought he missed. Code generators > and ORMs are probably a philosophically poor solution to a problem since > they do tend to create very data-centric models but they are a solution > nonetheless. So, when you get all the Acme Corps on OODMS's, then I might > reevaluate :) > > > > >> On Tue, Jun 24, 2008 at 2:08 PM, Dan Vega <[EMAIL PROTECTED]> wrote: >> >>> I think Sean brings up a really great point here. In very data centric >>> applications (bunch of forms and reports) a light mvc pattern to help >>> seperate your model and view might be all you need. Maybe only certain >>> features will follow a pattern. Its your job to learn the patterns and as >>> Sean said always be mindful of them. >>> >>> "if you have a very data-centric app with almost >>> no "behavior" (i.e., it's almost pure data entry or pure reporting) >>> then OO might be a waste of time for you - or maybe only parts of the >>> app will benefit from OO, perhaps at a very high level in the service >>> layer." >>> >>> Thank You >>> Dan Vega >>> [EMAIL PROTECTED] >>> http://www.danvega.org >>> >>> On Tue, Jun 24, 2008 at 2:05 PM, Peter Bell <[EMAIL PROTECTED]> >>> wrote: >>> >>>> Thats why I tend to prefer code gen/frameworks that start with a >>>> description of the model and then gen any persistence required if your use >>>> case (read no DBA and a green field app) allows it. >>>> Best Wishes, >>>> Peter >>>> >>>> >>>> On Jun 24, 2008, at 1:49 PM, Brian Kotek wrote: >>>> >>>> This is caused in a large part by the code generators that introspect >>>> the database and generate CFCs. While those can be great time saving tools, >>>> the reality is that most people just take what gets generated and then run >>>> with it without thinking further about what they're doing. >>>> >>>> This is why we get people with 5 CFCs for every single table in their >>>> database, and why people think that just because they're following these >>>> "patterns" (bean, DAO, etc.) that they are doing OOP. If everything is >>>> data-centric and there is no actual behavior in the objects, then all one >>>> really has is a totally procedural, data-centric application that has been >>>> shoved into CFCs. It really ends up being the worst of both worlds: all the >>>> complexity of OO with none of the benefits. >>>> >>>> Hal is completely correct that we need to get away from the fixation on >>>> data or slavishly following patterns without really understanding the >>>> tradeoffs involved. Each pattern has consequences, and not all of them are >>>> good. The unfortunate reality is that truly groking OOP takes a long time >>>> and a major shift in mindset. There's no easy route to getting there, but >>>> one route that is probably among the most difficult is to blindly apply >>>> patterns or let code generators "do the work" without truly understanding >>>> what's going on or why these patterns exist. >>>> >>>> On Tue, Jun 24, 2008 at 1:38 PM, Dan Vega <[EMAIL PROTECTED]> 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 >>>>>> >>>>>> > > > -- > Brian Rinaldi > blog - http://www.remotesynthesis.com/blog > ColdFusion Open Source List- > http://www.remotesynthesis.com/cfopensourcelist > Boston CFUG - http://www.bostoncfug.org > Adobe Community Expert - > http://www.adobe.com/communities/experts/members/brian_rinaldi.html > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
