2

前の投稿が削除されました。更新日:

したがって、私には固有の問題がありますが、これはおそらくかなり一般的です。プロパティは、おそらく最も一般的に使用されるコードです。データを一定値のストレージに保持する必要があるためです。それで、これをどのように実装できるかを考えました。それから私は、ジェネリックが生活をいかに簡単にできるかを考えました. 残念ながら、複雑な作業を行わずにジェネリックでプロパティを使用することはできません。これが私の解決策/問題でした。それが最善の方法かどうかわからないので、仲間にレビューを求めていたのはそのためです。

アプリケーションは大規模になることに注意してください。これは非常に簡単な例です。

概要：

プレゼンテーション層: インターフェイスには一連のフィールドがあります。または、Web サービスを介してネットワークを介してデータベースに送信されるデータです。 

// Interface:
public interface IHolder<T>
{
     void objDetail(List<T> obj);
}

したがって、私の最初の考えは、オブジェクトのそれぞれを一般的に処理できるようにするインターフェイスでした。

// User Interface:
public class UI : IHolder
{
    void objDetail(List<object> obj)
    {
        // Create an Instance
        List<object> l = new List<object>();
        // Add UI Fields:
        l.Add(Guid.NewGuid());
        l.Add(txtFirst.Text);
        l.Add(txtLast.Text);
        // l to our obj        
        obj = l;
        return;
     }
}

これでインターフェースができました。これは、UI で情報を入力するために使用されています。これは、私の好奇心の根源が混合物に投入された場所です.

// Create an Object Class
public class Customer : IHolder
{
     // Member Variable:
     private Guid _Id;
     private String _First;
     private String _Last;

     public Guid Id
     { 
           get { return _Id; }
           set { _Id = value; }
     }
     public String First
     {
           get { return _First; }
           set { _First = value; }
     }
     public String Last
     {
           get { return _Last; }
           set { _Last = value; }
     }

     public virtual objDetail(List<Customer> obj)
     {
         // Enumerate through List; and assign to Properties.
     }
}

これは私がクールだと思った場所です。ポリモーフィズムを使用して同じインターフェイスを使用できる場合。しかし、それをオーバーライドして、メソッドを別の方法で実行します。したがって、インターフェイスはジェネリックを利用します。特定のオブジェクト クラスにモーフする機能を備えています。

オブジェクトクラスです。基本的な Crud 操作を処理する Entity インターフェイスに移行できます。

この例が私の意図に最適ではないことはわかっています。ポリモーフィズムを使用する必要はありません。しかし、これは全体的なアイデア/目標です...

  • プレゼンテーション レイヤー UI フィールド値を格納するためのインターフェイス
  • プロパティを目的のクラスに実装する
  • クラスのラッパーを作成します。これはポリモーフィングできます。
  • Crud操作のジェネリックにモーフィング

私は正しい道を進んでいますか？これはタブーですか？私はこれをすべきではありませんか？私のアプリケーションは各インスタンスを保持する必要があります。しかし、プロセス内のすべてのインスタンスを中断することなく、非常に迅速に適応できる柔軟性が必要です。それが私が問題を解決できると思った方法です。何かご意見は？提案？ここにコンセプトがありませんか？それとも私は考えすぎですか？私はボートに乗り遅れ、自分のアイデアを完全に間違って実装しましたか? そこが私が迷っているところです...

4

1 に答える 1

0

このシナリオについて少し考えた後、変更とビジネスのためにコードが最適化されていることを保証しながら、その柔軟性を提供するにはどうすればよいかを考えました。これが正しい解決策かどうかはわかりませんが、うまくいくようです。機能するだけでなく、うまく機能します。かなり頑丈そうです。

このアプローチはいつ役に立ちますか? ユーザー インターフェイスをロジックから分離する場合です。全体の構造が見えるように、各側面を徐々に構築していきます。

public interface IObjContainer<T>
{
     void container(List<T> object);
}

この特定の構造が重要になります。必要なコンテンツをすべてそこに保存するためです。

まず、一連のフィールドを持つフォームを作成します。

  • 個人情報
  • 住所情報
  • 支払情報
  • 注文情報

ご覧のとおり、これらはすべて別個のデータベース テーブルである可能性がありますが、操作している同様のエンティティ モデルに属しています。これは非常に一般的です。

そのため、懸念の分離がわずかに現れ始め、フィールドが操作され、インターフェイスを介して渡されます。

public interface IPersonalInformation
{
      public string FirstName { get; set; }
      public string LastName  { get; set; }
}

したがって、本質的にインターフェイスはその変数をインターフェイスに渡します。したがって、呼び出したいフォーム全体または個々のインターフェイスを処理するインターフェイスを完成させて、それらを再利用できるようにします。

これで、一連のインターフェイス、または 1 つのインターフェイスができました。ただし、使用するこれらすべての変数が含まれています。したがって、クラスを作成します。

public class CustomerProperties: IPersonalInformation, IOrderInformation
{
    // Implement each Interface Property
}

これで、すべての値を保持するコンテナが作成されました。このコンテナーの優れた点は、アプリケーション内の別のクラスに同じ値を再利用したり、別の値を選択したりできることです。ただし、ユーザー インターフェイスは論理的に分離されます。

したがって、基本的にこれはリポジトリと同様に機能します。

これで、これらの値を取得して目的のロジックを実行できます。ここで素晴らしいのは、ロジックを実行した後、オブジェクトをジェネリック リストに渡すことです。次に、そのメソッドを目標のために別のクラスに実装し、リストを反復処理します。

正直なところ、うまく機能し、うまく分離しているように見えます。通常のリポジトリと作業単位に似たようなことをするのは大変な作業だったと思います。これで質問に答えますが、天気が良いかどうかはプロジェクトにとって理想的です。リポジトリ、作業単位、懸念の分離、制御の反転、および依存性注入。彼らはこれと同じアプローチをよりきれいにするかもしれません。

アップデート：

これを書いた後で考えてみたところ、一連のインターフェイスをバイパスして、これらのプロパティ値をジェネリック リスト構造に実際に実装できることに気付きました。ただし、毎回どのデータが順番に渡されているかを認識しなければならないため、一貫性の問題が発生します。可能ですが、理想的ではないかもしれません。

于 2013-02-27T19:47:55.783 に答える