Entity Framework 4.x 是在棕地环境中进行开发的正确工具吗？
在棕地情况下开发或更新代码时，实体框架 4.x 是正确的工具吗？
与仅针对数据库进行写入相比，我可以期望获得哪些实际的生产力提升？
我将不胜感激任何意见。
Is Entity Framework 4.x the right tool to use when developing or updating code in a brownfield situation?
What realistic productivity gains can I expect over just writing against the DB?
I would appreciate any opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
或许？这实际上取决于具体情况。
如果您正在编写一个新模块来插入应用程序，这可能是使用 EF 最简单的情况，因为您将能够将其隔离在该新区域中。当我切换到它时，我发现与直接针对数据库编写（或使用存储过程或其他方式）相比，生产力得到了巨大的提高。从字面上看，将许多任务的时间减少了一半，并消除了大量高度重复的代码。
生产力的巨大提升在于不需要编写类（因为您已经有一个数据库，您可以告诉 EF 使用它，它会为您创建实体和类），然后不需要编写查询。我总是发现编写高度重复的查询很容易因为拼写错误而出错，并且您的 CRUD 操作都会为您处理好。
如果您采用现有的东西并试图将 EF 硬塞进去，那就有点不同了，而且里面有很多“这取决于情况”。如果有一些易于更换的东西，它可能会对您有很大帮助。但是，如果您最终会遇到一种令人困惑的混合情况，即在一个函数中对 EF 中的数据库执行一些操作，然后通过使用旧方式直接访问它来对同一个数据库执行更多操作？对于稍后开发该应用程序的其他人来说，将很难理解正在发生的事情以及所有移动部分如何交互。
交换它也可能意味着扔掉已经可以工作的代码来访问数据库，因此生产力的提高并不像你刚开始时那么高，因为在这种情况下你已经有了一个工作的解决方案。不过可能还是值得的。
Maybe? It's going to really depend on the situation.
If you're writing a new module to plug into the app, that's probably the easiest case to use EF because you'll be able to isolate it in that new area. I found massive productivity gains when I switched to it vs writing against the DB directly (or using stored procedures, or whatever). Literally cut the time to do many tasks in half and eliminated a large amount of highly repetitive code.
The big gains for productivity are in things like not having to write classes (since you already have a database you can tell EF to use it and it'll create the entities and classes for you), and then in not having to write queries. I always find writing the highly repetitive queries error prone just due to typos, and your CRUD operations are all taken care of for you.
It's a bit different if you're taking something existing and trying to shoehorn EF into it, and there's a lot of "it depends" in there. It might help you out a lot if there are things that are easy to replace. But if you're going to wind up with a confusing mix where in one function you do some stuff to the DB in EF and then do some more stuff to the same DB by hitting it directly using the old way? For someone else working on the app later it's going to be difficult to understand what's going on and how all the moving parts interact.
Swapping it in also may mean tossing out already working code to hit the DB, so the productivity gain isn't as high as when you're starting fresh since in this case you already have a working solution. Might still be worth it though.