- Is this a benefit of Code First?
More or less that is. The benefit of Code-First seem to be that the persistent data model is generated "on the fly" according with the application data model premises. So, one less model -and code- to maintain.
Consider the db data model to be the physical model and the domain data model the logical model. Both are not necessarily the same.
However, this is exactly what Code-first EF does for you. It removes the need of thinking in both models. The persistent model is described by the domain data model itself, rather than implemented. So essentially there's only one model in your code base. The domain data model.
Code-first follows its own conventions. Mainly based on configurations, the names of the classes, methods, etc...
Somewhat similar to convention over configuration.
- 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 forces 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.
Note: On both approaches, -CF and DBF- repositories should return domain entities. Following CF this's inmediate, following DBF take us to map the persistent model to the domain model (if any). The application layer doesn't need to know the shape of the data on the persistence layer.