Can you clarify what you perceive as the connection between the MVC pattern and the EntityFramework?
Ta,
Viv

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