I didn't say I don't like EF. I do and use it a lot.
I *do* think that both the code-first and model-first approach to implementing an EF solution is not much more than a 'toy'.
Firstly, it will only *create* a database. Change the model and you wipe the existing DB entirely. And there is no guarantee that the database design is actually optimal.
On top of that it pre-supposes that you will only want one entity model.....



>In his book, "Patterns of Enterprise Application Architecture", Martin Fowler shows how data access techniques, such as SQL Dataset quickly breakdown and increase complexity as the application becomes more complex where a Domain approach, such as that used by EF, is much better suited for complex applications. The problem comes in when you try to determine where the ROI on the two methods intersect, thus making EF more cost effective.
>
>I'm not saying Code First is the best solution for all applications, nor that EF is right for everything. However, my experience is that most applications I've worked on tend to cross that intersect point, but if done with SQL Datasets, when you get to that point its too late to go back and change to EF, so I tend to use EF from the beginning.
>
>>I'm going to muddy the waters a bit more :-}
>>
>>Bill *may* be right in that a SQL Dataset approach is simple - but EF should give you a much better object orientated solution.
>>
>>OTOH I don't agree with Craig that 'code first' or even, come to that, 'model first' is a good way to implement EF - it's OK for simple, one-off type applications but the limitations soon become clear in real world scenarios......