Hey Justin;
the option I am considering for heterogeneous systems will be to handle them via web services where Query translates to QueryBean directly. Depending on the requirements of the client (i.e. how much money they are paying) a thin layer could be added that acts as an Adapter of complex CF types (i.e. Query) to whatever they require.
Thanks Kleanthis
On Apr 19, 2005, at 12:12, Justin Balog wrote:
Quick follow up, will your client pool be limited to CF/(and possibly flash)
in the future? Or do you see you self planning on more heterogeneity in
your applications. If so, I would like to hear how others handle aggregate
data so that it is typed neutral and record sets can be handled by various
clients.
Thanks,
Justin
-----Original Message----- From: Kleanthis Economou [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 8:53 AM To: [email protected] Subject: [CFCDev] Inter-Tier Considerations
Hey everyone;
I am new to this list so if the topic has been discussed before, I apologize – please feel free to point me somewhere else (web, listserv etc if you are aware of a more appropriate place for such discussions).
I am called to architect a solution. With the exception of changing backend, I have virtually the freedom to do whatever I want and one of the options I am exploring is CF7/JRun4. Truth be told, the news of the acquisition yesterday doesn’t help me much, but let’s ignore that (hopefully).
Brief overview: We use Oracle as our backend. CRUD operations are handled via packages (Stored procedures/Functions). In other words, there is a Façade to the CRUD plumping. (That said, a few ad-hoc queries will occur, but more so during proofs of concept and early development.)
As a result, we’ll have a thin Data Access Layer, where the Data Access Object’s hide the plumping of interfacing with Oracle.
A Domain Layer with some Business Objects, and a Service Layer that will serve as a boundary.
Various clients (that is, other CF apps we will write, as well as Flash clients eventually), will interface with the Service Layer. The CF-clients will consist of a Presentation Layer of course, and a glue layer (Mach-II) that will glue the Presentation Layer with the Service Layer.
OK, so maybe it wasn’t a very brief overview.
Implementation is not a consideration except Inter-tier communication. Obviously Transfer Objects come to mind, however given the nature of CF and CFCs, I am not fully convinced. Let’s see why.
When performing an operation such as a search (and by that I don’t just mean typing a search string, I mean finder operations in general for display purposes, to populate UI etc), multiple elements can be the result. Unless it’s a small handful. the strategy of creating Transfer objects and returning them to the client even if it is a CF-app becomes quite expensive and should likely be substituted for a Read Only RowSet Strategy. This is something the Query objcect in CF fulfills. Maybe not as encapsulated as would be done otherwise, but to counter for that it brings simplicity.
I’ve thought of wrapping Query into a ReadOnlyRowSet object, and use that as a TO. But this increases complexity in the Presentation Layer of CF-clients at least. Having a Query, you can just spit out tables, populate cfselect’s with minimal to no effort etc. Then I thought of writing CFXs that will simplify the interaction in the Presentation Layer but this strategy increases development and maintenance complexity. Yet further I thought we could expose the Query that's in the ReadOnlyRowSet for those cases Presentation would be simplified, but then it defeats the purpose of abstracting it.
I would like to hear your thoughts on this, and how you handle finder operations. Do you abstract Query, or not? Do you use it as a TO, or do you always create collections of TO's from your the results you get from your data access layer?
Thanks for your feedback Kleanthis
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
