我对利弊有疑问，当我比较netTiers(与codesmith)和Entity Framework时，我应该提到什么
这个问题在netTiers(与codesmith)周围被问了很多次，我发现的所有话题都很古老，可能比Entity Framework流行的时候更古老。
事实上，我对Entity framework很熟悉(不熟练，但我喜欢它，我经常使用它)，对netTiers也不太熟悉(与codesmith)，这就是为什么我想知道当我在复杂项目中看到netTiers时该决定什么。一种选择是留下来面对面地处理所有问题，我认为这需要大量的时间。另一个-使用微软已经管理和预先设计的高级实用程序(这就是entity framework在我使用netTiers几天后看起来多么漂亮)。
舒适级别是一个很大的级别，如果你是主要的开发人员，并且你喜欢实体框架，那么这是坚持它的一个很大原因。然而，在你的情况下，听起来你进入了一个使用netTiers的新环境，你更喜欢EF，并且你想要一个借口切换到你喜欢的框架。
我已经使用了这两个框架，并且大约在同一时间开始使用它们。在我看来，他们都有闪光点。
EF更适合小型项目，它主要用于代码优先的方法，并在新版本的应用程序推出时允许应用程序升级数据库方面大放异彩。然而，它也促进了使用linq-to-sql生成较差的sql查询，因此总体数据吞吐量往往低于netTiers。如果开发人员几乎没有直接的数据库经验，或者没有对数据库的直接管理访问权限，那么EF对他们来说可能是一个更具吸引力的选择，因为它可以让他们收回一点控制权。
netTiers在减少代码编写和维护方面大放异彩。与EF不同，它只支持数据库优先的方法。netTiers会自动为您生成整个DAL，并在单击生成按钮时保持更新。它更适用于大型项目，尤其是web项目，在这些项目中，您可以完全控制托管数据库，并可以轻松地对其进行升级。netTiers的致命弱点是用于生成DAL的CodeSmith配置。这个配置可能需要保留在源代码管理中，因为如果它丢失了，并且是高度定制的，那么很难重新创建它，这样下次按下按钮时就会以相同的方式生成DAL(这可能是开发人员流失期间的一个问题)。netTiers还允许您查看所有DAL代码，并根据需要进行调试，而EF只是您一直使用的dll。
从历史上看，netTiers是在EF真正成为一个可行的框架之前开发的。它的制定是为了解决一个真正尚未解决的问题。从那时起，英孚真正成长起来，在许多领域都超过了netTiers，这导致netTiers的受欢迎程度直线下降。EF比netTiers更易于配置和灵活。然而，EF在代码生成领域从未能够触及netTiers，需要做更多的工作才能确保其在数据吞吐量方面与netTiers持平。
我见过开发人员手动修改DAL代码的应用程序，这打破了netTiers通过自动生成DAL来减少编码时间的能力。只要你没有陷入这种情况，并且你已经有了一个坚实的netTiers设置，那么试图将其剥离并转换为EF可能是浪费精力。