>
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.
>

Better late than never!! < bg > :)



>
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.
>

A middle tier approach is the way to go. However, you will want to incorporate multiple components in the middle tier - hence n-tier...

In most cases, the following will sufice:

One tier that encapsulates your business rules.

One tier that encapsulates the CRUD operations (Create, Update, and Delete operations).

The business rule tier is the broker that determines whether you get to the CRUD tier. Sometimes, the CRUD tier is considered the third/data services tier. It is a matter of opinion as to the name. The key is what it does.

>
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.
>

Surfacing redundant properties does not scale. And, the story gets worse if you start using access/assign or Let/Set methods. Performance really starts to crawl.

The field collection of an ADO Recordset and the Parameters Collection of an ADO Command object are good enough. The key is to provide a wrapper around the varioius ADO objects - but still provide access to the respective Field and Parameter objects.

As you might guess, DataClas COM from RedMatrix Technologies does this already -and does it quite well. The approach also uses Stored Procedures as a method of interfacing with SQL Server. Instead of re-hashing all of the benefits here, go to www.redmatrix.com and download the PDF Docs.

And of course, please email me privately if you have any ?'s. There are a lot of ways to get off on the bad foot when you stray into this arena. The road is riddled with failed approaches. DataClas I am happy to say works, and works very well.


>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.
>

A disconnected RS is definitely the way to go. However, it is important to note that a RS should only be used for 1 thing - displaying and passing data around. When it comes to updating/creating data, etc - that is where the ADO Command objects and stored procs come into play. Again, the DataClas COM handles these issues and provides a great framework for this sort of work.

Again, please feel free to email me if you have any ?'s.

Best regards,

< JVP >