选择数据访问技术时要考虑的问题？

Posted 2023-02-16

【中文标题】选择数据访问技术时要考虑的问题？

【英文标题】：Issues to consider when choosing data access technologies?

【发布时间】：2011-01-09 17:02:20

【问题描述】：

有时我们不得不在 2 或 3 种技术/策略之间进行选择来开发模块。

现在，对于每个小型或大型组件/模块/项目，我们都有几乎数不胜数的选择。对于那些有多年经验的人来说可能很容易，但对于那些刚接触编程的人来说，比如不到一年的时间，这并不容易。

我有时会对 .NET 世界中的数据访问选择感到沮丧。我们不能去了解市场上的每一种工具，以及它为每一种产品提供的东西。

提出这个问题的原因是最近我们必须处理一个项目，并且 DataAccessLayer 的规范是使用 ADO.NET 完成的。进入项目大约 20% 的过程中，一位新开发人员加入了我们的部门（但不是我们的团队）。我认为他很聪明，乐于助人，我们喜欢和他一起工作。

在代码审查期间，他亲自建议我们最好将 LINQ to SQL 用于我们正在开发的模块。他很有说服力。经过积极的辩论，我们同意使用 LINQ to SQL。

但是，“管理层”对此并不满意。有人争论说我们应该在开始模块之前想出这个“绝妙的想法”。他们的论点是，到目前为止 20% 的工作已经花费了资源，而这些工作将被浪费掉。

鉴于新产品/技术/策略的频繁出现，我们发现很难获得有关所有这些工具和技术的所有信息。

我们已经成功使用 ADO.NET。我们对 LINQ（一般）、NHibrnate 和许多其他方面有一个想法，但我们继续使用 ADO.NET。我不反对学习新事物，这就是我们共同推动使用 LINQ 的原因。

问题 我们当初做出这个选择有错吗？

是否有任何指标或指南可用于决定在某些情况下选择哪种技术，以及何时不中途切换？

【问题讨论】：

管理层应该很高兴您已经准备好适应新开发人员的新建议，从而节省时间和/或金钱。如果管理层想将责任归咎于某人，它应该指出自己缺乏进一步的培训（为您的团队）或缺乏监督和对自己的洞察力。

这是投票、咆哮、博客还是什么？

顺便说一句，您知道 MS 停止了对“LINQ to SQL”的进一步开发，转而支持“LINQ to Entities / Entity framework”？

您在评估后使用您认为有用的东西。例如，使用带有 MS MVC 2 的模型绑定，您可以将 POCO 类绑定到相同的命名视图。您可以根据自己的情况手动执行此操作，并在适合的时间和地点使用新技术。就 NHibernate 而言，如果团队的所有成员都理解它，团队将使用它（就像任何技术一样）。您将退回到您可以在时间范围内合理处理的技术。

【参考方案1】：

在开始新项目时牢记所有当前技术是一项具有挑战性且越来越困难的任务。

我总是努力追随最前沿的东西，这样我就知道那里有什么。这是阅读大量博客、参加会议和保持最新状态的问题。

话虽如此，您不想总是使用任何最前沿的东西。我的经验法则是估计产品的发货日期。我尝试使用任何最新的技术，在我们将要发货的日期之前至少收到一个“服务包”或更新。诚然，这需要大量猜测，因为发货日期未知，但经验（观察行业）有很大帮助。

有根据地猜测哪些技术会流行，哪些技术会随着时间的推移而消失是一门艺术。不幸的是，这真的是一个经验问题。如果您有一位拥有多年经验的开发人员，并且掌握最新技术（很重要），那么他们是帮助您做出此决策的好资源。

【讨论】：

恕我直言，您应该很少使用最前沿的任何东西。发货日期是一回事，但尖端技术有时会被证明只是大肆宣传，而且往往很快就会从市场上消失。

这就是为什么我说“研究前沿”但目标是至少有一次更新的东西（所以它不会在交付时间上处于前沿）。

【参考方案2】：

有一半的时间感觉更多的是使用您手头的资源（即人们知道哪些语言？）以及我们获得了哪些许可？

【参考方案3】：

拥有 1 年的经验，首先没有选择正确的技术不是您的错。这些决定很难做出，而且需要经验。

这里的过错很可能是项目经理在项目开始时没有提供正确的资源来做出这些架构决策。

【参考方案4】：

时间框架和项目风险。这些是基础。

我对 LINQ 或 ADO.NET 并不熟悉，但这并不重要。

在高层次上，我看不出 LINQ 和 ADO.NET 之间没有区别。我可以看到 LINQ “更好”、“更优雅”、更少代码和更清晰。但是，事实上，如果团队已经熟悉并熟悉 ADO.NET，那么这些风险并不大。您仍然需要将数据进出数据库，并且团队已经知道如何处理“不太优雅、更多代码、不太清晰”的 ADO.NET（请注意，这些只是概括，而不是判断本身） .

如果项目中有时间能够吸收采用 LINQ 之类的东西，而且即使对于新技术也明显更好，那么我可以看到将它用于新工作，也许在旧的、已完成的工作中进行改造.

如果您有一个为期一年的项目，很容易看出时间线中的哪些地方很容易有足够的“松弛”来采用新技术。如果是 1 个月的项目，可能不会那么多。

虽然那里有许多很棒的新技术，而且每天都在问世，但可以说很多关于“你知道的魔鬼”与采用未经证实的新事物之间的争论。这就是为什么，就我个人而言，我会在家里以“爱好模式”进行大部分此类探索，以便在新技术可能更适合和适合我们尝试和真实的情况下，我可以更好地了解新项目“老派”方法。

否则，需要在项目规范期间留出时间来证明新技术，以确定其在项目开始时是否适合纳入。很多时候，制定规范的人没有得到那个时间。

【讨论】：

+10。希望我能不止一次地投票。在已经在开发的项目中切换技术是非常具有破坏性的（并且会扼杀最后期限）。尤其是当所涉及的开发人员必须即时学习新技术时，他们已经落后于技术变革的计划。总会有未来的项目，当您已经花时间学习新技术时，整合新技术会容易得多。 （话虽如此，LINQ 可以很容易地与 ADO.NET 共存，但仍然......下一次，不是这次。）

【参考方案5】：

对于给定的解决方案或开发项目，哪些技术是“合适的”有很多因素可以衡量。

很多时候，您会在选项方面受到许多内部和外部影响，什么是“正确”的，什么是流行的，什么可能是最有趣的。

在我看来，做出“正确”的决定是选择最稳定、记录在案、可行的解决方案。现在要做到这一点，您需要跟上技术并知道那里有什么。因此，跟上 LINQ、Entity Framework 等的步伐势在必行。

真正的“艺术”是决定什么适合您的环境，每个环境都不同，您需要考虑许多不同的项目。这只是内部使用吗？如果没有，你对环境有什么样的控制和影响？是否可以使用最新版本的VS等。

我不喜欢使用“尖端”，因为它就是这样。使用新工具需要有技术基础。

【参考方案6】：

使用“LINQ”不一定是一个“奇妙”的想法，无论是在项目的开始还是结束。如果您的团队有使用 ADO.NET 的经验并使用该技术成功完成了项目，那么这确实是您应该使用的技术。

要点是，如果您有一个团队“了解”VB6 的内里外外...猜猜看...您更喜欢编写 VB6。

使用团队中大多数人都熟悉且知识渊博的技术。（希望这就是您招聘的目标。）

【参考方案7】：

在项目已经开始之后切换到Linq-to-SQL，当不是每个人都准备好时，可能是一个错误，是的。即使您应该一开始就使用它，最好在项目开始后坚持使用您所知道的。反之则不同：如果您在项目开始时尝试新事物，但结果很糟糕，最好切换回更熟悉的事物。

在 Linq-to-sql 的情况下，它不太可能给您带来值得切换到它的优势项目中期。这是一场赌博，不幸的是，这听起来好像没有成功。

.Net 数据访问选项让我们中的许多人发疯。你不是一个人。即使试图了解所有技术也变得越来越困难。要正确评估，您必须有经验并彻底调查。你肯定不想尝试最新的东西，因为它看起来很整洁。我们熟悉的一些旧技术（如 ADO.NET）运行良好。