0

对于这种情况，2 层是否是一个有效的选择：

  1. sql server 数据库
  2. 业务永远不会需要超过几百个通过 LAN 连接到共享数据库的同时连接

  3. 事实上（我相信）开发 2 层应用程序的工作量要少得多
  4. 通过 LAN 自动更新客户端程序
4

4 回答 4

1

2 层解决方案可能更容易开发，但如果应用程序具有任何规模和/或复杂性，则将更难维护。

如果这个应用程序对业务很重要并且在很长一段时间内到位，我认为您会发现花费在将您的表示、业务逻辑和数据访问分离到它们自己的层中的额外时间将在它得到回报时得到回报是时候修复问题、更改逻辑或扩展应用程序了。

这是您可能会得到与答案一样多的不同意见的问题之一。

于 2009-01-28T14:23:54.510 回答
1

一开始可能更容易开发，但我也认为，如果项目不是仅供内部使用的微不足道的工具，那么从长远来看，这会让你付出代价。

您是否需要 3 层应该取决于您要维护项目多长时间以及您稍后计划为它计划多少功能/更新。它还可能取决于您愿意接受（并修复）多少错误。IMO 3 层倾向于创建更稳定的软件。

于 2009-01-28T14:32:30.763 回答
0

这两个答案似乎几乎都在说 3 层是优越的解决方案是不言而喻的。也许

Rockford lhotka似乎在争论您应该选择 2 层，除非您的特定情况的成本效益分析支持 3 层。

他说 ：

作为一名优秀的架构师，您应该被拖着大喊大叫地为您的系统添加层级。

他认为安全性是唯一明显优于 3 层解决方案的领域。

他认为

更糟糕的是，边界增加了软件设计、网络基础设施、系统的可管理性和整体可维护性的原始复杂性。简而言之，应用程序中的层越多，处理的复杂性就越高——这直接增加了构建和维护应用程序的成本。

最后，关于可扩展性，我想知道，如果您在 ado 中使用断开连接的记录集进行数据访问，那么您是否默认拥有连接池，因此无论如何都具有高度的可扩展性？

于 2009-01-29T23:14:12.640 回答
0

抄自 Charles Williams 的《Professional Visual Basic 6 Databases》一书：-

2 层与 N 层

在 2 层和 n 层模型之间进行选择似乎是人们的想法。等式中有很多变量（包括偏好），没有一本书可以确定您的客户端-服务器模型的最佳结构。其中一些变量可以包括：

您选择的数据库服务器的灵活性和功能。今天的数据库服务器能够处理数百甚至数千个并发连接，而​​无需迁移到 3 层架构。

容纳服务器的 CPU 的强大功能和多功能性。CPU 越强大，服务器处理请求的任务就越快。

有多少吞吐量正在运行到服务器中，以及存在多少连续连接。您可能有很少或很多连接，每个连接可能会传递很少或很多请求。

经济因素。你愿意在你的系统上花多少钱。通常，n 层系统的开发和维护成本更高。如果您可以使用 2 层解决方案，您可以节省大量资金。

对我来说，这似乎表明除非您正在开发（非常流行的）基于 Web 的应用程序，否则 2 层可能是更合乎逻辑的选择。

于 2009-02-07T20:41:53.767 回答