我应该迁移到实体框架吗？

Question

我一直在使用SqlCommand该类并编写自己的T-SQL查询很长时间了。我坚持使用它是因为我对此感到满意，它可能源于我在拥有许多其他不错选择之前的几天开始从事Windows开发。我从事Web开发大约十年了，至今仍在使用它并编写自己的查询字符串。我已经为我的所有数据库需求动态编写了一个动态类，我所要做的就是编写T-SQL，我可以快速完成该任务并在任何项目中使用。

其他开发人员在看到我的代码时大开眼界，并鼓励我学习一点都不喜欢的LINQ。

我现在正在ASP.NET MVC中开始一个新项目，现在感觉应该摆脱恐龙时代，转到Entity Framework来处理我的数据。

我知道SqlCommand该类是Entity Framework幕后工作的基本要素，所以我觉得为什么我应该通过中间人（实体）来获得相同的结果并花时间学习一些新知识。

有人可以向我解释为什么我需要继续前进，还是我应该坚持我所知道的？

Answer 1

切换到EF的主要原因是

• 学会EF后，开发起来会更快
• 特别是在大多数情况下，联接更容易编写
• 您将在编译时检查所有列和表是否确实存在
• 您可以选择使用EF迁移，这是目前最好的数据库迁移工具之一

我几年前（通过Linq2SQL）进行了切换，从没有回头。

首先使用EF代码并使用迁移。

Answer 2

好吧，使用SqlCommand ...如果做得正确，您可能已经编写了等效于ORM的代码，或者正在花费大量时间编写代码，这些代码的工作包括打包参数以及将列映射到对象。如果您没有执行任何上述操作，则可能是您的代码不安全并且正在传递未类型化的数据集，然后进行了大量的强制转换，或者您正在执行容易发生SQL注入的危险的串联SQL查询。

使用EF（或任何ORM）的优点是它可以处理SQL生成，对象映射，参数打包，并为您提供了非常强大的查询接口，可让您非常快速地编写多个查询。

可以写一行的时候为什么还要写十行代码？

是否使用EF确实是个人选择……但是，如果您正在进行认真的，面向对象的开发，则应该使用某种类型的ORM（甚至可能是微型ORM，例如精致的ORM）。或为此编写您自己的微型Orm。

在没有某种自动映射技术的情况下使用ADO只是一个巨大的痛苦。