CODEWITHSUNDEEP
.netentity-frameworkrefactoringef-code-first
Artur Udod
Artur Udod

Reputation: 4753

Refactor solution to use Entity Framework 4.3 (Code First)

I'd like to have some advices on the problem: We're having a solution that uses classic ADO.NET for data access (its like 4+ years old). The data-access architecture has been built back in times of .NET 2.0. Our data classes are simple classes that are inherited from, say, FooDataBaseObject (the name doesn't actually matter), which has a default implementation of CRUD operations. Our properties are marked with Custom Attributes ( holding necessary data, like the name of the respective column in the table and so on). And the same with data-classes (custom attribute is used to specify table-name etc).

The relations among entities are specified in special .xsd and .xml files. The tables themselves rarely have foreign keys and other typical constraints (we actually have this table inherited and customer has forbidden us to modify them, since they still use import and export engines on their side). But i am sure i will be able to persuade people to refactor the database.

The problem is with the existing services. Is there a way to introduce EF still having the possibility to use old ado.net services? i am currently considering the idea of using EF Code First approach, since i don't need my entities to be generated or inheriting some specific class, etc, rather then i will be able (i hope) to construct a DbContext for them and map to the existing database. Also, probably there is a way to create mirroring classes for our old data-classes. Say Customer -> CustomerEntity. CustomerEntity will mirror all the necessary properties of the Customer and then be used in DbContext and DbSet, so that we'll be using CustomerEntity in new services and just Customer in old.

I want to hear about the potential bottlenecks of this approaches and about the very possibility of this (is this actually real?) or maybe some other advices, etc. Thank you!

Upvotes: 0

Views: 264

Answers (1)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93444

You're going to have a lot of problems using EF if the tables don't have foreign key relationships. EF will typically depend on these relationships in order to create relationships in the code.

Of course, you can just treat them as individual tables -> individual objects and deal with all the keys manually.

It's unlikely you can map the classes to your old code without modifications, as your old code seems to rely on it's own helper methods, and ways of committing or rolling back data. Without knowing anything about your existing object model, it's hard to say.

What I would do is create an EF model, then start using it piece by piece as you upgrade your app. So long as your existing code deals with things in isolation, and there's not a lot of dependency throughout the code.

Upvotes: 1

Related Questions