2

ユーザー インターフェイス用の複数のプラットフォーム (つまり、ASP.net webapp、Windows アプリケーション、そしていずれはモバイル アプリ) とバックエンド データベース用の複数のプラットフォーム (つまり、SQL Server、XML、Oracle) を組み込むエンタープライズ アプリケーションを構築しています。さらに必要なことは、これらのバックエンド DB が集中化されて Web 経由でアクセスされるか、クライアント コンピューター上でローカライズされ、場合によっては中央サーバーと同期されることです。

ユーザー インターフェイス レイヤーとデータ レイヤーを抽象化して、さまざまな UI と DB のさまざまな選択肢の間でプラグアンドプレイの適応性をより簡単に作成できるようにする方法について、誰かアドバイスをいただけますか? たとえば、あるケースでは、インターネットを介して中央サーバーで実行されている Web アプリがあり、Windows アプリを介してローカライズされたコピーを実行しているリモート マシンがある場合があります。スケジュールされた間隔で、すべてのマシンを同期して、すべてのマシンがほぼリアルタイムのデータを取得できるようにする必要があります。

また、関連するさまざまな接続文字列を処理するためのアドバイスも必要です。これにより、1 つのアプリで変更する必要がある設定は「ローカル」または「リモート」だけになり、必要な接続文字列が決定されます。

4

2 に答える 2

5

プレゼンテーション レイヤーの抽象化は、n 層アーキテクチャのコツをつかめば、かなり簡単な概念です。「ドメインロジック」と「アプリケーションロジック」を区別することに集中してください。ドメイン ロジックは異なるプラットフォーム間で共通であり、アプリケーション ロジックはプラットフォーム固有です。たとえば、データ検証はドメイン ロジック (フロントエンドで実行できると便利ですが、これにより複雑になりますが、ここでは私と一緒に作業します...) と、何らかのアクションが適用された後にリダイレクトする URL を決定します。論理。どのプラットフォームでも使用できるレベルでドメイン ロジックを配置し、ドメイン レイヤーにアプリケーション ロジックを配置しないようにしてください。

あなたの質問の残りの半分は、あなたのより大きな焦点のように思えますが、2 つの異なる本質的な質問を識別できるので、ここで明確化をお願いしたいと思います。

  1. データベースの独立性という「聖杯」を目指していないことを願っています。これは常に設計段階で打ちのめされる高い目標であり、ほとんどの場合、ほとんどの場合、必要ありません。

    それが目的ではない場合は、どのオブジェクトがどの永続媒体に格納されているかを知っておく必要があることをお勧めします。また、柔軟性の複雑さを避け、垂直パスを単純な方法でコーディングする必要があります。できるだけ。IEは、「将来のある時点で」SQL Serverにデータを入れることができるように、データをOracleに格納するビジネスクラスに余分なものをコーディングしません。(ラウンドロビンでデータベースの独立性に戻りましたよね?)

  2. 特定のプラットフォームのパフォーマンスを向上させるためにデータをローカルにキャッシュするという問題は、それらのプラットフォームに固有のものであり、スマート クライアントと MS P&P チームのキャッシュ フレームワーク/ガイダンスを調べることをお勧めします。私はここ 2 年間、Web 関連の作業だけに専念してきましたが、2006 年 5 月の時点ではかなり順調でした。その間、彼らは Smart Client に関する多くの作業を行っていました。

于 2008-10-25T07:27:02.257 に答える
1

プロバイダー モデルを使用して、アプリケーションでデータベース接続を確立する方法を検討します。

Microsoft Data Application Block で提供されている例と詳細を確認することから始めます。これは、その一部を理解するのに役立つと思います。

于 2008-10-24T19:11:57.857 に答える