[AccessD] .NET Form Object Frameworks -- WAS: Data interface The best way

>I see now VBA/VB6-programming concept I called "DEEP-object concept"
>(http://www.smsconsulting.spb.ru/shamil_s/articles/deepcnpt.htm) 

Shamil, 

Colby turned me on to your site some years ago. All I can say is that
you were way ahead of the curve -- it even took MS 3 years to come up
with a stable platform to run your concept. 

I too have dabbled with my own form management frameworks for Access. I
got two running, the first a modestly complex, class-based framework
that relied on sinking events (developed independently), and the second
a stripped down, much-simplified framework based on interfaces. The
interface framework managed not only Access forms, but Excel Userforms
and standalone objects, as well.

The shift in thinking was from a reactive style (respond to an event
from something that already happened) to an active style (tell some
object to do something with this information). 

One aim of the interface-based framework was to produce a more
loosely-coupled system by moving parameters directly to the object,
eliminating the reliance on any global objects (external form controls,
global variables, functions and collections...). The other goal was to
move away from the flakey form event system, and instead build framework
"events" (in reality interface callbacks) on the much more reliable
mechanism of object termination.

I have thought of building a third framework that combined the best
ideas of the first two, but have run into these problems:
* Access Form objects have no parameterized constructor (a true
Initialize event with a user-definable parameter list). Form_Open
happens way too late for my purposes. (Maybe Access 2005 will correct
this)
* No easy way to deliver the framework. COM-based approaches would
require Active-X dlls, developed in VB6. 

.NET seems to provide some answers:
* VB.NET, C# and similar have the object sophistication to build a
technically satisfying framework.
* Packaging and installation appear to be simpler and more robust
(although I can't say this firsthand) 

Some interesting thoughts on what such a framework should and shouldn't
have: 
* Based in .NET
* Works with Access via COM Interop to an Office Add-In.
* Automates other form types, including Userforms and .NET forms.
* Form Roles defined by the Interfaces they support.
* Extensible by defining new Form Role Interfaces, and providing the
support code to implement them.
* Not driven by Form events. The form communicates to other forms in the
framework via interfaces. Form events are considered private to the
form, in that they don't drive inter-form communication. The form can
use helper objects that sink form events and perform various services,
including communication via the proper channels. These would be
explicitly set up in the form.

Of course, the larger question is, "why do this?". Maybe Microsoft will
revive enough developer interest in its next release of Access to
justify investing in such a framework. 

-Ken