使用 Linq-to-Sql 还可以吗

Question

当 Linq-to-Sql 第一次发布时，我经常将它用于不需要真正的多层架构的中小型项目。

NHibernate、小型中间件、矫枉过正

在我工作的地方，我们现在几乎只使用 NHibernate 进行真正的领域驱动开发。

我正在开发一个小型临时（可能是一年，也许更少）中间件组件，NHibernate 在配置和保持实体最新方面感觉有点过头了。特别是因为我对数据库没有任何控制权，所以它有时会发生变化，而且有点“遗留”。

最近对数据库进行了一些更改，NHibernate 映射不是很完整。

Linq-to-Sql？还是英孚？

我认为只删除我拥有的 IRepository 实现并将其替换为 Linq-to-Sql 实现可能会更容易。然后我可以只使用 lambdas 进行简单的查询，只需将表拖放到其中。

RAD 但死了？

在这种情况下，Linq-to-Sql 的 RAD 元素是有意义的。但它本质上是旧技术。我不应该使用它吗？我从未使用过实体框架。我应该使用它吗，它使用起来是否简单快捷？

干杯

Answer 1

使用 Linq-to-sql 还可以吗？

是的。可以使用任何能够让您及时交付具有所需功能和质量的产品的技术。您仍然可以找到使用 ASP、ADO、VB6 的项目。微软技术在许多国际公司中遇到困难的一个原因是他们的产品寿命很短。 Linq-to-sql 上市不到 2 年，被微软弃用，但公司/社区对此争论不休，微软稍微改变了他们的策略。 Linq-to-sql 没有新功能，但仍受支持且功能齐全的技术。

Linq-to-sql 或 EF 会解决您的问题吗？

这取决于。也许是，也许不是。不要相信有关 RAD 的营销公告。有时我觉得人们认为 RAD 是关于设计师的。 No。支持 RAD 的工具是关于定义明确的 API，它易于理解、易于使用且不包含意外行为 (Principle of least surprise) - 您将使用 API 快速构建应用程序原型，但仍需要理解和实践。当您将 NHibernate 的映射与手动执行整个数据访问进行比较时，它仍然是原型。我们甚至可以遵循好的框架的基本规则：容易的事情容易做，困难的事情可能。这是 NHibernate 比 EF 或 Linq-to-sql 做得更好的东西。

如果您了解 NHibernate，但对 EF 或 Linq-to-sql 没有任何实际经验，您可以确定 Linq-to-sql 或 EF 都不会提高您在第一个或两个项目中的工作效率你用吧。如果您在 NHibernate 更改为 EF 或 Linq-to-sql 方面没有太多经验，可能不会导致暂时失去生产力。

我也不认为 EF 或 Linq-to-sql 通常会在数据库更改的情况下帮助您。我记得 Linq-to-sql 设计器根本没有更新映射功能，因此它经常在没有设计器的情况下完全使用，因此您仍然必须手动修改映射。 EF 从数据库更新模型在这里可能会有所帮助，但它不是灵丹妙药。某些更新可能需要手动修改 EDMX 文件（巨大的 XML）。

最后要知道，NHibernate 的映射功能要强大得多，尤其是在处理遗留数据库时。 Linq-to-sql 的映射功能非常有限，主要是表到类的 1:1 映射，但有一些例外（基本 TPH 继承）。 EF 提供了更复杂的映射功能，但它以某种方式期望数据库的正确设计。

Answer 2

如果您（和您的同事）对 NHibernate 感到满意，那么它应该与 Linq to SQL 一样 RAD。没有理由不使用 L2S，只要您了解它不会对 Microsoft 的更新和改进产生太大影响，但是根据我的经验，如果您已经知道如何使用这两个框架，则无需重新进行工作只是因为 L2S 可能会更 RAD 一点

Answer 3

关于 NHibernate 与 L2S/EF 的一些很好的讨论

• Entity Framework vs LINQ to SQL
• MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)

在您的具体情况下，您应该使用您最熟悉的技术。尽管 Linq2Sql 相对简单——并且可以直接构建到语言中——但它确实有一点学习曲线和自己的一套陷阱！