I am writing a small (and I emphasize small) data driven application.

Basically it consists mainly of a data dictionary -- You call a certain master record -- it links to child records which tell the program which views to open in which orders and where to send output to. (There is a little more than that going on -- but not much, handled with code hooks.) It is basically a data validation application, comparing inputs to outputs, making sure certain summary calculation equal one another -- just making sure nothing has gone wrong with the program.

To be on the safe size for later upsizing (or side sizing) we have made sure the app is indifferent to whether the views are remote or local (using the trick Kevin's MMortals taught of name the views "lv_*" or "rv_*" and the discarding the first character. We are also setting up to handle standard cursors, SPT cursors, and actual VFP tables if need be.


It works fine (so far -- not yet complete), and I really should not worry, but I am wondering how to fit this into the N Tier model. I mean it seems like a buisness object in this case would just know the location of the data dictionary and the master to record to pass it -- which would make it kind of a dummy business object, without much point.

I know that for a more complex application this kind of run time dictionary tends to be slow, and can actually be tougher to maintain than a business object based application.

Because the application is special purpose, and simple this seems a fairly safe thing to do.

But it is one small module in a much larger application. The larger application will use the business object model. Is there a way in which using a data driven module in an application mostly based on a larger N-tier type scheme could cause problems for us?

Thanks

Gar