【发布时间】:2009-07-06 11:41:53
【问题描述】:
对于同时具有 Web 和桌面客户端版本的应用程序:
- 对于需要访问 SQL Server 的桌面客户端,最佳做法是什么?
- 从应用程序连接到数据库与使用 Web 服务相比有什么好处?
- 哪一种提供更好的安全性?
- 一种与另一种需要哪种类型的范围(企业 Intranet 与 Web 应用程序等)
- 在平台上选择时是否还有其他需要考虑的因素?
【问题讨论】:
标签: c# sql web-services
对于同时具有 Web 和桌面客户端版本的应用程序:
【问题讨论】:
标签: c# sql web-services
一般的经验法则如下:
【讨论】:
需要访问 SQL Server 的桌面客户端的最佳做法是什么?
如果您使用的是本地 SQL Server,则直接访问数据库。如果客户端必须在另一个系统上使用 SQL 数据库,则首选使用 Web 服务来获得额外的保护以及拥有应该能够处理多个用户的业务层的额外优势。
从应用程序连接到数据库与使用 Web 服务相比有什么好处?
通过 Web 服务连接总是会慢一些,并且对数据库的修改会更难添加到整个系统中。 (基本上,这意味着您需要创建新版本的 Web 服务,同时维护旧的 Web 服务以实现向后兼容性。)
哪一个提供更好的安全性?
网络服务的使用往往更安全,尽管安全性通常更多地是人的问题而不是软件问题。但是通过用户和数据库之间的网络服务,与数据库的连接更加安全,因为用户不能直接访问它。 (您通过 Web 服务提供的功能除外。)当客户端和数据库位于同一系统上时,这一点没有实际意义,因为这样用户可以获得完全访问权限。
一个和另一个需要什么类型的范围(企业 Intranet 与 Web 应用程序等)
Web 服务更适合客户端-服务器应用程序,用户不应直接访问数据库。否则,直接数据库连接只会提高性能。 创建 Web 服务时,首先编写一个通用(类)库,该库将为 Web 服务提供功能。围绕这个(业务)库创建一个 Web 服务,将重要的方法暴露给外界。任何网站都可以直接调用这个库而不使用网络服务,尽管您总是可以选择让网站代码通过网络服务访问数据。 即使你只是创建一个带有本地数据库的桌面应用程序,编写一个具有访问数据库逻辑的业务库也只是一件非常好的事情。您的客户可以直接或通过网络服务调用此业务库,具体取决于您的需要。
在平台上选择时还有其他需要注意的事项吗?
主要是您愿意用于设置的硬件数量。如果您有能力设置一个数据库服务器,一个单独的 Web 服务用于服务,第三个用于您的网站,有十几个客户端系统,那么您可以选择最分层的版本,客户端和网站都在其中调用调用数据库的 Web 服务。但是,如果一切都需要在单个系统上运行,那么只需坚持应用程序和业务层/库即可。
不过,从单个用户的角度来看,添加层会降低性能。但是,使用多个层可以提高整体性能,因为资源在多个用户之间得到了更好的分配。
【讨论】:
我会保持简单并尽量减少层数。层具有成本效益、引入复杂性并需要在更多位置进行更改。
所以,如果应用程序和 Sql Server 之间的网络连接是打开的(通常是 tcp 端口 1433),我会使用 Sql 连接。
【讨论】:
鉴于上下文,客户端访问数据库可能存在很大的安全问题。它需要授予用户对数据库的访问权限,或者创建一个服务帐户。让用户直接访问数据库会带来风险。这两种方法都为利用桌面 dll 连接到应用程序上下文之外的数据库打开了大门(我多次看到所有功能操作都使用公共数据访问类的情况。当然,这些组件初始化所有连接信息. 基于反射的访问使得访问受保护或私有方法变得很容易,除非您声明安全特权)。
Web 服务公开了不公开任何基于 sql 的操作的函数式操作。这不仅更安全,而且将您的客户端从您的数据存储实现中抽象出来。
同样,这取决于您的上下文。不过,在 Enterprise/ISV 领域,这通常是一个很大的禁忌。
【讨论】:
如果您可以从桌面访问数据库,那么您应该这样做。
您有多种客户。这意味着您的应用程序应该有多个层。 这并不意味着您需要多层。
如果您的层必须通过防火墙传输数据或者您拥有多种技术,则可能需要多层。
【讨论】:
我做混合动力车。可以对表执行只读操作的受限用户直接访问数据库。具有可以执行写入功能的高权限数据库用户的 Web 服务。业务规则内置于 Web 服务中(审计试验、权限检查等)
直接的数据库访问使我更容易开发报告,从客户端应用程序访问查找值。
【讨论】: