I want various objects to inherit from an object named “Device”, since they will all have some common properties (i.e. IP address, MAC address, etc.).
You are essentially talking about which inheritance pattern you intend to use in EF; or how the model maps to database tables. There are 3 main types of inheritance patterns in EF (see Inheritance: Walkthrough for beginners ):
- table on hierarchy
- table per type
- Type of table for concrete
Each has its own pros and cons (for example, performance). But you should also consider that this model is a model that refers to the database, and in larger projects you can create a second level for working with business logic. DDD talks about persistence models and domain models . Again, your choice here weighs the initial development speed, scalability and future performance.
I like to create objects using the constructor (Model First), but I don’t like the difficulty of updating the database from the model.
There are 4 and only 4 development strategies for EF (see Entity Framework Development Workflows ):
I don’t like to drop the database and recreate it, especially after I start filling the database
Code First is really very, very good at this:
- A visit to the code First allows you to populate the database with test or live data, depending on where you are.
- Migrations enable non-destructive database updates and data transfer into a fully verifiable, completely reliable way for active deployment.
Doing this with the First model is unfortunately more complicated. The only real solution I know is to create a new database and use the SQL comparison tool (with data mapping) to generate data in the new database.
Template and strategy selection
Each strategy has its pros and cons, and each inheritance scheme is better used with specific development strategies. The compromises are really your own, to judge, for example, you might have to use a database - first, if you have an existing database that you have inherited, or you can be happier with the EF designer, so use the model first.
The first model (by which I mean using the EF designer to define your model) uses the TPT strategy by default. See Inheritance EF Designer TPT . If you want TPH, you can use Model-first (see EF Designer TPH Inheritance ), but you have additional work; First code is better for TPH. TPC is even harder to use the First model, and Code First is really the best (only viable) option for EF 5.
when I create POCOs from the database, the objects do not inherit from each other
It is good to remember that the model belongs to classes; the database deals with storage in tables. When creating a model from your EF database, it is difficult to determine what the inheritance of TPH or TPC should be. All he can do is create the “best guess” in your model based on table associations. You should help him after creating the model by renaming properties, changing associations, or applying inheritance. There is no other way to do this. Therefore, database updates may require more work with the model.
Your best approach
This, unfortunately, is up to the opinion. However, if your basic requirements:
- Do you want TPH or TPC (or mixed strategies)
- You do not want to drop your database when releasing updates for the model
then the best fit for these specifications is Code First development with migrations and sowing.
The downside of Code First is the need to write your own POCOs and learn the attributes of data annotation . However, keep in mind:
- Writing POCOs is not much different than writing a database table (and once you get used to it just as quickly)
- Code First is much more convenient for automated testing (for example, using DI and / or IoC for testing without a database), so it can have advantages later
- If you first do a lot of manipulation of the EDMX database, or work a lot when you first drop and update your database using the model, then you just invest time and effort in other places, and not in POCO writing which