我正在开发一个相对较小的 asp.net Web 应用程序，我想知道是否真的需要采用完整的 n 层架构。对于大小的想法；大约有20个数据库表。
过去，我使用了一种 2 层方法，其中业务逻辑和数据访问被组合到一个类库中，其中一个 asp.net Web 应用程序形成 UI 层，这似乎工作正常。
是否有阈值大小或一些经验法则，您应该在哪里使用 n 层？
问问题
1639 次
5 回答
14
它现在可能相对较小，但您认为它将来可能会增长吗？当然，您必须务实，但是如果您已经在单个程序集中自然地分离了关注点，那么将其拆分为两个或多个程序集是相当容易的。如果这些类本身结合了业务逻辑和数据访问，那么您将有更多的工作要做。但是，我认为在一个程序集中编写数据访问逻辑并在另一个程序集中编写业务逻辑（如果需要的话并行编写）比一开始就将它们全部编写在一个地方几乎没有更多的工作。
于 2009-02-05T19:37:24.037 回答
3
如果您预计会有任何形式的增长或变化，那么现在加强明确的层级将有所帮助。但是，如果这是您自己的项目，并且您不介意支付更改或紧密集成代码的成本，那么只需像一层一样破解它。
一切都与未来的成本有关。目前，随用随编程是迄今为止最便宜的，但不能很好地响应变化。使用层规划，会有前期成本，但它可以比第一种方法更好地处理更改和剥离整个层的实现。
因此，您的经验法则取决于谁将支付变更费用以及何时支付。
于 2009-02-05T19:38:39.667 回答
3
是的，这是值得的。您提出的是一起破解解决方案。我无法告诉你这给我带来了多少次痛苦和折磨。硬币的另一面是过度构建他们的解决方案的天文学开发人员。你也想避免这种情况。
简单点，构建你的三层，我建议你尝试 LINQ to SQL，它使构建 DAL 变得轻而易举，然后你可以专注于构建一个纤薄的 UI，以及一个可以处理繁重工作的 BLL。这样做不会花费您太多时间，并且以后可以进行单元测试。
于 2009-02-05T20:06:52.637 回答
1
是否有阈值大小或一些经验法则，您应该在哪里使用 n 层？
不是我知道的，但我会抛出这个：如果这个网络应用程序有可能增长（或更改后端）和/或其他人可能最终维护它，我会考虑使用 n层方法。
于 2009-02-05T19:46:57.123 回答
1
只要保持它可能。现在可能有点矫枉过正，但不要把自己写进不可能的情况。与从头开始重建相比，大规模重构将花费您更长的时间（可能就是这样，从头开始重建）。
我从事的最后一个项目（来晚了）是以打破层级的方式编写的，实际上是不可能的。数据逻辑与业务逻辑交织，与表示逻辑交织。在短期内，它和以往一样好，因为修复它需要几个月的时间。
把所有东西分开并不难，就像我之前说的，保持它可能。
于 2009-02-05T20:10:26.420 回答