- Is this a benefit of Code First?
No exactly. The benefits of Code First seem to be that the persistent data model is generated "on the fly" according with the application data (code-first) model premises.
Consider the db data model to be the physical model and the application data model the logical model. Both are not necessarily the same.
However, this is what Code-first EF does for you. It models the persistence via convention over "code". The persistent model is described by the domain data model Itself, rather than implemented aside. So essentially there's only one model in your code base. The domain data model.
Code-first follows its own conventions. Mainly based on the names of the classes, methods, etc...
- Is it an anti pattern to put domain logic in a code first EF entity?
No. Just the opposite. Code-first EF encourage you to focus on the logic rather than on the persistence. However, It doesn't not say you how to do it. You might end up modelling POCOS anyways. You still need to be familiar with DDD and its premises.
- Is it an anti pattern to put domain logic in a database first EF entity?
Not necessarily, but it's unlikely to happen. Database-first models are prone to be row mappers (POCOS, DTO, whatever). However, if you found the way to make your code-first entities "smart", you should be able to do the same with database-first. Ultimatelly, the model doesn't depends on the tools we use. Or It should not.
The difference between CF and DBF is that DBF force you to map and implement the persistent model, while CF does it "magically on the fly" for you.
One less abstraction to be worried about.