为什么我应该使用Entity Framework codefirst，如果它不能在安全生产中使用，像索引之类的东西无法描述 [英] Why should I use Entity Framework codefirst if it can't be used in production safely and things like indexes can't be described
问题描述
我目前使用的工具是
- ASP.NET MVC 3
- Entity Framework 4.3
- li>
一切都很顺利，但我发现一些Entity Framework CodeFirst有点粗略。
例如，我不得不使用 http://codefirstmembership.codeplex.com/ 来设置成员资格信息部分代码首次设置。这感觉有点ropey必须使用的东西第三方。显然，我应该是1337足以滚自己，但我不想咬伤太多从去。运行aspnet_regsql感觉可怕，并且会随着每个数据库更新而丢失。无论如何，让所有的工作与上述图书馆，这不是太糟糕。脚手架似乎已经破碎了。
现在，除了所有这些，现在似乎这些东西在我在现场环境中运行时会变得有点麻烦。任何我想在dev db和live db之间进行的模式更改都必须使用脚本进行手动管理，这样我就不会先丢失代码。
在过去一年里我一直在使用Google App Engine，希望代码首先能以同样的方式工作吗？即，进行更改并修改实时数据。现在我假设，由于没有做过严重的重构在应用程序引擎，它基本上不会对生产中的任何伤害。因此，您永远不能使用AppEngine重命名表。它总是创建一个新的表，并离开旧的。您必须手动端口传输数据。
所以我现在在想。为什么不只是去数据库第一？我一直在linq2sql工作3年，非常舒服与数据库。虽然TBH我的db源控制stratergy一直有一点....缺乏。所以我希望代码首先能够强化这种情况来改善，但它实际上让我觉得我应该去数据库，只是严格保持它的控制。
我会真正感谢任何关于这种情况的想法，以及如何比较使用Nhibinate？您正在描述的升级方案正在EF迁移中添加。
签出： http://coding.abel.nu/tag/ef-migrations/
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?
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: http://coding.abel.nu/tag/ef-migrations/
这篇关于为什么我应该使用Entity Framework codefirst，如果它不能在安全生产中使用，像索引之类的东西无法描述的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
