3

Since MSFT has officially abandoned Model First and Database First, does anyone have alternative suggestions for this functionality? One I am considering is DevArt Entity Developer. Can anyone else suggest any other alternatives I should consider?

A while back before MSFT announced dropping Database First, I was considering using Sparx EA to maintain the database, then use EF Database First to update the model from the database, but they refuse to acknowledge any need to now generate Code First from their design model even though Database First is no longer supported by EF. EA will generate POCO classes, just not any CodeFirst variant, and I don't want to constantly update by hand.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
Dave
  • 1,822
  • 2
  • 27
  • 36
  • 1
    errr, since CodeFirst is essentially a `DbSet`, how are the POCO classes not "CodeFirst variant"? just take the classes they create, make a context and add a `DbSet` for each one, and away you go..... – Claies Mar 20 '15 at 19:41
  • 3
    Where exactly has MSFT dropped those alternatives? At least in VS 2013 you still can generate databases from models. – Mare Infinitus Mar 20 '15 at 20:34
  • @MareInfinitus Entity Framework 7: http://blogs.msdn.com/b/adonet/archive/2014/10/21/ef7-what-does-code-first-only-really-mean.aspx – Dai Mar 20 '15 at 22:56
  • 1
    You always will be able to "generate" entities from Database. The only thing they are removing is the "Designer" which will benefit everyone! – Michal Ciechan Mar 20 '15 at 23:32
  • @Claies - no decoration. – Dave Mar 21 '15 at 02:16
  • 1
    @Mare - announced for EF7. Code First only, though they allow you to generate that once from the database. Then you must stay with Code First. – Dave Mar 21 '15 at 02:19
  • @Michael - they let you generate Code First from the database but then you have a Code First model, not Database First. – Dave Mar 21 '15 at 02:21
  • 1
    I'm still trying to understand what the issue is here; If you have spent any time at all with Code First, you understand that the DbContext is no different than the DbContext created using Model First or Database First, and the Classes are simply POCO classes you create instead of using a designer that outputs XML and .TT files to generate the classes. If you have another tool that can generate POCO Classes, then there is no difference in functionality. – Claies Mar 21 '15 at 03:15
  • in fact, the article you posted says very specifically that the functionality will still exist: "In EF7 all models will be represented in code. There will be tooling to reverse engineer a model from an existing database (similar to what’s available in EF6.x). " That implies that there will be tooling similar to the "Database First" tools that exist now, which do exactly that, reverse engineer a model from the DB. – Claies Mar 21 '15 at 03:18
  • @Claies - Yes DbContext is the same, but you cannot keep updating the Code First model from the database once it is customized w/o losing customizations. And some of us like to see the visual model as well. No reason all 3 approaches could not have lived in harmony where you could use Code, Model and Database First in concert depending on what you wanted to do. Model for the visual, Code for the decoration, Database for pulling in views and other changes (views are a whole 'nother story). – Dave Mar 21 '15 at 12:31
  • Obviously we just have to agree to disagree here, because I have yet to ever have any issues loosing customizations on existing models, but our workflows must be different in some respect. – Claies Mar 21 '15 at 14:28
  • @Claies - sorry had to do work over research for a while so just picking this back up. Are you saying that having once reverse engineered your database to code first, you can decorate and customize the relationships, add new entities, properties etc. and then still update the code first model from the database again and not lose those customizations? That is a big part of what I'm after. I want a designer (like DevArt Entity Designer or Sparx Enterprise Architect) that can model and update the database then have the changes reflected into my code first model w/o losing other changes I made. – Dave Apr 28 '15 at 20:00

1 Answers1

2

As per your Link, they are not removing Database First design, Code-First is only a name that means your database is represented as a set of POCO C# objects, rather than XML + Designer.

They have REMVOED the designer and .edmx file. But you can still `Reverse Engineer your database to create entities.

From that link:

For Code First you can re-run the reverse engineer process and have it regenerate your model. This works fine in basic scenarios, but you have to be careful how you customize the model otherwise your changes will get reverted when the code is re-generated. There are some customizations that are difficult to apply without editing the scaffolded code.

Them removing the designer, and making EF Code-First only, does not mean you HAVE to create entities first in your c# then have them generate the database. All it means is that you database will be mapped via POCO's rather than .edmx.

And believe me, .edmx + designer is nothing but problems!!!!

If you are not going to be happy with the reverse-engineering results, or adding new tables/relationships via code, than I'm almost certain someone will create a fancy Drag+Drop Designer as a 3rd Party Add-on. But to me + most of devs i know, Designer is only for beginners, as soon as you start doing something or customizing it, you have much better, cleaner, easier to understand control in code via annotations + fluent mappings.

Michal Ciechan
  • 13,492
  • 11
  • 76
  • 118
  • @Michael, Yes, they have removed Database First. You can only do it once. To convert to a Code First model. And yes, I know it is nothing but problems. They should have fixed it so all three models round trip to each other and you could design in any of the three modes... – Dave Mar 21 '15 at 02:16
  • @Michael - Designer and database first only for beginners? Rather arrogant eh? Perhaps written by beginners but Model First and Database First should complement Code First and vice versa, not be dropped. – Dave Mar 21 '15 at 02:25
  • "This works fine in basic scenarios, but you have to be careful how you customize the model otherwise your changes will get reverted when the code is re-generated." - my point. Not that Model First and Database First did not have problems. But rather than fix them, they were dropped, forcing Code First where that was the worst choice when EF first came out and for quite a while. Clearly their effort went into Code First later on. The problem is when one makes that conversion, customizes, and then can no longer update the model from the database w/o losing customization and the visual model. – Dave Mar 21 '15 at 12:21
  • @Dave You will still be able to regenerate your models from the database, yes it may mean some custom merging or losing your changes. But believe me, merging a C# Class with another auto generated C# Claas that will be very similar is a lot easier than trying to merge an XML file (.edmx) I will put my money on that you will be able to "Update" your models from the database again, and if there are breaking changes, you can easily rename the entity, regenerate teh entity, and merge them. From my expeirence designer has caused nothing but problems. Especially in a team – Michal Ciechan Mar 21 '15 at 14:37
  • Im guessing you are the same type of person who complains that the WPF designer is not as useable as the WinForms designer? its the same scenario, if anyone is using t he WPF designer for anything other than to see what something looks like, you are either doing something very simple, or not doing it properly. – Michal Ciechan Mar 21 '15 at 14:43
  • @Michael - again with the arrogance? Buzz off - don't want your unrelated advice. You need to reread my question before commenting anymore. – Dave Mar 21 '15 at 18:15
  • @michael - I get that you can reverse engineer a database to code first. Do you get that you can only do that once and one would lose customizations if doing it again? Or that I actually want a designer to help maintain the model and relationships or to at least view them? – Dave Apr 28 '15 at 19:54
  • @Dave yeah I get your point,,, I guess its not my preffered way of working... as recently I have been using code migrations, and the designer is nothing but trouble on some of our projects at work (due to junior devs updating from db when someone is testing stuff and not realizing what they are committing :| ) – Michal Ciechan Apr 28 '15 at 20:56