使用N-Tier解决方案有任何不利原因吗？

Question

我对我的公司很新（2周），我们正在使用DotNetNuke的.NET 3.5 Team Foundation为我们的系统启动一个新平台。我们的“架构师”建议我们使用一个类项目。当然，我使用“3层”架构（业务，数据，Web类项目）。

使用这种架构有什么缺点吗？ Pro是将代码与数据分离，使类对象远离代码等等。

Answer 1

我认为一个相当大的缺点是，您必须为小型项目编写，管理和维护的额外代码量可能只是过度杀伤。

这完全取决于项目规模，最终项目的预期寿命和预算。有时候，“正确地做事”很有吸引力，做一些更“轻量级”的事情可能是正确的商业决策！

Answer 2

它往往会让一个没有经验的团队更长时间来构建3-层。这是更多的代码，所以更多的错误。我只是扮演魔鬼的拥护者。

Answer 3

即使这是一个小项目，我也会努力推动N级方法。如果您使用像codesmith + nettiers这样的ORM工具，您将能够快速设置项目并开发能够快速解决业务问题的代码。

当你开始一个新项目并且你花了好几天坐在纺车周围谈论如何构建“建筑”时，它会让我失望。您希望花时间解决业务问题，而不是解决其他人为您解决的问题。使用ORM（无论哪一个，只需选择一个并坚持下去）来帮助您获得初始牵引力将有助于您专注于项目的目标，而不会分散您试图解决“架构”问题的注意力。

如果在一天结束时，架构师想要采用一种项目方法，那么你没有理由不能创建一个带有BLL和DAL文件夹的app_code文件夹来分离现在的代码，这将有助于你稍后转到N层解决方案。

Answer 4

因为你希望功能能够将层分布到不同的物理层（我总是使用“tier”作为物理层，而“layer”作为逻辑层），你应该再考虑一下把所有东西都放在一个班级，因为如果你需要开始分发，你就会有重大的重构。

Answer 5

与任何抽象都会产生复杂性一样，做N层的复杂性应该是合理的，例如，N层实际上是否有益于系统？ 将成为最适合N层的小型系统，尽管其中很多都不会。

此外，即使您的系统目前还很小，您可能希望稍后添加更多功能 - 不会使用N层可能构成您的技术债务，所以你必须要小心。

Answer 6

唯一的缺点是复杂性，但实际上有多难添加一些域对象并绑定到它们的列表而不是使用数据集。您甚至不必创建三个单独的项目，您只需在Web应用程序中创建3个单独的文件夹，并为每个文件夹分配一个名称空间，如YourCompany.YourApp.Domain，YourCompany.YourApp.Data等。

最大的优势是拥有更灵活的解决方案。如果您开始将应用程序编写为以数据为中心的应用程序，将Web表单页面强烈耦合到数据集，那么随着业务逻辑的复杂性增加，您将在以后迁移到更多域中心模型时执行更多工作。

也许在短期内，您可以通过创建非常简单的域对象并从数据集中填充它们来专注于简单的解决方案，然后您可以根据需要向其添加业务逻辑，并根据需要构建更复杂的ORM，或使用nhibernate。