从“Linq 到 SQL”迁移到实体框架 4
问题
过去，我们的开发团队决定创建一个新的企业应用程序，并决定使用“Linq to SQL”，因为实体框架“很糟糕”。 （不是我的意见！）他们使用 Visual Studio 2008，并且 EF 不是默认设置的一部分，但需要额外的加载项。因此决定使用Linq to SQL来访问数据库。结果，我们现在有多个围绕包含 DBML 和 L2SQL 实体的数据模块类库的项目...
需要
现在很明显，那些开发人员错了。一些人转到了其他公司，一些新公司也包含在这个项目中。 （包括我。）我们想改用实体框架。最好是使用 .NET 4.0 的版本 4...这将使我们能够更灵活地处理数据，并且我们希望在多个实体中包含一些继承，使代码更易于阅读和更好使用。
问题：如何...
那么，如何从“Linq to SQL”迁移到 Entity Framework 4，而不需要重写大量代码？
Problem
In the past, our development team decided to create a new enterprise application and decided to use "Linq to SQL" since the Entity Framework "sucked". (Not my opinion!) They used Visual Studio 2008 and the EF wasn't part of the default setup but required an additional add-in. So the decision was made to use Linq to SQL to access the database. As a result, we now have multiple projects around a datamodule class library containing a DBML and L2SQL entities...
Needed
It is now clear that those developers were wrong. Some moved on to other companies and a few new ones are included in this project. (Including me.) And we would like to use the Entity Framework instead. Preferably version 4 with .NET 4.0... This will allow us more flexibility with our data and we're hoping to include some inheritance in several of the entities, making the code easier to read and nicer to use.
Question: How to...
So, how to migrate from "Linq to SQL" to the Entity Framework 4 without the need to rewrite much of our code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
手动。没有其他方法，如果您没有使用数据模块的所有项目的集成测试套件，则在编写这些测试之前不应开始任何迁移，因为许多在 Linq-to-Sql 中工作的 linq 查询不起作用在 Linq-to-entities 中 (不仅仅是 Linq 查询）。
一般来说，迁移是错误的想法。看起来您想要进行迁移只是因为您想使用另一种技术。这项努力将增加什么真正的商业价值？ EF 和 Linq-to-entities 提供了一些补充，但它在很多方面比 Linq-to-sql 差。没有必要接触有效的代码，除非您有一些真正的业务需求，这将是必要的。尤其是迁移到 EFv1 将是非常愚蠢的举动。您可以在当前代码中使用 .NET 4，不会出现任何问题，因为 Linq-to-Sql 也是 .NET 4 的一部分。
如果你问我，以前的开发人员在 EFv1 和 Linq-to-Sql 之间做出选择时做出了很好的选择。
Manually. There is no other way and if you don't have integration test suite for all projects using the data module you should not start with any migration until you write those tests because many linq queries which worked in Linq-to-Sql doesn't work in Linq-to-entities (and not only Linq queries).
Generally that migration is wrong idea. It looks like you want to make a migration just because you want to use another technology. What real business value will be added by this effort? EF and Linq-to-entities offers some additions but it is in many ways worse than Linq-to-sql. There is no need to touch code which works unless you have some real business requirement which will make this necessary. Especially migrating to EFv1 would be really stupid move. You can use .NET 4 with your current code without any problems because Linq-to-Sql is part of .NET 4 as well.
If you ask me the former developers made a good choice when they made selection between EFv1 and Linq-to-Sql.