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

Question

有时，我们必须在2到3项技术/战略之间作出选择，以开发模块。

现在，对于每一个小的或大的组件/模块/项目，我们几乎有不可数的选项。对于那些有多年经验的人来说，这可能很容易，但对于那些刚开始编程的人来说就不容易了，比如说不到一年。

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

提出这个问题的原因是，我们最近不得不做一个项目，DataAccessLayer的规格与ADO.NET一起完成。在进入项目的过程中，有20%的新开发人员加入了我们的部门(但不是我们的团队)。我认为他很聪明，很有帮助，我们很喜欢和他一起工作。

在一次代码评审中，他亲自建议我们最好在我们正在开发的模块中使用LINQ。他很有说服力。经过积极的辩论，我们同意使用LINQ。

然而，“管理层”对此并不满意。有一种观点认为，在启动模块之前，我们应该想出这个“奇妙的想法”。他们的论点是，到目前为止，有20%的工作已花在资源上，而这些工作将会被浪费掉。

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

我们在使用ADO.NET方面取得了成功。我们对LINQ (一般地)、NHibrnate和许多其他方面有了一个想法，但是我们继续使用ADO.NET。我并不反对学习新东西，这就是我们共同推动使用LINQ的原因。

问题，我们当时做了这个选择，是不是有错了？

是否有任何衡量标准或准则来决定技术在某些情况下的选择，以及何时不切换到中流？

Answer 1

时间框架和项目风险。这些都是基本原则。

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

在高层次上，我可以看到LINQ和ADO.NET没有区别，我可以看到LINQ是“更好”、“更优雅”、更少代码和更清晰。但是，事实上，如果团队对ADO.NET已经很熟悉和满意了，那么这些并不是很大的项目风险。您仍然会在数据库中获取数据，并且团队已经知道如何处理“不那么优雅、更多代码、更不清晰”的ADO.NET (请记住，这些都是泛化的，而不是判断本身)。

如果这个项目中有时间能够吸收像LINQ这样的东西，而且即使是一种新的技术，它显然也是更好的，那么我可以看到将它用于新的工作，或者在旧的、已完成的工作中对它进行改进。

如果你有一个长达一年的项目，很容易看出在时间线上有足够多的“松弛”来采用一项新技术。如果这是一个为期一个月的项目，也许就没那么多了。

虽然有很多优秀的新技术，而且他们每天都会出现，但是关于争论“你知道的魔鬼”和采用一些新的、未经证实的东西，我们可以说很多。这就是为什么，我在家里，在“业余爱好”模式下，在自己的时间里做了大部分这样的探索，这样我才能更好地了解新的项目，当一项新的技术可能比我们尝试过的、真实的“老派”方法更合适和合适时。

否则，需要在项目规范期间提供时间来验证新技术，以确定其是否适合于在项目开始时包含进来。很多时候，制定规范的人都没有那么多时间。

Answer 2

在启动一个新项目时，要记住所有的现有技术，这是一项具有挑战性、也越来越困难的任务。

我总是试图追随任何最前沿的东西，这样我就知道外面是什么了。这是一个阅读大量博客，出席会议，并保持最新的问题。

尽管如此，您不希望总是使用使用，不管是什么都是最前沿的。我的经验法则是估计产品的装运日期。我试图使用任何技术将是最新的，已经收到至少一个“服务包”或更新的日期，我们将要发货。诚然，这涉及很多猜测，因为船舶日期不知道，但经验(在观察行业)非常有帮助。

有一门艺术可以对哪些技术会受欢迎，以及哪种技术会随着时间的推移而消失，做出有教养的猜测。不幸的是，这真的是一个经验问题。如果您有一个具有多年经验的开发人员，他们也能跟上当前的技术(很重要)，那么他们是帮助决策的好资源。

Answer 3

一年的经验，这不是你的错，没有选择正确的技术在第一位。这样的决定是很难做出的，而且是有经验的。

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