>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.

That's only true if you bind your UI controls directly to the cursor that has the data. I have just spent many hours converting my VFP app to use Business Objects (which have flexible back end service and an Entity property which hosts the properties from the data row). So now my UI controls bind to the data Entity on the BO. You can also have other "presentation properties" that you mock up on the BO that can also be displayed in the UI. This can provide virtual data fields that don't really exist on the data row but they do exist on the BO.Entity.


When you design your VFP app in this OO manner, it's not really a VFP vs. EF issue, its becomes a more generic "object model of a data row" issue, which spans both platforms.



>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
>>
>>
>>.