Historically, as we all know, it as ado.net, entity framework, and mvc. EF attempts to solve the impedance mismatch between the data and the statically typed language. MVC attempts to solve the impedance mismatch there also, when not used with EF, in addition to providing a layer for solving the impedance mismatch to the UI. In that sense, then, MVC is (partly) yet another ORM, as I see it.

Hank

>Hi,
>
>I understand the MVC / MVVM stuff (and EF). It was just the "MVC (and the Entity Framework before it)" phrase that didn't make sense to me......
>
>>It's probably easiest to see if you look at MVC applied to WPF, where it becomes MVVM. http://www.orbifold.net/default/?p=550 As Brad Abrams points out, http://blogs.msdn.com/brada/archive/2008/01/29/asp-net-mvc-example-application-over-northwind-with-the-entity-framework.aspx, the Model can be from the Entity Framework (or any other ORM-type). MVC as I see it is a workaround for the fact that there is no metadata repository for data or UI, and so classes that store and test the action of the metadata need to be created.
>>
>>Hank
>>
>>>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
>>>>>
>>>>>
>>>>>.