Hi Gar..

Is the issue a data driven application or some elements and functionality that are data driven?

I would like to address both issues if I may...


First, with respect to data-driven applications. Typically,these beasts are data-driven at runtime. Given the overhead involved, I have to ask what is the real return. Of course, when I say overhead, I am talking in terms of cost and processing time.

When I hear about data-driven solutions, invariably, it ends up being a situation where the developer thinks that what he has done is super cool. Look at what I did!!! Typically, it ends up being what is normally a 200 dollar problem being solved with a 2000 solution. I am OK with this sort of thing if the additional $1800 investment is going to have a payback. Me as a developer thinking it is cool is not an economically justifiable argument.

Canned soltuions like Steve Black's INTL toolkit, and its use of a data-dictionary make sense since that is central to the problem being solved. Data-
Of course, I would still advocate compile time solutions as opposed to run-time solutions. Purely a preference on my part.

Driving for the sake of data driving is a poor excuse for the extra-overhead.

With respect to data-driving pieces of an application, that is often where it is needed since the data-driven aspect is central to solving the problem. If you think of things in this regard, the problem gets simpler to solve.

Therefore, if you have a class/component that has functionality that needs to be data-driven, build the logic there. Once you are at that level, whether the you are building a single tier or an n-tier app, it really does not matter. Your frame of reference is a module - and that concept applies in either case. How you physically deploy your app is not germane to the issue.

Synopsis:

Don't get hung up on data-driving your app. Look at specific functionality and data-drive that within the class boundary if need be.

< JVP >





With respect to





>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