>I, unfortunately, have only recently been able to start working with client/server applications. This same holds true for another developer that is working on a project with me.
I am also working on my first client/server project.
>What we would like to do is create a COM/ActiveX module (whichever is the correct terminology), that would be responsible for enforcing the business rules and interfacing with the back-end. My hope is that as we become more proficient in multi-tier apps, this will get us one step closer when we decide to truly go multi-tiered and setup an application server.
I think the latest terminology from MS is COM Server.
>Right now, I am playing with an object(component?) that just handles user-maintenance. This object will have methods exposed to handle Adding, editing, deleting, and retrieving user information. Right now, I am exposing the 1:1 data elements (User name, employee badge id#, first name , last name, etc) as properties of the object which the GUI would manipulate and then issue the appropriate method (add, edit, delete, get, etc). By using the properties I am running procedures in the PROPERTY LET snippets to make sure that the data is formatted correctly (i.e. left-justified and upper-case). From here I am using a ADO recordset to write back to the DB. I have also seen this done by performing native SQL to the back-end.
I am using the Mere Mortal framework, which has helped me out a lot with the middle-tier. In the middle tier, the framework makes use of VFP remote views of server data (in my case, SQL Server). The author makes what IMO is a pretty good argument for using VFP remote views: VFP forms and thir controls (Grids, Textboxes, etc) work best with data in VFP format.
However, the middle-tier objects also can communicate with other clients (VB, ADO, etc) through ADO or XML. I like this solution because I can take advantage of VFP's strength if I am using a VFP front-end, and also provide data services to other clients.
>I also know that some people just pass a disconnected recordset back to the GUI for display and manipulation and then send the recordset back to be validated and written to the DB.
>
>I guess my question becomes:
>
>What are your opinions on using the object as I have described?
>
>I haven't formed a opinion on way or the other yet. I would really be interested in knowing what other people are doing.
>
>Thank-you for your time.
>Dave
Chris McCandless
Red Sky Software