Entity Framework Code First convention over configuration should be the other way around [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

Why has MS decided to use convention over configuration.

I deal with very large projects and not all projects are data centric. In fact, even with data centric projects, my entity classes have a lot of custom functionality that needs to be persistence agnostic.

With the current MSM approach, I end up having to apply attributes to non-persistence properties instead of the other way around. Shouldn't that be the point of code-first? To use a working class hierarchy and turn it into persistence compatible as an 'addition'?

I understand that some conventions are very useful such as the naming of Identity or primary key properties and foreign keys. But honestly, tell me how many developers would use code-first instead of model-first if they did NOT already have a class structure???

Answer 1

You don't need to use any persistence dependent attributes in your classes. EF code first uses model configuration to define mapping - that configuration is either defined directly in OnModelCreating method of your derived DbContext or in separate configuration classes per every your entity and complex type. Attributes are just shortcuts converted to these configurations.

Answer 2

If you are creating appropriate abstractions then this should not be a problem IMO. It sounds like you are mixing business entities and logic with data entities. If you follow the repository pattern and abstract the persistence entities, then most of your POCOs should follow convention. I would suggest re-evaluating your architecture as it sounds very coupled to the persistence layer. If you create a more loosely coupled architecture, then these conventions should make sense to you. Just my two cents, though

Answer 3

I've worked quite a bit applying code first to pre-existing business objects to create a persistence-ignorant architecture. There's more than one way to apply EF in this context - I agree that dressing up your business objects with attributes is less than ideal. What we've done in the past is

1. Define an interface stored in the BLL assembly that is implemented by the DAL. This is used by upper layers for CRUD operations
2. In the DAL, map business objects using EntityTypeConfiguration(of T)

It's worked pretty well for us, and decouples the upper layers from the DAL pretty nicely