有时我们不得不在 2 或 3 种技术/策略之间进行选择来开发模块。
现在，对于每个小型或大型组件/模块/项目，我们都有几乎无数的选择。对于那些有多年经验的人来说可能很容易，但对于那些刚接触编程的人来说，比如不到一年的时间就不容易了。
我有时会对 .NET 世界中的数据访问选择感到沮丧。我们不能去阅读市场上的每一种工具，以及它为每一种产品提供的东西。
提出这个问题的原因是最近我们必须处理一个项目，并且 DataAccessLayer 的规范是使用 ADO.NET 完成的。进入项目大约 20% 的过程中，一位新开发人员加入了我们的部门(但不是我们的团队)。我认为他很聪明，乐于助人，我们喜欢和他一起工作。
在代码审查期间，他亲自建议我们最好将 LINQ to SQL 用于我们正在处理的模块。他很有说服力。经过积极的辩论，我们同意使用 LINQ to SQL。
然而，“管理层”对此并不满意。有人争论说我们应该想出这个 “好主意” 在启动模块之前。他们的论点是，到目前为止，20% 的工作已经花费了资源，而这些工作将被浪费掉。
鉴于新产品/技术/策略频繁出现的步伐，我们发现很难获得有关所有这些工具和技术的所有信息。
我们已经成功使用 ADO.NET。我们对 LINQ(一般)、NHibrnate 和许多其他方面有一个想法，但我们继续使用 ADO.NET。我不反对学习新事物，这就是我们共同插入使用 LINQ 的原因。
问题
我们当时做出这个选择有错吗？
是否有任何指标或指导方针可以决定在某些情况下选择哪种技术，以及何时不中途切换？
最佳答案
时间框架和项目风险。这些是基本面。
我对 LINQ 或 ADO.NET 并不熟悉，但这并不重要。
在高层次上，我看不出 LINQ 和 ADO.NET 之间没有区别。我可以看到 LINQ “更好”、“更优雅”、更少代码和更清晰。但是，事实上，如果团队已经熟悉并熟悉 ADO.NET，那么这些风险并不大。您仍然需要将数据进出数据库，并且团队已经知道如何处理“不太优雅、更多代码、不太清晰”的 ADO.NET(请注意，这些只是概括，而不是判断本身) .
如果项目中有时间能够吸收采用 LINQ 之类的东西，而且即使对于新技术也明显更好，那么我可以看到在新工作中采用它，也许在旧的、已完成的工作中对其进行改造。
如果你有一个为期一年的项目，很容易看出时间线上哪里有足够的“松弛”来采用新技术。如果这是一个 1 个月的项目，也许不会那么多。
虽然那里有许多很棒的新技术，而且它们每天都在问世，但可以说很多关于“你知道的魔鬼”与采用新的和未经证实的东西的争论。这就是为什么，就我个人而言，我会在家里以“爱好模式”进行大部分此类探索，以便在新技术可能更适合和适合我们尝试和真实的情况下，我可以更好地了解新项目“老派”方法。
否则，需要在项目规范期间提供时间来证明新技术以确定其在项目开始时是否适合纳入。很多时候，制定规范的人没有得到那个时间。
关于.net - 选择数据访问技术时要考虑的问题？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2142771/