2 层是否是这种情况的有效选择答案

【问题标题】：Would 2 tier be a valid choice for this scenario2 层是否是这种情况的有效选择
【发布时间】：2009-01-28 14:00:59
【问题描述】：

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

sql server 数据库
业务永远不需要超过几百个同时连接通过 LAN 到共享数据库
事实上（我相信）开发 2 层的工作量要少得多
应用
通过 LAN 自动更新客户端程序

【问题讨论】：

标签： sql-server database architecture 2-tier

【解决方案1】：

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

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

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

【讨论】：

好吧，实际上 Rockfork Lhotka（见下面的链接）似乎同意你的观点，将应用程序划分为层是好的，他以不同的方式定义层和层。不同的层可以容纳在同一个物理层内。
@kjack：对。我可能应该更好地区分逻辑层和物理层。

【解决方案2】：

一开始可能更容易开发，但我也认为，如果项目不是仅供内部使用的微不足道的工具，从长远来看它会花费你。

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

【讨论】：

我想我真正想知道的是，在使用访问作为后端的大约 10 台计算机的网络中表现良好的 2 层解决方案在 100/500/1000 的网络中表现如何只需将数据库更改为 sql server 的计算机。
客户端软件自动寻找新版本，第一个更新自己的客户端然后更新数据库版本。因此，正在进行的开发实际上仅限于对客户端程序的增强。根本没有服务器程序，也没有中间层。

【解决方案3】：

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

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

他说：

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

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

他认为

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

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

【讨论】：

【解决方案4】：

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

2 层与 N 层

在 2 层和 n 层之间进行选择模型似乎是人们身上的东西头脑。有这么多变数因素到方程（包括偏好）没有一本书可以确定最适合您的结构客户端-服务器模型。其中一些变量可以包括：

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

服务器所在 CPU 的强大功能和多功能性。越强大 CPU 越快，服务器将越快处理请求的任务。

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

经济因素。你愿意在你的系统上花多少钱。通常，n 层系统将花费更多的开发和维护。如果你可以使用 2 层解决方案可以省很多钱。

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

【讨论】：