我有一个问题，关于比较netTiers（使用codesmith）和Entity Framework时应该提到哪些优缺点。
这个问题在很多场合下都被问及过，但是我发现所有的讨论都非常古老，比Entity Framework流行的时间还要早。
我其实非常熟悉Entity Framework（虽然不是专家级别，但我喜欢它，而且用的很多），对netTiers（使用codesmith）并不是很了解，这就是为什么当我在复杂项目中看到netTiers时，想知道该怎么决定。
一种选择是留下来，面对所有问题并耗费大量时间解决。
另一个选择是使用微软已经管理好的预先设计好的高端工具（这正是我在花了几天时间学习netTiers之后，感觉entity framework如此美妙的原因）。
如果您是主要的开发人员，且喜欢Entity Framework，则舒适水平非常重要，这是坚持使用它的一个非常重要的理由。但是，在您的情况下，听起来您正在进入一个使用netTiers的新环境，您更喜欢EF，并且希望找借口切换到自己最喜欢的框架。
我使用过两个框架，并且开始同时使用它们。在我看来，它们都有各自擅长的领域。
EF更适用于小型项目，主要是采用代码优先方法，并擅长允许应用程序随着应用程序的新版本而升级数据库。然而，它也会使用linq-to-sql生成较差的SQL查询，并且通常具有比netTiers更低的总数据吞吐量。如果开发人员没有直接的数据库经验，或者无法直接访问数据库，则EF对他们来说可能更具吸引力，因为它将使他们能够掌控一些控制权。
netTiers擅长减少编写和维护代码。与EF不同，它仅支持数据库优先方法。 netTiers会为您自动生成整个DAL，并在生成按钮的单击处更新它。它更适合较大的项目，特别是Web项目，在这些项目中您可以完全控制托管的数据库并轻松升级它。 netTiers的弱点是用于生成DAL的CodeSmith配置文件。该配置文件可能需要保存在源代码控制中，因为如果它被删除且高度定制化，则重新创建生成DAL的方式可能非常困难（在开发人员更替期间可能会出现此问题）。netTiers还允许您查看所有的DAL代码，并根据需要进行调试，而EF只是一个您无法更改的dll。
历史上，netTiers在EF真正成为可行框架之前就已经开发了。它是为解决尚未得到解决的问题而开发的。自那时以来，EF已经真正成长，许多方面已经超过了netTiers，这导致了netTiers的流行度下降。EF比netTiers更具可配置性和灵活性。但是，EF从来没有能够触及netTiers在代码生成方面的水平，并且需要更多的工作来确保它在数据吞吐量方面与netTiers保持同步。
我曾经见过一些开发人员手动修改DAL代码的应用程序，这破坏了netTiers减少编码时间自动生成DAL的功能。只要您不处于这种
