Hi Matt,

As I see it, MVC (and the Entity Framework before it), are elegant ORM answers to the problem of working in a system where there is a mismatch between what the controls expect as a datasource, and what the native providers of data in the system can provide; and in which metadata is not assumed (because it isn't) to be available.

In VFP, of course, there is no mismatch between datasources and controls: you just wire them up. No need do describe the type of a field: it's all done for you. The same is true in the eTecnologia effort for (my name) VFP.Net.

The other part, the Data metadata and the UI metadata, is something we have been using for 7 years as our extensions to the framework we use in VFP. I couldn't imagine software development without it (e.g., dynamically setting when a control should be visible, or be enabled, etc., in metadata rather than in code; setting field triggers in metadata rather than in code; etc).

We'll have the same metadata available in VFP.Net, but reworked based on our experience, and also on new features available in VFP.Net.

These ORM solutions shove all of the above into one place. Since most of it is itself data (i.e., metadata), that place should be a table, not a bunch of code. Of course, I look at things as a data guy, but isn't that what we are?

Hank

>Model < --- > ViewModel < -- > View
>
>It's great theory, but come on!
>
>Just say No Way!!
>
>http://therealmattslay.blogspot.com/2009/11/model-view-model-view-no-way-for-now.html
>
>
>.