エンタープライズアプリケーションでのデータ接続層とプレゼンテーション層の抽象化

Question

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

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

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

Answer 1

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

あなたの質問の残りの半分はあなたのより大きな焦点のように見えますが、ここでいくつかの明確化を求めたいと思います。

1. 「聖杯」に向かないことを願っています。データベースの独立性。これは常に、設計段階で高く評価される目標であり、ほとんど常に、ほとんど常に必要ではありません。

   それが目的ではない場合、どの永続オブジェクトにどのオブジェクトが保存されているかを知っておく必要があることをお勧めします。柔軟性の複雑さを避け、まっすぐに垂直パスをコーディングする必要があります。可能な限りマナーを転送します。 IEは、データをOracleに格納するビジネスクラスに余分なものをコーディングしないで、「将来のある時点で」SQL Serverにデータを配置できるようにします。 （ラウンドロビンでデータベースの独立に戻りましたよね？）

2. 特定のプラットフォームのパフォーマンスを向上させるためにデータをローカルにキャッシュするという問題は、それらのプラットフォームに固有のものです。スマートクライアントと、MS P＆amp; Pチームのキャッシュフレームワーク/ガイダンスを検討することをお勧めします。私はここ数年、ウェブ関連の仕事に専念してきましたが、2006年5月にはかなり良かったです。その間、彼らはスマートクライアント関連の仕事をたくさんしてきました。

Answer 2

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

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