Does Entity Framework DB First (EDMX) prevent proper Separation of Concerns?
===

I am new to entity framework and MVC, and trying to understand what constitutes a good design approach for a new application.

There are several ways of using Entity Framework. However, for my project, the best looking option is DB First. I've played around with an EDMX file, and I have got as far as using the DbContext code generator to create my wrapper classes.

I plan on using the repository and unit-of-work patterns, and using ninject for DI.

However, it does not seem "proper", from a SoC point of view, that whilst my respository will hide the implementation of the data store (EF) from my code, the model classes themselves are very much EF flavoured.

It seems that using EDMX-based approaches to EF blur the separation of concerns. Only POCO support seems to allow a true separation, but POCO has some other limitations that I don't like.

Am I missing something, or does using EDMX have this drawback?

Are people using an auto mapper to convert between the entity model and another, clean, SoCced model?

thanks

Tian