当Linq-to-Sql首次发布时，我对那些不需要真正的多层架构的中小型项目使用了很多。
在我工作的地方，我们现在几乎只使用NHibernate进行真正的域驱动开发。
我正在开发一个小型临时（可能是一年，可能更少）的中间件组件，NHibernate在配置方面感觉有些过度，并使实体保持最新状态。特别是因为我无法控制数据库，它有时会发生变化，而且它有点“遗留”。
最近对数据库进行了一些更改，并且NHibernate映射不是很完整。
我认为仅仅删除我所拥有的IRepository实现并将其替换为Linq-to-Sql实现可能更容易。然后我可以使用lambdas进行简单的查询，只需拖放表格即可。
在这种情况下，Linq-to-Sql的RAD元素是有意义的。但它本质上是旧技术。我应该不用吗？我从未使用过实体框架。我应该使用它，它是否容易和快速使用？
欢呼声
答案 0 :(得分：6)
使用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提供了更复杂的映射功能，但它不知何故需要正确设计数据库。
答案 1 :(得分：2)
如果您（和您的同事）对NHibernate感到满意，那么它应该像Linq一样使用RAD。没有理由不使用L2S，只要你理解它不会对微软的更新和改进产生太大影响，但根据我的经验，如果你知道如何使用这两个框架，就不需要重新做这些工作了仅仅因为L2S 可能多一点RAD
答案 2 :(得分：2)
关于NHibernate vs L2S / EF的一些很好的讨论
在您的具体情况下，您应该选择最适合您的技术。虽然Linq2Sql相对简单 - 并且构建在语言中 - 它确实有一个轻微的学习曲线和它自己的一套陷阱！