使用 Datasnap 构建真正的数据库应用程序
我使用 ADO 和 devexpress 在 D2010 中构建了一个广泛的 2 层应用程序。我想将其升级为使用 Datasnap 主要是为了向易受攻击的 SQL 服务器提供 HTTPS 通信，而不仅仅是 TCP/IP。我已经遵循了我能找到的所有 Datasnap 教程。我有 Cary Jensen 的 Delphi 深入：ClientDatasets。一切都很好，但是这些示例几乎没有用，因为在真正的数据库应用程序中，网格是通过将多个表连接在一起来填充的，而不是从单个表中填充的。这立即消除了客户端数据集的“自动解析”功能。即使建议的 beforeupdateevent 处理程序也无法在 datasnap 应用程序中工作，因为数据库只能由 datasnap 服务器访问。因此，在我看来，我必须在 datasnap 服务器上为我需要的每个插入/更新创建一个方法，然后将这些方法公开给客户端并根据需要从客户端调用它们，以请求 datasnap 服务器执行所需的操作更新/插入。这看起来工作量很大！
有没有更简单的方法来实现到 SQL Server 的 https 通信？
哦，如果您想知道，该应用程序已经是伪 3 层，因为网格连接到 TdxMemData，而不是直接连接到 TADOQueries。我自己处理所有插入/更新的方式与使用 TClientdatasets 时所需的方式相同。
I have built an extensive 2-tier application in D2010, using ADO and devexpress. I want to upgrade this to using Datasnap mainly to provide HTTPS communication instead of just TCP/IP to the vulnerable SQL server. I have followed all the Datasnap tutorials I could find. I have Cary Jensen's Delphi In Depth: ClientDatasets. All good and well, but the examples are pretty useless because in a REAL database application, grids are populated from joining multiple tables together and almost never from a single table. This obviates the "autoresolve" capability of clientdatasets right off the bat. Even the proposed beforeupdateevent handlers won't work in a datasnap application because the DB is only accessible to the datasnap server. So it seems to me I have to create a method on the datasnap server for EACH insert/update I am going to need, then expose those methods to the client and call them from the client as required to request the datasnap server to perform the required update/inserts. This seems like a lot of work!
Is there an easier way to implement https comms to a SQL Server?
Oh in case you're wondering, the application is already pseudo 3-tier in that grids are wired to TdxMemData, and never directly to TADOQueries. I handle all insert/updates myself in the same way that I would have needed to if I had used TClientdatasets.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您认为您的数据库容易受到攻击，请在使用 D2010 Datasnap 时三思。它非常非常脆弱。不要被 HTTPS 愚弄，在充分保护通道方面仍然缺少很多部分。例如，一旦您使用 Datasnap，SQL Server Windows 集成身份验证（基于 Kerberos...）就消失了。
有关完整说明，请参阅：为什么 Datasnap 2010 是一个玩具库。这当然是我的个人意见，但它是基于我自 Delphi 3 以来使用 Midas/Datasnap 的经验以及我当前有关 IT 安全的工作。
无论如何，你对插入/更新/删除的看法是错误的。您必须使用提供者的事件来在 datasnao 服务器端控制它们。它比在两层应用程序中处理它们要复杂一些，但您不需要为每个操作使用临时方法。
If you think your database is vulnerable think twice about using D2010 Datasnap. It is very, very vulnerable. Don't be fooled by HTTPS, there are still lot of pieces missing to fully protect the channel. For example once you use Datasnap, SQL server Windows integrated authentication (kerberos based...), is gone.
For a full explanation see: Why Datasnap 2010 is a toy library. It's of course my personal opinion, but is is based on my experience using Midas/Datasnap since Delphi 3, and my current work about IT security.
Anyway you're wrong about insert/updates/deletes. You have to use providers' events to control them on the datasnao server side. It's a bit more complex than handling them in a two-tier application, but you don't need ad-hoc methods for each operation.
[2016 年更新：2016 年的 DataSnap 在安全性和功能方面比撰写此问题时更加落后。我根本不建议在任何新设计中使用它。]
DataSnap 是构建多层（三层或更多）应用程序问题的解决方案。从包含客户端中所有业务逻辑的胖客户端通过 Internet 直接连接到 SQL 会出现许多众所周知的问题，其中包括业务逻辑发生更改后需要您立即更新所有客户端的事实。数据快照（或其他）中间层逻辑内部的中间层改进（业务逻辑更改）不会分发给每个客户端。客户端更精简，包含的业务逻辑也更少。其次，您自己构建的设计良好的数据快照“API”只会让您面临您自己创建的风险，而不是让您面临整套 MS SQL 漏洞。
坦率地说，失去来自胖客户端的 Kerberos 身份验证并不是放弃中间层想法的理由。我根本不明白 ldsandon 的观点。他是否提倡连接到互联网或 LAN 客户端并包含所有业务逻辑的两层应用程序架构，比多层应用程序“更安全”？
您的标题所暗示的隐含问题是无法回答且未定义的。 “真实”是什么意思？许多行业在自己的公司 LAN 内部署两层胖客户端。许多人发现在自己的 LAN 内使用中间层是有益的，并且许多人发现通过互联网运行的外部应用程序绝对不应该将 SQL 连接暴露给胖客户端，因此他们提供了某种“Web 方法” （SOAP、REST+JSON 等）架构。有人仔细指出，Data-Snap 并不是一个纯粹的“RESTful”架构，但它确实使用了 JSON，并且在设计上在很多方面都是 RESTful，尽管并不完全。
如果您不了解创建 DataSnap 是为了解决的问题，很容易认为 DataSnap 毫无价值，或者（或者，同样错误）某种灵丹妙药。它的存在有一个特定的目的，许多人发现对他们的发展需求有用。如果您打算承担制作中间层的工作，DataSnap 比 100% 完成它作为“滚动您自己的中间层”更容易，但它比没有中间层需要更多工作。
[2016 Update: DataSnap in 2016 is even more woefully behind in terms of security and features now than it was when this question was written. I do not recommend its use in any new designs at all, ever.]
DataSnap is a solution to the problem of building multi-tier (Three or more) applications. Directly connecting to SQL over the internet from a thick client that contains all the business logic in the client has many well-understood problems, including the fact that business logic changes then require that you update ALL your clients at once. A middle tier improvement (business logic change) that is inside your data-snap (or other) middle tier logic, is not distributed to each client. The clients are thinner, and contain less of the business logic. Secondly, a well designed data-snap "API" that you build yourself only exposes you to the risks that you create yourself, rather than exposing you to the entire set of MS SQL vulnerabilities.
Frankly, losing Kerberos authentication from your thick client, is not a reason to abandon the idea of a middle tier. I don't understand ldsandon's point at all here. Is he advocating a two-tier application architecture that connects to internet or LAN clients, and that contains all the business logic, as "more secure" than a multi-tier application?
The implicit question suggested by your title is unanswerable, and undefined. What does "real" mean? Many industries deploy two-tier thick clients inside their own corporate LANs. Many have found it beneficial to use a middle tier inside their own LAN, and many have found that external applications that run over the internet should definitely NOT be surfacing the SQL connectivity to thick clients, and so they provide some kind of "web method" (SOAP, REST+JSON, etc) architecture. It has been carefully pointed out that Data-Snap is not a Purely "RESTful" architecture, but it does use JSON, and is in many ways REST-ful in design, although not fully.
If you don't understand the problem that DataSnap was created to solve, it is easy to think DataSnap is worthless, or (alternatively, and equally wrong) some kind of silver bullet. It exists for a particular purpose, one that many people find useful for their development needs. If you intend to take on the work of making a middle tier, DataSnap makes it easier than to do it 100% as a "roll your own middle tier", but it is more work than not having a middle tier.