<i><font color="#663300">Has anyone done an n-tier app in Codebook? I know that logically, Codebook is n-tier but is it possible to do a physical n-tier app with Codebook. Is it possible to have bizobjs as DLLs residing in a server and front-end in user workstations?
I know that COMCodebook is available for such a setup, but I feel more comfortable working with Codebook?
Any comments/suggestions?
jun</font></i>
Hi,
Iíve put in way more info than you are probably interested in, but here goes.
I've built several of these. I use most of the Codebook framework ěas isî but work around the bizobj portion. I donít use views, so I donít need much of the dataenv stuff. This could be done a variety of ways, but what I do at the simplest level is to create a data broker object that I attach to a form. The data broker object has the SQL pass through code in various methods to get data from the back end and save it. When a method gets data from the back end, I create data object a collection of ërecord objectsí to hold the data. This could be a custom class with a few fields as properties or an object created from SCATTER NAME. In some cases I might create data object collection hierarchies to feed a tree view for example. Basically, for a simple from I would have a few method types for the data broker object:
1. A method to get data from the back end using SQL pass through and compose it into some type of collection accessible to the form.
2. A method that decomposes a data object collection and uses sql pass through to update the back end.
3. A method that updates the formís ui from the data object collection.
4. A method that updates the collection from the ui values.
5. Various utility methods or objects that get a connection handle for the back end, etc.
Most of the rest of the codebook framework stays in place. For example, I just put code in the form.save() method that calls my object and returns the objectís result code. This type of object is really quite easy to put together and can be a regular vfp class or a com/dcom object. I suppose that in some ways, iím kind of reinventing ado/rdo type stuff, but this keeps everything in ěnativeî VFP and I prefer it that way. Another thing that I like is that even creating complex data collections is shockingly fast. It sounds a lot more complicated that just binding fields to remote views, but it's quite easy to do and the data handling and collection building is REALLY fast.
These data collection objects can be passed to any com/dcom client as well which I have done quite a bit of. This allows a middle tier VFP data layer to handle all the data manipulation for all front ends in a shop. This keeps the typical vb or web programmer from (usually poorly) replicating code and data structure information that breaks whenever a change occurs in the back end. hope this helps.
Gary Foster
©2002 Gary Foster |
