Thanks Isaac, I think you answered my question by stating that most frameworks don't help you with data access. If that is the case, then I could use FB/MG/whatever and then do the data access how I like. They might suggest I put my queries in a specific location, but after that I can make them 10 lines or 500 lines, and the framework will work the same.
As far as using views: we do use views here, and they are very nice. But let me give a simple example to explain why our queries can be complex. Say you have financial data in 3 different databases, all built by 3 different people. The reason there are 3 different databases is because the data is gathered by 3 different business units in the company. The Budgeting system needs to gather data from all 3 systems. For example, one page in the budget tool allows you to budget for a department's payroll. In order to put the necessary data on the screen (all of the info a manager needs to create his payroll budget), you have to query the budget database itself (for historical comparisons), as well as the human resources and the ERP databases. The reason for the first two is obvious, but the ERP system is where employees charge their work orders when they do capital labor jobs throughout the year. So a data query for the payroll budget screen has to join data from all three databases, hitting multiple tables in each. This is not a simple report though, because /every/ manager in the company will use this tool, so every query will be unique to that manager's department. Also, most of the data queries behind this page are virtually useless in the rest of the budget tool. We /could/ create a view that would simplify the above queries, however this view would be useless to any other page or tool because this specific situation is very unique. Am I making any sense? > -----Original Message----- > From: S.Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 12:58 PM > To: CF-Talk > Subject: RE: OOP, why me? > > > The queries we need to write to gather data can be very > > complex, often times in the hundreds of lines. Something > > I've often heard in the framework discussions is that > > you guys use these DAO thingies to simplify access > > to your data. I have always doubted that a DAO would > > be useful for my scenario, because our data queries > > are often very complex. > > If you continue to write your reports the same way then a DAO may not > help you reuse that code much if at all. A framework in general isn't > going to help with data access in particular (unless it happens to be > a DAO framework - I haven't looked at Reactor, so I can't comment on > that front). Although it really sounds to me like what your particular > environment lacks isn't so much OO but views... The power of a view to > simplify data access can be PHENOMENAL. I would be very surprised if > quite a few of your hundreds of line queries don't ultimately boil > down to a dozen or so well conceived views and would then be able to > produce very simple queries in your reports which probably could be > reused quite easily. Being able to reduce your queries from hundreds > of lines to tens of lines or less than ten lines I suspect would make > putting all those queries related to the same subject in a single DAO > make a lot more sense for you. May God have mercy on your soul if you > put dozens of queries with hundreds of lines each in a single DAO. > Templates (CFC or otherwise) with thousands of lines in them are > _NO_FUN_. > > > Here are the two big reasons I've heard people cite for > > using a DAO: > > > > 1. Abstraction of your database > > 2. Caches the data > > > > Sure, we /could/ use a DAO, but it would be very specific > > to the one report it is used for. What's the point of > > using an object if you only need it one page? > > A DAO object typically has a collection of related data access methods > in it, so the same object would be used in several places, even if a > given method only appears on one page. Which may seem like a waste on > an individual page, and you might not be wrong if you create the > object for each request (instead of storing the object in memory) > because the server has to create the object and every method in that > object means one more thing the server has to create (an object called > a "functor" if you're curious enough to look it up on Wikipedia). > However the amount of time required to create a single method is > typically very small, so even if you do recreate the object on each > request sometimes the benefit of having all that database access in > one place for simple organizational reasons can be beneficial in > helping you see the bigger data-access picture in your application. > > > Also, I really don't want the millions of records > > that would be filtered sitting in memory on my server. > > The whole reason databases were created in the first > > place was so that you don't /have/ to carry data > > around in your applications, you just grab the pieces > > you need, when you need them. Caching makes sense if > > you have a user table with a couple hundred records, > > but when you are querying a financial ledger that > > contains millions of rows, I'm not sure I'd want to > > pre-cache the data. > > There are two types of caching which may or may not be relevant here. > The first is the type I described above where you have a CFC which > you've stored in memory, however, having stored that component in > memory doesn't require you to store the returned data in memory (the > second type of caching). Typically with a report you would not cache > the returned data, you would simply write a function ("method") in > your CFC which executes your query. Caching of data is typically used > for individual records when you're using "object-relational mapping" > (ORM) to provide data to "beans". The performance gained from this > scenario is mostly in the CRUD portions of an application -- an > individual detail view page may not need to access the database if the > information for the desired record is already stored in memory. > > > I realize I may be butchering things here, as I've never > > used a framework. So please don't take this as an attack, > > but rather as an attempt to understand the benefits of > > frameworks, and how they could help me. > > I suspect that most frameworks don't really address these issues in > particular. Most frameworks actually say very little about data access > (unless it happens to be a data-access framework, which is uncommon) > -- their authors may mention or recommend DAO's, but as is the case > with Fusebox, Mach-II, Model-Glue, the Hub, etc. most of them don't > more than hint really at what they think might be a good place to put > your ad-hoc queries. > > The onTap framework is a whole other animal together -- I'm not > convinced it would do much for your issue of having hundreds of lines > of query code... It could if you used the sql-abstraction API and you > have foreign key constraints in your database, it might save you a > fair lot of keystrokes (particularly if you're using a lot of > cfqueryparam tags now, and or if you currently use a lot of manual > testing for url variables to set filters, since the onTap framework > will let you select.collectionFilter(url) to simplify that process). > Although given that I suspect your company is standardized on a single > database platform (Oracle?) you're not likely to need some of its > features like platform independance. > > But -- as I said -- this is sort of the exception to the rule anyway. > Frameworks as a whole don't really focus much (if at all) on reporting > either ... Not that you wouldn't get the same benefits from a > framework that you get with any other application, but they generally > don't offer any specific tools that would be helpful to reporting apps > -- at least, not that would be more helpful to reporting than to any > other task. > > I find myself wanting to offer up some suggestion of the benefits of a > "traditional" framework to your specific environment, (FB / Mach-II / > MG -- I won't call onTap traditional, although it has some of the same > features in addition to its other APIs) but I think I lack enough > practical knowledge of exactly how your environment operates to make > it at all useful to you. [INFO] -- Access Manager: This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234527 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
