> 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.
s. isaac dealey 434.293.6201
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234504
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
