使用 N 层解决方案是否有任何负面原因？ [关闭]答案

【问题标题】：Are there any negative reasons to use an N-Tier solution? [closed]使用 N 层解决方案是否有任何负面原因？ [关闭]
【发布时间】：2010-09-05 13:46:36
【问题描述】：

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

使用这种架构有什么缺点吗？专业人士的做法是将代码与数据分离，让类对象远离您的代码，等等。

【问题讨论】：

标签： architecture n-tier-architecture

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

因为您想要能够将层分布到不同物理层的能力（我总是将“层”用于物理层，而“层”用于逻辑层），您应该三思而后行将所有内容放在一个类中，因为如果或当您确实需要开始分发时，您需要进行重大重构。

【讨论】：

【解决方案3】：

与任何抽象都会产生复杂性一样，因此应适当证明执行 N 层的复杂性是合理的，例如，N 层实际上是否有益于系统？会有一些小型系统最适合 N 层，尽管其中很多不会。

此外，即使您的系统目前很小，您也可能希望稍后为其添加更多功能 - 不采用 N 层可能对您而言构成某种技术债务，所以你必须小心。

【讨论】：

【解决方案4】：

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

当您开始一个新项目并且花费数天时间坐在纺车上谈论应该如何构建“架构”时，这让我很生气。您希望花时间解决业务问题，而不是解决其他人为您解决的问题。使用 ORM（其实并不重要，只需要选择一个并坚持下去）来帮助你获得初步的牵引力，这将有助于你专注于项目的目标，而不是分散你试图解决“架构”问题的注意力。

如果最终架构师想要采用单一项目方法，那么您没有理由不能创建一个带有 BLL 和 DAL 文件夹的 app_code 文件夹来分隔代码，这将对您有所帮助稍后移至 N 层解决方案。

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

缺乏经验的团队往往需要更长的时间来构建 3 层。代码越多，错误就越多。不过，我只是在扮演魔鬼的拥护者。

【讨论】：