Question

After deploying a complete application using Entity Framework (EF) and LINQ, the next things can happen then with the data in a “database which previously was included/mapped to EF in the aplication”:

1. Create new tables and include into EF
2. Delete existing tables from the database that were previously included in EF
3. Include new fields to tables and include in EF also.
4. Delete fields from existing tables which were previously included in EF
5. Modify a field from the database (new type or length) and apply the changes in EF.

The question is: can all these changes be easily/automatically modified in the application that uses EF?

Answer 1

The modifications you describe and easily be accommodated for or consumed by the EF designer. Go ahead and make the changes in your database. Once that’s finished, you can simply right click on the EF designer surface and choose to refresh your EF model from database.

The more difficult part will be re-aligning your business logic to conform to the new data model. Those entities/tables and properties/attributes that were deleted/changed will be highlighted in Visual Studio, and you’ll have to visit each of those lines of code to correct them. This could be in your DAL/Repository, and up into any assemblies that reference your EF model.

For those new tables/entities and attributes or datatypes, you can simply incorporate and start using them right away in your code.

To get a feel for how this will work, try changing one thing (deleting an entity/table or changing datatype), and go though the steps I’ve described. Depending on your tolerance for multiple changes, consider taking a longer amount of time to manage the datamodel changes one-by-one.

Does EF have mechanisms or “best practices” that let us align the BL with the new model?

I’m not sure I understand your intent of ‘align the BL with the new model’. There aren’t any automated ways to ‘fix the code to accommodate the entities new look’. You’ll simply see compiler errors.

If you’re asking about how to protect against DB changes, I’d say that this is an architecture decision that you make in the application, and there aren’t any BP. Given that EF is an ORM, some devs would suggest using/consuming the entities that EF creates for you. Some devs suggest using them, and create partial class to extend their behavior (new methods or properties separate from the database). Some devs want to create a whole new set of classes and object model to represent or make the classes look more like the real-world, rather than how a database wants to structure the data model. They then go on to create mapping code between the EF entities and their own POCO classes — translating between each version.

My suggestion on this is: use the ORM’s classes for your tables/entities, and extend their behavior and data with partials if/when needed.