0

次の実装で使用するのに最適なデザイン パターンは何か知りたいです: Web サイトから画像をダウンロードして背景として設定する小さなアプリケーションを作成しています。

Web サイトと連携して XML ファイルをダウンロードし、このリモート サーバーでホストされているBackground.xml別のファイル ( ) もダウンロードしたいと考えています。Background.bmpファイルはビットマップで、XML はビットマップに関するメタデータです。ファイルをダウンロードしたら、背景として設定したいと思います。ファイルダウンロードコードと背景設定コードを分けたいのですが、どのデザインパターンを使えばいいのかわかりません。

これは、フォームがプレゼンテーション レイヤー、バックグラウンド セッター/XML パーサーがビジネス レイヤー、ダウンローダーがデータ レイヤーである典型的なプレゼンテーション/データ/ビジネス アプリケーションのようです。しかし、データベースではなく Web サイトからアクセスするため、実際のデータ アクセスにどのデザイン パターンを使用するかはわかりませんでした (したがって、DAO はおそらくこれには適していません)。ウィキペディアでデザインパターンも購入しましたが、何も正しくないようです。これは、MVC を使用できるものですか?

データレイヤー

public class DataLayer {
    public void DownloadFile() { 
        // download the file from http
    }
    public void GetXmlMetaData() { }
}

ビジネス層

public class BusinessLayer {
    private static BusinessLayer m_instance = new BusinessLayer();  
    public static Instance BusinessLayer { get { return m_instance; }
    private BusinessLayer() { }

    public void SetNewWallpaper() { 
        // download the file from data layer
        // set it as the background
    }
    public String GetWallpaperInfo() { return String.Empty; }
}

プレゼンテーション層

public class PresentationLayer {
    public void HandleButtonClick(Object sender, EventArgs e) {
        BusinessLayer.Instance.SetNewWallpaper();
    }
}

データ アクセス部分をバックグラウンド設定ロジックから分離するにはどうすればよいですか?

4

2 に答える 2

1

次の実装で使用するのに最適な設計パターンは何か知りたいです

何を基準に？ファイルをダウンロードして X を実行することは、航空機のメンテナンスおよび部品追跡システムを構築することと同じではありません。複雑さ、ソフトウェアのライフサイクル、チームの規模、予算、時間枠、すべてが「最善のアプローチ」に影響を与えます

どのソフトウェア設計原則を適用する必要があるかがわかれば、それはより簡単に適切な位置に収まります。

ファイルのダウンロードコードと背景設定コードを分けたいのですが、どのデザインパターンを使えばいいのかわかりません。

なんで？はい、これは良い習慣ですが、分離する理由があります。バグを減らし、コードの再利用を増やし、より良い単体テストを促進し、依存関係を取り除き、メンテナンスを容易にし、分離します...次のことができます:

a) すべてのコードを 1 つのメソッドに入れるのは極端です。
b) クラスで多くのメソッドを使用します。a レベルアップ
c) 次のステップでプロジェクト内のクラスを分離します。Basic OO
d) ソリューションで個別のプロジェクトを作成します。より多くの設計パターン
e) 通信する個別のソリューションを構築します。もう一方の極端。

設計原則を適用することを優先するため、C) または D) を検討している可能性が最も高いでしょう。

選択したオプションには、依存性注入/制御パターンの反転など、独自のバリアントを含めることができます。しかし、前もってそれをやろうとしないことをお勧めします。アプリにとってやり過ぎのように聞こえます。

これは典型的なプレゼンテーション/データ/ビジネス アプリケーションのようです

はい、そうですが、プロジェクトの 90% 以上は何らかの方法で行われます。あなたが提示していないデータを持つことはあまり意味がありません。データのないプレゼンテーションではあまり意味がありません。

投稿時点で 2,000 近くの担当者がいれば、明らかにコーディングできます。だから私は提案するつもりです: 3 つのプロジェクトでソリューションを構築します。

  1. データアクセス
  2. ビジネス層
  3. プレゼンテーション。
  4. 単純なクラス (POCO) と基本的なオブジェクト ロジックのみを含むコア モデル プロジェクト
  5. 依存性注入/制御の反転

非常に熱心な場合にのみ 4 または 5 を検討してください。DI/IOC は、1/2/3/4 タイプのソリューションに満足するまでそのままにしておくのがおそらく最善です。

フロント エンド プロジェクトからデータ アクセス プロジェクトを参照/呼び出しすることは避けてください。

コア モデルは他のプロジェクトを参照しないでください。

これは、MVC を使用できるものですか?

はい、できます。フロントエンド プロジェクトにはコントローラ (または 2 つ) があります。コントローラは、フロントエンド プロジェクトのビューを「呼び出し」ます。ビューは、ユーザーからデータを提示して取得するだけです。コントローラーは別のレイヤーを呼び出します。たとえば、コントローラー呼び出しのビジネス プロセス レイヤーは、必要なすべての情報を取得して更新するために、データ レイヤーに対して複数の呼び出しを行う場合があります。

MVC について詳しく知りたい場合は、http://www.asp.net/mvc/tutorialsを参照してください。チュートリアルは、MVC の側面に集中しているため、常にきれいに「分離」されているとは限りません。実際、コントローラーの途中でデータアクセスが表示されます。プレゼンターが実際のプロジェクトで絶対にやらないこと。

小規模な 1 回限りのアプリの場合は、基本的な MVC パターンを使用する 1 つのプロジェクトで十分です。複数のプロジェクトは「デモ」を複雑にします。しかし、アプリの Windows WPF バージョンが必要だと想像してください。そして、MVC プロジェクトのデータ アクセス コードを参照してください。再利用はあまりありません。それは、分離が良い理由のタイプをよりよく説明しています.

幸運を...

于 2013-05-01T13:20:16.443 に答える