Dave Watts Said:
"There just isn't that much CFML code to organize!"
And that about sums it up, folks. If you have an application without "that
much CFML" then you don't need any kind of organization.
However, if all your business and application logic is performed by CF and
SQL and you don't use more than those 2 tiers (CF for logic and display and
SQL for backend), then a structured application architecture (like Fusebox)
is mucho important, regardless of the minor decrease in speed for numbers of
included files.
Nat Papovich
ICQ 32676414
"I'm for truth no matter who tells it."
-Malcolm X, 1965
-----Original Message-----
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 20, 2000 3:03 PM
To: CF-Talk
Cc: Nat Papovich
Subject: RE: fusebox style: too much disk access?
I was afraid this would happen. I'm surprised that Sean Renet hasn't
contributed yet, though!
> What-evah, Dave. Fusebox kicks ass for the very implementation
> you mention. COMs can be called from a single file (using a new
> prefix com_filename.cfm if you want), then whenever you need
> that COM, you cfinclude that file.
Well, I could do that, but for most purposes, what would be the point?
Let's say I use a COM object many places in my application. This doesn't
mean that I'm going to use the same methods and properties of that object
each time. So, I create a file:
<!--- com_foo.cfm --->
<cfobject type="COM" class="MyClass.Foo" name="oFoo" action="CREATE">
<!--- end com_foo.cfm --->
OK. Well, that sure buys me a lot, doesn't it? Admittedly, you might reuse
some of the methods and properties, but then again you might not. The point
of using COM, in my opinion, is that it IS an encapsulation - I simply
instantiate the object, then use it. I don't need to encapsulate the
encapsulation!
> Maybe it would help us if you made a distinction between
> application logic encapsulation and business rules
> encapsulation. If you do both within COM/EJB, then you
> practically don't even need CF for anything other than
> CFOUTPUT. If however, you want application logic in COM, but
> still want business rules in CF, then Fusebox is great. No?
>
> It seems to me that if you remove application and business
> logic from CF, then a structured application architecture
> (like Fusebox) becomes less of a necessity. What kind of
> CF architecture do you guys use in EJB/COM-heavy apps?
In my world, application logic is the whole enchilada. Business rules are a
subset of application logic; specific algorithms written to model rules and
limitations imposed by the business process. In the real world, of course,
it's often difficult to cleanly separate business rules from everything
else, but we try.
In most Fig Leaf applications, we actually don't use all that many COM or
EJB components, although we're certainly moving in that direction more and
more, it seems. However, we're still distributing application logic across
multiple tiers.
We'll often place significant amounts within stored procedures. Now,
according to Fusebox, we should then place the stored procedure calls within
separate "qry_" or "act_" files. Of course, since all the real code is in
the stored procedure, and we often call the stored procedure using CFQUERY
(as we can then cache the recordset using CFQUERY's caching attributes),
we'd have something like this:
<!--- qry_foo.cfm --->
<cfquery name="foo" datasource="bar"
cachedwithin="#CreateTimeSpan(0,1,0,0)#">
{ call myspFoo(#mynumericparam#, '#mytextparam#') }
</cfquery>
<!--- end qry_foo.cfm --->
Again, not a lot of reuse value. In fact, at this point, using Fusebox seems
to me to be just another layer of abstraction I'd have to deal with.
That's really where I draw the line. I could use it with anything - frames,
JavaScript, WML, COM/EJB, stored procedures, etc. However, at a certain
point, it adds complexity rather than making things simpler. The reason I
like CF is that it's a comparatively simple, high-level language which is
easy to read. Given that within a well-constructed application, you're
generally going to have a relatively self-documenting structure of
directories/subdirectories and of functionality, the price for making every
last line of code so self-descriptive seems a bit high to me. There just
isn't that much CFML code to organize! The amount of organizational
structure in Fusebox seems to me to exceed the amount of algorithmic
content.
As for what kind of CF architecture we use (whether in object-tier apps or
not), we simply use a "common sense" architecture. We design the application
before building it, and we organize the CF portion of the application in a
modular subdirectory structure. We have some standards for using
frames-based interfaces, we have other standards for using JavaScript to
work with recordsets on the client, and so on.
Within our organization, we frequently move developers from one project to
another, without any major difficulties in understanding the flow of the
application.
Finally, I've never told anyone "don't use Fusebox". I've said that I don't
think it's the best choice for everything, and that I don't use it. If you
like it, go ahead and use it! But if you don't, don't use it just because
"it's what everybody uses".
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
----------------------------------------------------------------------------
--------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a
message with 'unsubscribe' in the body to [EMAIL PROTECTED]
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
