Access and the "Middle Tier"

[Jordan S.]

Can I have a logical "middle tier" that somehow participates in binding of
UI widgets (forms and combo boxes, etc) - or does binding UI controls
necessarily preempt having a logical middle tier that abstracts the
underlying database.

Same question put another way (to make clear my intentions): If I want to
bind my UI widgets (forms, combo boxes, etc) and NOT programmatically load
them, do I have to bind directly to tables or queries (and therefore cannot
really have a business objects layer)?

I would like to be able to programmatically load up classes in a "business
objects" layer and then bind my UI controls to those objects.

Thanks!

 

[Brendan Reynolds]

In recent versions of Access, forms (and reports) can be bound to DAO or ADO
Recordsets, but that's as close as it gets with bound forms. You can not
bind directly to your own classes as in .NET, no.

 

[Tony Toews]

Can I have a logical "middle tier" that somehow participates in binding of
UI widgets (forms and combo boxes, etc) - or does binding UI controls
necessarily preempt having a logical middle tier that abstracts the
underlying database.

Same question put another way (to make clear my intentions): If I want to
bind my UI widgets (forms, combo boxes, etc) and NOT programmatically load
them, do I have to bind directly to tables or queries (and therefore cannot
really have a business objects layer)?

I would like to be able to programmatically load up classes in a "business
objects" layer and then bind my UI controls to those objects.

Such does not exist in Access although I would very much like
something in place to handle business logic modeling such as middle
tiers do.

One thing I did in one situation where I had some exceedingly complex
logic behind a continuous subform and a corresponding detail form was
to have function calls in the BeforeUpdate event passing in the form
as an object. If the function failed then I passed a cancel back so
the cursor was kept positioned in that field.

I also ensure that all control names on both of the forms were
identical. So now if I needed to validate fields against other fields
I would do this in the functions but using the form object passed into
the function.

So this kept the business layer logic separate from the form.
Clearly this is a bit more work and certainly not intuitive. <smile>

One thing to remember though is that most times there is only one
form, be it a main form or a continuous subform which updates one
table. There are quite often other forms which only update a few
values or are used as inquiry type forms.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm