3

Let's say you have a database that is currently in use. It has one table that contains some information about Customers.

And let's say that you want to create an application around it. You need to use the Customers table in your program, but you also need to add some new tables, possibly connected to the Customers. For example, you need to add an Orders table that has some association to the Customers table.

I have started to learn Entity Framework. I have learned a bit about "Database-First" and "Model-First" data models. But the situation is, what I want to do doesn't fit into any of these categories. I neither have a completely empty database, nor a finished database schema that can directly be used in the program.

What should I do? If I go with "Model-First" and design my entities using the Visual Studio Designer, can I just use it to create the relevant part of the database schema?

hattenn
  • 4,371
  • 9
  • 41
  • 80

2 Answers2

2

Go with Data-first, THEN go with Model-first. You don't have to pick... use the data-first wizard to generate EF for your existing table, then use the designers to create additional objects, then sync that back to your database. The concepts of model-first and data-first only applies to the initial creating of your EF stuff - anything you do after that can by synced in either direction.

This shows how to put database changes back into your model after it's created - you can do the other way too, but I can't find that article - all the new videos and crap are hard to navigate - you may be able to find it.

http://msdn.microsoft.com/en-us/data/jj206878

After all, the framework wouldn't be very useful if it locked you into never being able to update anything. Right?

Jasmine
  • 4,003
  • 2
  • 29
  • 39
0

The more development into your project, the more Database-First it'll become, so I suggest you to go with Database-First right now and then extent your EF entities and then implement/fake/mock the missing pieces

If you haven't read about TDD, it's time to do so now. It'll save a ton of time down the road especially when working with an ever changing data model.

Ray Cheng
  • 12,230
  • 14
  • 74
  • 137
  • Why the suggestion of TDD? It has absolutely zero relationship to this? – Jasmine Apr 22 '13 at 20:03
  • @Jasmine, I think it'll benefit OP. – Ray Cheng Apr 22 '13 at 20:33
  • TDD isn't always good. I was trying to figure out if you thought it had some specific bearing on working with EF, or if you just are generally in love with it. Don't fall into the trap of thinking something is always helpful. I don't see the benefit of TDD here, unless the OP is running out of things to do. – Jasmine Apr 22 '13 at 21:22