时限和项目风险。这些是基本原则。
我对LINQ或ADO.NET不太熟悉，但这并不重要。
在高层次上，我看不出LINQ和ADO.NET之间有什么区别。我可以看到LINQ“更好”、“更优雅”、更少的代码和更清晰。但是，实际上，如果团队已经熟悉并适应ADO.NET，那么这些都不是大的项目风险。您仍然要将数据从数据库中取出和取出，团队已经知道如何处理“不优雅，更多的代码，不太清楚”ADO.NET（请注意，这些是一般性的，而不是判断本身）。
如果项目中有时间能够吸收采用类似LINQ的东西，而且它甚至对一种新技术来说也明显更好，那么我可以看到在新的工作中采用它，也许在旧的、完成的工作中对其进行改造。
如果你有一个长达一年的项目，很容易看到时间表上有足够的“空闲时间”来采用一项新技术。如果是一个一个月的项目，可能就没有那么多了。
虽然有很多很棒的新技术，而且它们每天都在问世，但关于“你所知道的魔鬼”与采用未经验证的新技术的争论还有很多可以说的。这就是为什么，就我个人而言，我在我的时间，在家里进行大部分这种探索，在“爱好模式”，以便我可以更好地了解新的项目时，一个新的技术可能适合和适当的超过我们的尝试和真正的“老派”方法。
否则，在制定项目规范时需要留出时间来验证新技术，以确定其在项目开始时是否适合纳入。很多时候，制定规范的人没有时间。

在开始一个新项目时，要记住所有当前的技术是一项具有挑战性的任务，而且越来越困难。
我试着总是跟随最前沿的东西，这样我就知道外面有什么。这是一个阅读大量博客，参加会议，保持最新状态的问题。
话虽如此，你不想总是使用什么是最先进的。我的经验法则是估计产品的发货日期。我尝试使用任何技术将是最新的，已经收到至少一个“服务包”或更新的日期，我们将船舶。当然，这涉及到大量的猜测，因为船舶日期是未知的。但经验（观察行业）帮助很大。
有一门艺术就是要根据经验来猜测哪些技术会流行，哪些会随着时间的推移而过时。不幸的是，这实际上是一个经验问题。如果你有一个拥有多年经验的开发人员，他也能跟上当前技术的发展（这很重要），那么他们是帮助你做出决策的一个很好的资源。

对于给定的解决方案或开发项目，有很多因素可以影响什么样的技术是“合适的”。
很多时候，你会有很多内部和外部的影响，关于选项，什么似乎是“正确的”，什么是流行的，什么可能是最有趣的。
在我看来，做出“正确”的决定就是选择最稳定、最有文档记录、最可行的解决方案。现在要做到这一点，你需要跟上技术的发展，知道外面有什么。所以跟上LINQ、实体框架等是势在必行的。
真实的的“艺术”是决定什么适合你的环境，每个环境都是不同的，你有许多不同的项目要考虑。这是内部使用吗？如果不是，你对环境有什么样的控制和影响？是否可以使用最新版本的VS等。
我不是一个使用“尖端”的爱好者，只是因为它是什么。需要有一个技术基础来使用新的工具。

在项目已经开始之后，当不是每个人都准备好的时候，切换到Linq-to-SQL可能是一个错误，是的。即使你 * 应该 * 使用它开始，最好是在项目开始之后坚持你所知道的。反之则不同：如果你在项目开始的时候尝试了一些新的东西，但是进展很糟糕，那么最好换回一些更熟悉的东西。
在Linq-to-sql的例子中，它不太可能给你带来值得在项目中期转向它的优势。这是一场赌博，不幸的是，听起来它没有成功。
.Net数据访问选项正在让我们中的许多人发疯。你并不孤单。甚至试图了解所有的技术都变得越来越困难。为了正确地评估，你必须有经验并进行彻底的调查。你肯定不想尝试最新的东西，因为它看起来很整洁。我们熟悉的一些旧技术（如ADO .NET）工作得很好。

有了1年的经验，没有选择正确的技术不是你的错。这种决定很难做出，需要经验。
在这里，谁有错更可能是项目经理，因为他没有提供正确的资源来在项目开始时做出那些架构决策。

有一半的时间感觉更多的是关于使用你手头上的资源（比如，人们知道什么语言？）以及我们有什么许可证？

使用“LINQ”不一定是一个“奇妙”的想法，无论是在项目的开始还是结束。如果您的团队有使用ADO.NET的经验，并且成功地使用该技术完成了项目，那么这确实是您应该使用的技术。
关键是，如果你有一个从里到外“了解”VB6的团队......那么你猜怎么着......你最好喜欢编写VB6。
使用团队中大多数人熟悉和熟悉的技术（希望这是你招聘的目标）。