CODEWITHSUNDEEP
asp.net-mvcentity-framework-4
Ciel
Ciel

Reputation: 17782

Entity Framework, Updating

I'm having a great deal of trouble with the Entity Framework (4.0) due to the pattern of 'adding' to a program. (Using ASP.NET MVC)

The problem is that it feels like the entire structure of the Entity Framework is designed to 'build everything all at once'. It doesn't seem to lend itself to progressive development, because of all of the changes that go through with the tools. I.E if I go change my database, then it fubars up the models - and trying to do updates causes all kinds of havoc and chaos. This wouldn't be bad if all I had to do was re-drag everything and my models worked verbatim, but I have to make manual edits to fine tune things ...and it is getting repetitive, and error-prone.

Does anyone know of any better tools or methods for this kind of problem?

Upvotes: 1

Views: 243

Answers (2)

heisenberg
heisenberg

Reputation: 9759

Ok, take two. It sounds like instead of using the designer you would be better off going the code-first route and making use of data annotations.

Data Annotations: Link -- Check out the storeNameAttribute for the specific case you mentioned in the comment to my deleted answer

Good code-first writeup here: http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

I'm just starting to dig into this myself but I've got some small samples up and running so if you have specific questions let me know and I'll try to answer.

Upvotes: 2

John Farrell
John Farrell

Reputation: 24754

What did you do before? Did you refactor the database and NOT have to change code?

So far I've used everything from ADO.NET to 3 .NET ORMs ( Nhibernate, Linq2Sql, and Entity Framework ), dabbled in Django and Python, and now hobbying in Ruby on Rails. None of these tools completly solved the problem of the impedance mismatch between the database and the code.

Someplace somewhere this code has to exist:

DBCOLUMN => CODE //or
myModel.Property = rdr["something"]  //or
<Property Name="EndDate" Type="datetime" /> //or
Id(x => x.Id);

Whether its in a Rails View, Migration file, Linq2Sql designer, or Fluent Nhibernate file doesn't matter. It always going to be an issue.

My suggestion is to try and make the mismatch as small as possible. Don't rename badly named columns in the designer and take every step to make the conventions between your database and code the same.

The other answerer provided tools that simply change where the renames occur but in reality you're always going to have to do this sort of work.

Upvotes: 0

Related Questions