ColdFusion queries can be consumed via web services in .NET, COM, Java, and CF with minimal complications. What other support would be necessary?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Balog Sent: Tuesday, April 19, 2005 11:13 AM To: '[email protected]' Subject: RE: [CFCDev] Inter-Tier Considerations 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] ---------------------------------------------------------- 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] ---------------------------------------------------------- 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]
