1

许多应用程序使用以下模型：

  1. 浏览器或其他客户端与应用服务器交互。
  2. 应用程序服务器（Web 服务器或 RPC 服务器）与数据存储服务器（SQL 服务器或非 SQL 存储）交互。

对于 Internet 应用程序，他们需要应用程序服务器，因为它们必须在数据服务器上保留简单的功能以提高性能。但我看不出他们为什么需要Intranet上的应用程序服务器。

例如，我们可以开发一个直接连接到 PostgreSQL 服务器的 Adob​​e AIR 应用程序吗？我想我们可以部署一个有很多存储过程并设置严格权限的中心 PostgreSQL 服务器，并让 Adob​​e AIR 应用程序仅通过调用存储过程来获取（和修改）数据。

为什么大多数应用程序不选择更简单的解决方案？

4

3 回答 3

3

一般来说，没有理由不能让独立的应用程序直接与 PostgreSQL 服务器对话。一些应用程序这样做，它工作正常。

我对 Adob​​e AIR 不够熟悉，无法说出在这种情况下是否可行。原则上，如果你能得到一个PostgreSQL驱动，或者你可以使用TCP套接字编写自己的驱动程序（PostgreSQL网络协议在官方文档中有详细记录），你当然可以直接连接。

话虽这么说，在终端客户端和数据库服务器之间有一种应用服务器形式并不是纯粹为了性能。

基于 Web 的开发允许 SQL 查询由服务器控制。您不是公开完整的 SQL 访问权限，而是公开客户端可以使用的功能。如果您稍后需要调整查询（错误、数据结构更改等），您可以在应用程序服务器上集中执行此操作，而无需为每个用户部署新版本的客户端。

当然，你可以像这个用户服务器编程那样直接做一些抽象，但这并不适合所有的应用程序。这可能取决于您的应用程序需要哪些其他功能，例如，如果它需要使用以另一种语言编写的库。您可以使用一些过程语言绑定，但它并不总是合适的：例如，pl/Python 是一种“不受信任的”语言（可能会导致安全问题），而 pl/Java 需要一个外部插件。

此外，如今并非所有应用程序最终都保留给 Intranet 使用。当您开始设计应用程序时，通常不要将自己限制在 Intranet 的使用范围内。

于 2012-10-19T09:11:45.057 回答
1

我最初是从直接访问设计开始的，很快发现迁移到我通过 Web 服务与数据库通信的应用程序服务器很有用。原因包括：

  • 当您通过 HTTP 等无状态协议与数据库通信时，处理数据库重启、本地连接丢失、客户端 IP 地址更改等要容易得多。对于远程工作者来说，这更是一个问题。

  • 事务在服务器端事务方法中明确划分和隔离（我使用 EJB3 和容器管理事务）

  • 添加新客户端（如手机应用程序）要容易得多，因为它们可以共享更多代码和业务逻辑。数据库中的存储过程非常有用，但可能会受到限制并且有时会令人沮丧。

  • 一些工具/语言没有直接与 PostgreSQL 对话的内置工具，但可以轻松地与具有 XML 或 JSON 请求/响应格式的 RESTful Web 服务对话。

  • 如果您只处理单个应用程序服务器连接池，则数据库管理员会更容易

主要的缺点当然是额外的层意味着额外的工作和额外的维护。

于 2012-10-20T02:15:16.707 回答
1

你可以，但是...

  • 浏览器语言/库往往缺乏对数据库的支持
  • 当有人想远程使用这个应用程序时会发生什么？

如果您不是在谈论基于浏览器的应用程序，那么这正是许多人所做的。有大量已安装的传统客户端应用程序直接或通过包装器（odbc/jdbc）与后端数据库通信。

于 2012-10-19T09:10:31.170 回答