我对利弊有疑问，当我比较netTiers（与 codesmith）和Entity Framework
这个问题被问了很多次netTiers（和 codesmith 一起），我发现的所有主题都非常古老，Entity Framework可能比它变得如此流行的时间还要早。
我实际上很舒服Entity framework（不精通，但我喜欢它并且我经常使用它）并且不是很接近netTiers（和 codesmith），这就是为什么我想知道当我netTiers在复杂项目中看到什么时要决定的原因。一种选择是留下来面对面处理所有问题，我认为这需要大量时间。另一个 - 使用 Microsoft 已经管理和预先设计的精美实用程序（entity framework在我花了几天时间之后，这对我来说似乎很漂亮netTiers）。
舒适度很重要，如果您是主要开发人员，并且您喜欢 Entity Framework，那么这是坚持使用它的重要原因。但是，在您的情况下，听起来您正在进入一个使用 netTiers 的新环境，您更喜欢 EF，并且想要一个切换到您最喜欢的框架的借口。
我已经使用了这两个框架，并且大约在同一时间开始使用它们。在我看来，他们都有自己擅长的领域。
EF 更适合小型项目，它主要用于代码优先的方法，并且在推出新版本的应用程序时允许应用程序升级数据库。但是，它也促进了使用 linq-to-sql 生成较差的 sql 查询，因此总体数据吞吐量往往低于 netTiers。如果开发人员几乎没有直接的数据库经验，或者没有对数据库的直接管理访问权限，那么 EF 可能对他们来说是一个更有吸引力的选择，因为它可以让他们收回一点控制权。
netTiers 在减少代码编写和维护方面大放异彩。与 EF 不同，它仅支持数据库优先方法。netTiers 自动为您生成整个 DAL，并在单击生成按钮时保持更新。它更适合大型项目，尤其是您可以完全控制托管数据库并可以轻松推送升级的 Web 项目。netTiers Achilles heel 是用于生成 DAL 的 CodeSmith 配置。此配置可能需要保存在源代码管理中，因为如果它丢失并且高度自定义，那么重新创建它可能会非常困难，因此下次按下按钮时会以相同的方式生成 DAL（此在开发人员周转期间可能是一个问题）。netTiers 还允许您查看所有 DAL 代码，并根据需要进行调试，而 EF 只是您坚持使用的一个 dll。
从历史上看，netTiers 是在 EF 真正成为可行框架之前开发的。它的开发是为了解决一个真正尚未解决的问题。从那时起，EF真正成长起来，在很多领域都超过了netTiers，这导致netTiers的人气一落千丈。EF 比 netTiers 更具可配置性和灵活性。但是，EF 在代码生成方面始终无法触及 netTiers，并且需要做更多工作才能确保在数据吞吐量方面与 netTiers 保持一致。
我见过开发人员手动修改 DAL 代码的应用程序，这破坏了 netTiers 通过自动生成 DAL 来减少编码时间的能力。只要您没有陷入这种情况并且您已经拥有可靠的 netTiers 设置，那么尝试将其撕掉并转换为 EF 可能会浪费精力。