最好的 Delphi n 层低带宽技术是什么？
我需要在需要集中数据和文件存储系统（用于文档成像）但有多个分支机构且互连性相对较差的环境中部署Delphi应用程序。 我相信 3 层数据库应用程序是最好的方法，这样我就可以提供丰富的桌面体验和相对轻量的数据传输需求。 到目前为止，我已经简要了解了 Delphi Datasnap、kbmMW 和 Remobjects SDK。 看来 kbmMW 和 Remobjects SDK 使用的带宽最少。 是否有人有在具有大量用户的挑战性环境中部署这些技术的经验（我需要支持 700 多个用户）？ 谢谢！
I need to deploy a Delphi app in an environment that needs centralized data and file storage system (for document imaging) but has multiple branch offices with relatively poor inter connectivity. I believe a 3 tier database application is the best way to go so I can provide a rich desktop experience with relatively light-weight data transfer needs. So far I have looked briefly at Delphi Datasnap, kbmMW and Remobjects SDK. It seems that kbmMW and Remobjects SDK use the least bandwidth. Does anyone have any experience in deploying any of these technologies in a challenging environments with a significant number of users (I need to support 700+)? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
取决于您是否绑定到远程数据集。 如果您不受数据集限制，那么 SOAP 可能是一个不错的选择。 或者，我所做的是编写自己的协议，本质上类似于 SOAP。 这是在 SOAP 成为标准之前完成的，我很高兴我这样做了 - 这使您能够控制更多的数据流。 鉴于如果您的连接性较差，那么您将花费时间来支持它。 如果您支持的是您自己的代码，而不需要等待供应商，那就太好了。 （尽管 KBM 和 REM 被认为是相当不错的供应商。）
个人说明：文档成像应用程序中的 700 个用户由于连接不良而听起来很混乱。 把钱花在升级连接上，因为从长远来看它会更便宜。
Depends if you are tied to remote datasets. If you aren't dataset bound then SOAP would likely be a good choice. Or, what I've done is write my own protocol that is similar to SOAP in nature. This was done before SOAP was standard and I'm glad I did - this gives you the ability to control more of the flow of data. It's given that if you have poor connectivity then you will be spending time supporting it. It's very nice if it's your own code you are supporting versus having to wait on a vendor. (Although KBM and REM are known to be pretty good vendors.)
Personal note: 700 users in a document imaging application over poor connectivity sounds like a mess. Spend the money on upgrading connectivity as it'll be cheaper in the long run.
kbmMW 和 RO SDK 都提供二进制格式，它比 SOAP 格式更紧凑，特别是您正在处理文档。
RO sdk 似乎提供了更多 GUI 工具来帮助您完成服务。
另请看一下 RealThinClient SDK，它是一个轻量级远程处理框架。
但是无论您使用什么框架，您的工作设计都会使其变得更快或更慢，我有一些应用程序在慢速 128kb 线路上运行，并且它运行完美，没有任何用户抱怨，但我不会对文件进行大量传输。
Both kbmMW and RO SDK offer binary format, which is more compact than SOAP format,specially you are working with documents.
RO sdk seems to offer more GUI tools to help you doing your services.
Also give a RealThinClient SDK a look, it's a lightweight remoting framework.
But what ever framework you go with, your design of work will make it fast or slow, I have some applications working on slow 128kb lines, and it's working perfect without any user complain, but I don't do a large transfer for files.
要记住的一件事......问题不是用户数量，而是同时使用资源的用户数量。 如果可能的话，尝试开发“无状态服务器”应用程序，如果您发现必须向池中添加更多服务器来支持您的客户群，从长远来看，这将提供更大的灵活性。 n 层最困难的事情是扩展到第一台服务器之外......从一开始就计划好。 每个请求不应该知道有关先前请求的任何信息……或者至少该请求应该有一种传递上下文的方法，以便服务器可以在会话表或其他内容中查找它。
就我个人而言，我会推荐 RemObjects。 我用过，效果很好。
One thing to remember...its not the number of users, but the number of them using the resources at the same time that will be the issue. Attempt to develop your application "server stateless" if at all possible, this will allow greater flexibility in the long term if you find you have to add more servers to the pool to support your customer base. The hardest thing about n-tier is scaling beyond the first server...plan on that from the start. Each request should not know anything about a prior request...or at the very least the request should have a way of passing the context so the server can look it up in a session table or something.
Personally, I would recommend RemObjects. I have used it with good results.
我不知道它是否是最好/最有效的（很高兴你问这个问题！），但我使用 RemObjects SDK + DataAbstract 得到了很好的结果。 后者减少了很多管道细节的涉及，这很有帮助。 仍在实施，但到目前为止一切顺利。
I don't know if it's the very best / most efficient (glad you asked this question!), but I've had good results w/RemObjects SDK + DataAbstract. The latter made much of the plumbing details less involved, which was helpful. Still implementing, but so far so good.
如果您确实想要“低带宽”，请使用 BSD Sockets API - 这将使您完全控制发送的内容，并且您可以发送尽可能少的信息。 当然，那么您必须自己实现所有层，但是嘿 - 这仍然是一个选项：D
If you really wanna go "low-bandwidth" use BSD Sockets API - that'll give you full control over what's being sent and there you can send as little information as you want. Of course then you'll have to implement all the tiers yourself, but hey - that's still an option :D