11

Firebird（ストアドプロシージャ、ビューなど）に強く結びついている比較的大きなアプリケーションがあります。現在、追加のデータベースをサポートするための多くのリクエストが寄せられています。また、多くの機能をクライアントからサーバーに移動したいと考えています。

今は、3（4）層アーキテクチャに移行する良い機会のようです。DataSnap2009とRemObjectsSDK/DataAbstractについてはすでに見てきました。どちらも仕事をしているように見えますが、注意すべき長所/短所はありますか？他に推奨できるフレームワークはありますか？

乾杯、ポール

4

5 に答える 5

4

Components4Developers の KBM Middleware コンポーネントを使用することをお勧めします。少し学習曲線がありますが、それらは非常に柔軟で、実際の状況での使用に耐えます.

ユーザーからのコメント ( http://www.components4programmers.com/usercomments/commentfromapowerusertoaquestion.htm )

于 2009-02-13T09:16:42.453 に答える
4

新しいフレームワーク (RM、DS、kbmMW など) を使用してアプリケーションをマルチティアに変更すると、アプリケーション アーキテクチャに多くの変更が加えられます。データベース、次のような他の製品と

DevArtの UniDac (直接接続のデータベースに最適なコンポーネント)。 AnyDac (RemObjects を提供している同じ会社から 。SqlDirect (9 MajorDB と ODBC もサポートしています) 。ZeosDB (オープン ソース)。

上記のコンポーネントのいずれかを使用すると、ほとんどの主要なデータベースがサポートされますが、多くの変更を行う必要はありません。場合によっては、古いデータベース コンポーネントを新しいコンポーネントに置き換えたり、プロパティの一部を変更したりするだけです。

ただし、多層に変更すると、サポートされるデータベースが増えるだけでなく、ビジネス ロジックがプレゼンテーション レイヤーから分離されるため、Web インターフェイスやスマート デバイスなどのアプリケーションのプレゼンテーション レイヤーを増やすことができます。

しかし、多層アーキテクチャで最も重要なことは、他の言語を使用してクライアント アプリケーションを作成するなどの他の利点に加えて、使用しているデータベースが接続を処理できる以上に拡張できるスケーラブルなシステムを使用できることです。

于 2009-02-13T19:49:34.697 に答える
3

多層アプリケーションに移行するプロセスでは、言語/テクノロジーに依存しない、レイヤー間のトランスポートプロトコルの使用を検討できます（Webサービスのように（remobjectsはそれをサポートしていると思います））。

これにより、後でレイヤーの再実装が簡単になる可能性があります（後で、browser / java / silverlightで別のバージョンのクライアントアプリケーションを作成する必要がある場合など）。

于 2009-02-13T08:45:35.167 に答える
1

ミッドウェアを調査することもできます http://www.overbyte.be/frame_index.html

于 2009-04-13T19:39:17.090 に答える
1

多層アーキテクチャについては、メッセージ指向のミドルウェアもチェックすることをお勧めします。

メッセージ指向のミドルウェアを使用すると、ピアツーピアまたはパブリッシュ/サブスクライブ通信モデルを使用して、クロス言語およびクロスプラットフォームのアプリケーション統合を実装できます。メッセージング システムは疎結合で、非同期であり、信頼性があります。たとえば、JBoss などの Java(tm) アプリケーション サーバーのコア コンポーネントです。

Firebird については、最近、Firebird データベース イベントの置き換え、その制限、およびメッセージ ブローカー ベースのソリューション (オープン ソースとして利用可能) に置き換える方法に関するブログ記事を書きました。

(免責事項: 私は、オープン ソース メッセージ ブローカー用の Delphi および Free Pascal クライアント ライブラリの開発者です)。

于 2013-03-17T15:33:52.917 に答える