使用 Linq 是否会使后期维护/升级我的项目变得更加昂贵?
之前我会使用在代码投入生产后易于修改的存储过程。
我正在为一个拥有大量内联 sql 的遗留应用程序的客户工作。他们已经付费将这些内容放入需要快速响应时间的应用程序的存储过程中。他们对使用 Linq 的前景并不感到兴奋,因为在他们看来它也像内联 sql。
Linq 是否等同于内联 sql?我知道 Linq 会让我的生活更轻松,但是一两年后呢?
使用 Linq 是否会使后期维护/升级我的项目变得更加昂贵?
之前我会使用在代码投入生产后易于修改的存储过程。
我正在为一个拥有大量内联 sql 的遗留应用程序的客户工作。他们已经付费将这些内容放入需要快速响应时间的应用程序的存储过程中。他们对使用 Linq 的前景并不感到兴奋,因为在他们看来它也像内联 sql。
Linq 是否等同于内联 sql?我知道 Linq 会让我的生活更轻松,但是一两年后呢?
只要现在表达更清晰,更容易理解,那么我很确定以后会更容易维护。
我发现使用实体框架的唯一缺点是如果您需要进行紧急更改(比如说),您正在查看代码更改而不是仅仅修改存储过程。对于我们的环境,对数据库进行脚本更改比推出新代码要容易得多。因此,它在某种程度上归结为您在您的环境中更喜欢哪个,推送新的 .dll 或推送存储过程更改。
至于可维护性,我们使用 Entity Framework 已经有一段时间了,并且升级/可维护性问题为零。它易于编写,易于维护,如果您正确编写 Linq,则易于更新/更改。
在所有内容都基于 proc 存储的应用程序中,新功能必须同时进行编码和脚本化——推出可能会很痛苦。使用更新的做事方式,通常可以使用不同的 linq 表达式公开新函数 - 创建新存储过程和升级脚本的痛苦消失了。(当然代码仍然需要推出..)
在我看来,速度可以忽略不计 - 存储过程肯定会更快,EF 并不总是提供最好的 sql,但它可以让生活变得简单:如果我有一个中间/数据层来返回客户按 ID,我想按名称获取客户;我需要一个新方法、新存储过程、用于推出它的脚本等。而使用 EF,我可以添加一个新方法。