Why should I use Entity Framework codefirst if it can't be used in production safely and things like indexes can't be described - 【StackMirror】|c#|database|asp.net-mvc|entity-framework|linq-to-sql

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?

2012-04-05 23:37
by Chris Barry

If you're not tied to a particular DB you might want to look at something like RavenDB - Derek Beattie 2012-04-08 20:50

I'm not really averse to using MSSQL, we should be able to migrate bits of it, so we can just scale using Standard Edition, which EC2 supports at a relatively decent rate. Probably would look to Mongo or Couch before Raven, any reason to go for Raven first - Chris Barry 2012-04-09 21:26

One thing to consider is what you are wanting out of code first. Are you really going for defining your tables in code and having that create the database, or is it the POCO aspect of EF 4.3 that you want? The reason I ask is that you could use POCOs and DbContext with Database First or Model First (you can create a custom T4 to gen the POCOs from your model). The reason I ask is because I sometimes see people writing about "code first", when the thing that they are really after working with POCO/DbContext - JMarsch 2012-04-13 16:30

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/

2012-04-07 18:56
by jessehouwing

Comment from that blo - Chris Barry 2012-04-08 19:59

Of cause the database have more objects than the Code First model; the model won't be able to describe everything SQL server has (indexes, statistics, columns order, object descriptions, computed columns, sprocs, views etc) anytime soon regardless of how many efforts are putted into EF Migrations and Code First metadata infrastructure. That's why I strongly believe that the database should be developed with database tools and not EF Migrations. Microsoft SQL Server Data Tools does this job extremely well with it's version control functionality, snapshots, localdb etc. migrations arn't enoug - Chris Barry 2012-04-08 20:00

It's always the disadvantage of using automated tools to do a DBA's job - jessehouwing 2012-04-10 13:37

you can use fluent definition but indexes. compute columns: implement in model. object description: comments of properties (column) etc. I think that we can tune DB after code first (of course with migration - Nuri YILMAZ 2012-04-12 07:29

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

2012-04-15 18:29
by NSGaga