使用 N 层解决方案是否有任何负面原因？

Question

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

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

Answer 1

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

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

Answer 2

缺乏经验的团队往往需要更长的时间来构建 3 层。代码更多，因此错误也更多。但我只是在扮演魔鬼的代言人。

Answer 3

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

当你开始一个新项目并花几天时间坐在旋转的轮子周围谈论应该如何构建“架构”时，这让我很伤心。您希望花时间解决业务问题，而不是解决其他人已经为您解决的问题。使用 ORM（哪一个并不重要，只需选择一个并坚持下去）来帮助您获得最初的牵引力，这将有助于您专注于项目的目标，而不会分散您尝试解决“架构”问题的注意力。

如果归根结底，架构师想要采用单一项目方法，那么您没有理由不能创建一个包含 BLL 和 DAL 文件夹的 app_code 文件夹来暂时分隔代码，这将帮助您转移到稍后 N 层解决方案。

Answer 4

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

Answer 5

与任何抽象都会产生复杂性一样，因此执行 N 层的复杂性应该得到适当的证明，例如，N 层实际上对系统有好处吗？那里 将要 是最适合与 N 层配合的小型系统，尽管其中很多不会。

此外，即使您的系统目前很小，您也可能希望稍后向其添加更多功能——而不是采用 N 层 可能 这对你来说构成了一种技术债务，所以你必须小心。

Answer 6

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

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

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