Hi Kev,
I do something a little like I *think* you are describing. I create data broker classes for passing data to/from the presentation layer to SQL Server. I have a defined object that I add to the container, be it a single form, pages of a page frame, etc. When a particular container instantiates or gets focus, I set the form level oDataBroker object variable to the one on the container. I do this because I use a variant of the Codebook framework and then all the Save, Edit, etc work on the active container, but the principle is the same without using Codebook. After I started seeing a common pattern for all my forms, I threw together a code generator that I use to create the class. Basically, I drag fields on to the container from a remote view, select everything and call the class generator. It creates almost everything I need to pass data back and forth to the back end, removing the controlsource from the field in the process since I’m using SPT exclusively for the moment. Also, this class can be compiled as a COM object and be completely separated from the presentation layer. I've done this for C++ and VB front ends as well as browser based forms.

Gary


>Hi
>
>I have a large, complex app, and I want to start breaking the code up a bit into a more 3-tier style.
>
>One of my first objectives it to extract any data-handling from the GUI into custom objects, the only thing that is getting me is where to plonk these data-objects.
>
>For example, most of the forms have buttons down the left hand-side that each call up a different container that contains the screen fields.
>
>Each container may relate to a different data-object, so where should I house these data-objects? and what would be the best way to ensure that the form is accessing the right object for the container that is currently displayed?
>
>Thanks
>Kev