>What I have found especially useful has been VFP's ability to store >functional class definitions in local metadata and instantiate them on the >fly when needed. >Andy Kramek
as I have commented before on this list I usually find myself in complete agreement with Andy Kramek but always with one exception <g>. I am currently working (struggling) on a design for a system based at least in part on storing class definitions as metadata - but *remotely*! This is what prompted my earlier question about n-tier design <http://leafe.com/archives/showMsg/327549> My concerns/ questions include what an object could/should know about other objects and hence in what order they should be instantiated. >From replies here and some googling it seems the consensus is either to use the form as the starting point (then bObj then dObj) or to use main.prg as the starting point (then bObj, dObj, menu(s) and form(s) 'in parallel' and aware of each others existence). Both approaches treat form controls as essentially dumb/ data-unaware objects (apart from data binding*) and both rely on 'do case' logic to potentially handle multiple back-end databases. It seems to me that this leaves the_programmer (the last of my 'pegs') as a sort of invisible component that alone knows what the backend actually is and what the *binding has to be between form controls and database fields. Most suggested architectures also ignore the de (data environment), usually on the grounds that it can't be sub-classed, well it can now - so I decided to consider it as a candidate 'peg', possibly even for the bObj hole. I decided that a robust n-tier design is not going to use fox tables for [most of] its data storage, and having been convinced that cursoradapters are just a more flexible version of my favourite remote views <s>, and having recently seen a foxpro based/ derived system that stores everything on the backend (think vcx scx mnx frx as backend tables) I decided to explore the concept of remote metadata. This means that the_programmer is still the repository of data and object relational information but can encapsulate it in one place. It also makes it slightly more 'politically' acceptable to also consider using the functionality and undoubted rigour of the rdbms for referential integrity and security e.g. by the use of sp's and triggers. I'm still swimming upstream on this, but if I get anywhere I'll let you know <vbg>. Andrew Davies MBCS CITP - AndyD 8-)# ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. Please contact [EMAIL PROTECTED] with any queries. ********************************************************************** _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
