would you separate Domain Classes with Models and ViewModels in an asp mvc EFCF approach?

Depends on the complexity of the solution. If it's a basic CRUD model and you can get away using the same models for both domain and data repository then go for it.

But if you're building a complex enterprise application and you'd be breaching too many SOLID principles then it's best you have separate models for domain and your data model. You can map your data objects to domain objects.

@LynxMagnus yeah the project is in the beginning and yes it will become quite complex, but what about mappings? I've heard already about automapper -but it might be better to manually map the properties do you have any bad experience with automapper?

@muli353 I've used automapper before and not had any bad experiences. You can create your own mapper but if there's already a tried and tested solution that does what you need then no need to reinvent the wheel.

I guess it's a judgement call, there are times I've separated my objects into domain and data when there wasn't really significant enough differences between my ideal data model and my ideal domain model. That just resulted in a lot of duplicated code and complexity that probably wasn't really necessary.

On the flip side there was also a time I used the same classes for both and because the objects were essentially a RDBMS schema, I couldn't use the objects as easily as I'd like to and it made enhancing the solution more complicated as there were several beaches of SOLID principles.

So there isn't a right answer, it's just what you think is right for the project.

@muli353 I fully agree with @LynxMagnus it depends greatly on the project, i like to keep (sometimes) several layers of models for data validation and persistent mappings, and about automapper I've used and so far no issues it's easy to configure which makes it a cool option to avoid investing time doing custom mappers