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

时间:2009-01-28 14:00:59

标签: sql-server database architecture 2-tier

2层是这种情况的有效选择:

  1. sql server database
  2. 业务永远不会需要超过几百个同时连接 到LAN上的共享数据库
  3. 事实上(我相信)开发2层的努力要少得多 应用
  4. 通过LAN自动更新客户端程序

4 个答案:

答案 0 :(得分:1)

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

如果这个应用程序对业务很重要并且在相当长的时间内到位,我认为你会发现将表示,业务逻辑和数据访问分离到他们自己的层中所花费的额外时间将是当需要修理,修改逻辑或扩展应用程序时,我们会回复。

这是其中一个问题,你可能会得到尽可能多的不同意见。

答案 1 :(得分:1)

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

您是否需要3层应取决于您要维护项目的时间以及您稍后计划的功能/更新数量。它可能还取决于您愿意接受(和修复)的错误数量。 IMO 3层倾向于创建更稳定的软件。

答案 2 :(得分:0)

这两个答案似乎几乎都说三层是卓越的解决方案是明智之举。也许

Rockford lhotka似乎在争论你应该采用2层,除非成本效益 对你的特殊情况的分析有利于3层。

他说:

  

作为一名优秀的建筑师,你应该拖着踢,尖叫着为你的系统添加层。

他建议的安全性是三层解决方案明显优越的唯一领域。

他辩称

  

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

最后,关于可伸缩性,我想知道如果你在ado中使用断开连接的记录集来进行数据访问,那么你是否确实默认使用连接池,因此无论如何都具有高度的可伸缩性?

答案 3 :(得分:0)

复制自Charles Williams的专业Visual Basic 6数据库: -

  

2层对比N层

     

在2层和n层之间进行选择   模特似乎是人们的'   头脑。变量太多了   将因子纳入等式(包括   偏好)没有一本书可以   确定最适合您的结构   客户端 - 服务器模型。其中一些   变量可以包括:

     
    

所选数据库服务器的灵活性和强大功能。今天的     数据库服务器是能够的     处理数百甚至数千     并发连接没有移动     到3层架构。

         

容纳服务器的CPU的功能和多功能性。越厉害     CPU越快,服务器就越快     处理所请求的任务。

         

服务器正在运行多少吞吐量以及连续多少吞吐量     存在联系。你可能很少或     许多连接和每个连接     可能会传递一些或多个请求。

         

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

  

对我而言,这似乎表明,除非您正在为(非常受欢迎的)基于Web的应用程序开发,否则2层可能是更合乎逻辑的选择。