Why should I use Entity Framework codefirst if it can't be used in production safely and things like indexes can't be described

Question

I'm just starting out an extremely large web project, and really trying to do everything right.

My tools using so far are

• ASP.NET MVC 3
• Entity Framework 4.3
• Ninject 3

All is going well, but I'm finding a few things with Entity Framework CodeFirst a bit sketchy.

For example, I had to use http://codefirstmembership.codeplex.com/ to setup membership information as part of the code first setup. This feels a bit ropey to have to use something third party of this. Obviously I should be 1337 enough to "roll my own" but I don't want to bite off too much from the get go. Running aspnet_regsql feels horrible, and will get lost with each db update. Anyway, got it all working with the above library and it's not too bad. Scaffolding seems to have broken however.

Now beyond all this, it now seems that this stuff is going to become probamatic when I am running in the live environment. Any schema changes I'm going to want to make between the dev db and live db will have to be manually managed with scripts anyway, so at that point am I not losing the point of code first?

I've been working with Google App Engine for the last year, and was hoping that code first would essentially work in the same way? Ie, make changes and they modify the live data. Now I assume, due to not having done severe refactoring in app engine, that it basically doesn't harm anything in production. So you could never rename a table with AppEngine. It would always create a new table, and leave the old one. You would have to manually port data.

So I'm now thinking. Why not just go Database first? I've been working with linq2sql for 3 years and very comfortable with going db first. Although TBH my db source control stratergy has been a little....lacking. So I was hoping code first would enforce that situation to improve, but it actually makes me feel that I should go DB first, and just be strict about keeping it under control.

I would really appreciate any thoughts on this kind of situation, and also, how does this compare to using Nhibinate?

Answer 1

The upgrade scenario's you're describing are being added in EF-Migrations. The go-live release of this is already available and it should become available as a officially supported release version soon.

Check out: https://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx?Redirected=true

Check out: http://coding.abel.nu/tag/ef-migrations/

Answer 2

Just my take on this...

You don't need to make a choice for good -

you can use Seed, custom initializer (and migrations hand in hand - with migrations you can actually manually change them, e.g. add indexes there etc. - though carefully), to 'inject' the raw SQL (and most of the needs could be covered by that). As far as I know you could run a custom batch file form initializer (but haven't tried, though I don't see why not). Migrations are done through PS so I'm guessing there is space to integrate on that side too.

You can use it to prototype things and startup - get your C# structure in place and in sync fast - then shape it up later - or once fixed use some 'use existing initializer' which does nothing from the code and move everything to Db side and your DBA.

IMO, you can go 'very far' in this sense, before actually needing to turn CF off and just work from Db.

For larger databases, or corporate environments, it's definitely not the right tool for the job.

I think it's now safe for production - but depends on what you consider safe, few things...

Also, EF/CF has gone a long way since the beginnings really - I used it since the start - and it had big problems initially. The latest versions are now pretty solid on all sides, so it's getting there I think.

...on the downside - I had worked out some pretty complex scenarios with code first approach (EF and otherwise). However, few things held me back with EF (on top of what you mentioned)...

UDF support, views (with linq - as if you're not to use LINQ one of the big 'pros' is gone) - which should come up in EF 5.0 (I did not check but it's what they're promissing) - as for more complex scenarios you need to optimize on the SQL side (or to be able to execute custom queries on the back and then map back, i.e. more flexibility on that side). So that's a promising thing if it comes (though won't be perfect I expect). (on the plus side, you can actually run custom queries and then map to your objects - but that sort of works, and you cannot do everything so it's limited in a way)

Performance with queries and again for more demanding heavy duty scenarios - that was my main problem with it. That's also promised to come up better in EF 5.0 - so to wait and see.

Having said that -
my favorite is a custom or open source code first like solution, ORM - where you can have more things under control. Still having many providers support etc. is what makes 'official' or MS implementations more viable on a long run.

hope this helps any