我已经使用了所有描述的技术,以及更多与 D3 交互的技术。我同意@Glenn 并将添加...我了解您正在远离.NET。没关系,你不需要它。但考虑到大多数 LAMP 实现将 DBMS 服务器与 Web 服务器分开。该拓扑在层之间引入了短暂的延迟,但在您想要使用多个 Web 服务器或多个数据库时将它们解耦 - 即使使用 D3 / MV 也是一种常见的拓扑。
我有一个客户端,我们有一个基于 Linux 的 Java/Grails 前端,所有数据查询都通过一个从应用程序逻辑中抽象出来的优雅的数据提供者类进行过滤。它使用我用 Java 编写的 Web 服务调用,调用 .NET Web 服务。该服务很容易生成/修改,就像来自 WSDL 的客户端一样。从那里 IIS 通过 mv.NET 向 D3 进行入站查询,此时 D3 DBMS 是在 Linux 还是 Windows 中并不重要。我的 Web 服务可以很容易地在带有 Java 的 Linux 中使用,但它会缺少池机制 - 见下文。
如果您想要所有 Linux,那么您可以使用 MVSP Java 库。TigerLogic(现在被 Rocket Software 收购)几个月前致力于 MVSP 的 PHP 绑定。我的一个客户没有等待,而是围绕 mv.NET 创建了一个 PHP 包装器,尽管 MVSP 很简单。因此,生成的应用程序本质上是 LAMP,但具有 M = 多值。我也写过这样的代码——我们可以用任何语言编写一个封装器,它公开有用的 API 并抽象连接方法和操作系统依赖项。换句话说,我们想要使用什么语言或涉及什么操作系统并不重要。这部分相当琐碎,以后可能会更改。最好专注于应用程序而不是通信。
您也可以离开菜单,可以说,围绕操作系统级 d3tcl 命令创建自己的 Java/PHP 包装器,该命令是 d3 可执行文件的脚本/包装器。这允许您自己打开连接并传入命令。
无论您选择什么选项,您都需要考虑打开和关闭 DBMS 连接是一个缓慢的过程。您不想围绕每个数据请求编写登录脚本。您确实希望打开一个连接并保持该连接持久打开,而您的客户端代码会根据需要访问和释放该持久连接。这就是我们喜欢 mv.NET 和 FlashCONNECT 的原因。使用 MVSP 和其他机制,您需要创建自己的持久性模型。您还需要管理一个连接资源池——当您同时获得 10 个查询时会发生什么,或者只有一个短一个又一个长的查询?您不想备份查询,不想拒绝或超时连接,也不想为每个客户端启动连接。您确实需要适当数量的 DBMS 会话等待入站连接。MV。
就我个人而言,我会回避 FlashCONNECT。我在那里进行了最初的开发和测试以及多年的最终用户实施。它不像其他选项那样广泛使用,对于那些不熟悉其他选项的人来说,它更像是一种工具。如果您在谈论 Java,那么您可能不倾向于使用 FlashCONNECT。也就是说,如果您的开发人员不熟悉 D3 之外的任何内容,那么 FlashCONNECT 对他们来说是一个不错的服务器端工具,而其他人则专注于使用其他技术的客户端。每个人都应该使用他们最好的技能。
最后,(已经?)如果有人不熟悉外部技术,并且更熟悉 D3,那么存在其他选项,例如 DesignBAIS 和 Viságe,主要是消除通信负担,并允许开发人员处理客户端功能并返回 - BASIC 中的结束规则。
我在博客上讨论了所有这些主题以及移动和电话。
高温高压