Ok. I'm migrating to EFCore from our very outdated ways of linq to sql with sqlmetal and manual dbml modifications.

I'm reading that EFCore represents a repository and as such doesn't need interfaces for your db objects. So instead of passing around interfaces and automapping them to db objects and saving them I can just pass around the object itself and save it. Cool, except in viewmodels typically you decorate members with your form requirements for validation.

How do you do this without inheriting an interface in the vm and decorating the vm? Is automapper and a new class that you manually write the only way to do this?

If you decorate the database class itself that works but you'll proliferate your requirements throughout your web but sometimes I don't want to do that. In one viewmodel I might want to force a user to input a value but not in another, even though they use the same database object.

Am I doing this way wrong? Do I still need interfaces? I have read that EF doesn't work well with them, but I want to make sure my validation requirements are in the viewmodel so I don't have to manually set "data-val="true"" and all that in the client and then manually validate again on the server instead of using modelstate.

Sorry if these are stupid questions, I swear I've tried to research this as much as possible but it seems that every heavily upvoted response on SO is conflicting with each other and it just doesn't seem like there's a standard that most follow.

It would be awesome if there were a project out there on GH or wherever that I could use as a reference, the "golden project" where they do everything correctly and by the book.

I know some rules are subjective to preference and there are 10 million ways to do any one thing (which is good) but it's a bit overwhelming and I don't want to dig myself into a hole on a big project by setting up the foundation of said project incorrectly.