4

ADO と devexpress を使用して、D2010 で大規模な 2 層アプリケーションを構築しました。これを、脆弱な SQL サーバーへの TCP/IP だけでなく、主に HTTPS 通信を提供するために Datasnap を使用するようにアップグレードしたいと考えています。見つけたすべての Datasnap チュートリアルに従いました。Cary Jensen の Delphi In Depth: ClientDatasets があります。すべてうまくいっていますが、例はほとんど役に立ちません。なぜなら、REAL データベース アプリケーションでは、グリッドは複数のテーブルを結合することによって生成され、単一のテーブルから生成されることはほとんどないからです。これにより、すぐに clientdatasets の「自動解決」機能が不要になります。DB は datasnap サーバーにしかアクセスできないため、提案された beforeupdateevent ハンドラーでさえ datasnap アプリケーションでは機能しません。したがって、必要な挿入/更新ごとにdatasnapサーバーでメソッドを作成し、それらのメソッドをクライアントに公開し、必要に応じてクライアントから呼び出して、datasnapサーバーに必要な実行を要求する必要があるようです更新/挿入。これは大変な作業のようです！

https 通信を SQL Server に実装する簡単な方法はありますか?

ご参考までに、グリッドが TdxMemData に接続されており、直接 TADOQueries に接続されていないという点で、アプリケーションはすでに疑似 3 層になっています。TClientdatasets を使用した場合と同じ方法で、すべての挿入/更新を自分で処理します。

4

2 に答える 2

6

データベースが脆弱であると思われる場合は、D2010Datasnapの使用についてよく考えてください。それは非常に、非常に脆弱です。HTTPSにだまされないでください。チャネルを完全に保護するために、まだ多くの部分が欠落しています。たとえば、Datasnapを使用すると、SQLサーバーのWindows統合認証（Kerberosベース...）はなくなります。

完全な説明については、「Datasnap2010がおもちゃ図書館である理由」を参照してください。もちろん私の個人的な意見ですが、これはDelphi3以降のMidas/ Datasnapの使用経験と、ITセキュリティに関する現在の作業に基づいています。

とにかく、あなたは挿入/更新/削除について間違っています。datasnaoサーバー側でプロバイダーのイベントを制御するには、プロバイダーのイベントを使用する必要があります。2層アプリケーションで処理するよりも少し複雑ですが、操作ごとにアドホックなメソッドは必要ありません。

于 2011-10-16T15:18:55.593 に答える
4

[2016 年の更新: 2016 年の DataSnap は、この質問が書かれたときよりも、セキュリティと機能の面でさらに遅れをとっています。新しいデザインでの使用はまったくお勧めしません。]

DataSnap は、多層 (3 つ以上) のアプリケーションを構築する際の問題に対するソリューションです。クライアントにすべてのビジネス ロジックを含むシック クライアントからインターネット経由で SQL に直接接続することには、ビジネス ロジックの変更後にすべてのクライアントを一度に更新する必要があるという事実を含め、多くのよく知られている問題があります。データ スナップ (またはその他の) 中間層ロジック内にある中間層の改善 (ビジネス ロジックの変更) は、各クライアントに配布されません。クライアントはシンナーであり、含まれるビジネス ロジックは少なくなります。第 2 に、適切に設計されたデータ スナップ "API" を自分で作成しても、MS SQL の脆弱性のセット全体にさらされるのではなく、自分で作成したリスクにさらされるだけです。

率直に言って、シック クライアントから Kerberos 認証を失うことは、中間層のアイデアを放棄する理由にはなりません。ここでldsandonのポイントがまったくわかりません。彼は、インターネットまたは LAN クライアントに接続し、すべてのビジネス ロジックを含む 2 層アプリケーション アーキテクチャを、多層アプリケーションよりも「安全」であると主張していますか?

あなたのタイトルが示唆する暗黙の質問は、答えることができず、未定義です。「本物」ってどういう意味？多くの業界では、自社の企業 LAN 内に 2 層のシック クライアントを展開しています。多くの人が、独自の LAN 内で中間層を使用することが有益であることを発見しました。また、多くの人が、インターネット上で実行される外部アプリケーションが SQL 接続をシック クライアントに明らかにすべきではないことを発見したため、ある種の「Web メソッド」を提供します。 (SOAP、REST+JSON など) アーキテクチャ。Data-Snap は純粋に「RESTful」なアーキテクチャではなく、JSON を使用しており、完全ではありませんが多くの点で RESTful な設計になっていることが慎重に指摘されています。

DataSnap が解決するために作成された問題を理解していない場合、DataSnap は無価値である、または (あるいは、同じように間違っている) ある種の特効薬であると考えるのは簡単です。特定の目的のために存在し、多くの人が開発のニーズに役立つと考えています。中間層を作成する作業を引き受ける場合、DataSnap を使用すると、「独自の中間層を作成する」ように 100% 実行するよりも簡単になりますが、中間層がない場合よりも手間がかかります。

于 2011-10-16T17:32:39.120 に答える