2

これが簡単であることを願っています。作成しているMVCアプリケーションにコマンドパターンを実装しようとしています。私が見ている唯一の問題は、コマンドオブジェクトの数が本当に多いということです。

更新が必要なフィールドが約20個ある11個のテーブルがあります。

私の質問は、フィールドごとに異なるオブジェクトが必要ですか？

これはヘルスケアアプリケーションなので、例を挙げましょう。KeyHospitalというテーブルがあります。このテーブルには、病院情報と、病院クライアントの病院情報のみが格納されます。データベースへの接続にLinqtoSQLを使用しました。KeyHospitalテーブルは、フィールドに関してはおそらく最大です。私がやったことは、フィールドごとに新しいオブジェクトを作成することです。

public class ChangeHospitalDEA : ICommand
{
    public ChangeHospitalDEA(int id, string newDEA)
    {
        var Thishospital = (from Hospital in _context.Keyhospitals
                            where Hospital.ID == id
                            select Hospital).Single();

        Thishospital.DEAnum = newDEA;
    }
}

私は抽象クラスとしてICommandを持っています。

public abstract class ICommand
{
    public AllkeysDataContext _context = new AllkeysDataContext();

    public void Execute()
    {
        _context.SubmitChanges();
    }
}

私はこれを正しくやっていますか？このためにたくさんのコードを書いているような気がします。これは、コマンドパターンを使用するのは初めてのことです。

4

2 に答える 2

1

かなり細かすぎる。代わりに、新しいエンティティの挿入、(1 つ以上の関連オブジェクトのグラフ) エンティティの更新などのアクションのコマンドを定義する必要があります。

アクションを実行したいときはいつでもコマンドが使用されます。場合によっては、1 つのフィールドを変更するだけで、追加のデータを返したり、提案を提供したりするなどのアクションが構成されることがあります。入力されたアドレスを検証するための AJAX 呼び出しなど。また、ICommand基本抽象クラスの名前の選択は適切ではありません。ICommandコマンド アーキテクチャの共通インターフェイスです。(「I」接頭辞は、通常、インターフェイス名用に予約されています。) 私は主に MVVM を扱っていますが、MVC には既に共通のコマンド インターフェイスがあるのではないかと思います。

于 2012-12-04T22:35:11.437 に答える
0

これはあなたが聞きたいことではないかもしれませんが、ユーザー インターフェイスをタスク ベースの UI に再構築し、UI を一般的なタスク (麻薬取締局の番号の変更など) に構築します。これらのタスクは時間の経過とともに洗練されます。

既存の分析がある場合、特定のフィールドが一緒にのみ変更され、これらが一般的なタスクに論理的にグループ化される可能性があることに気付くでしょう。また、コンストラクター内でデータベース呼び出しを非表示にし、その linq ステートメントを Execute に移動するのは悪い習慣だと思います。メソッドを実行し、ctor にパブリック プロパティまたはプライベート フィールドのみを初期化し、それらのフィールドを execute メソッド内で使用するようにします。

クエリを execute メソッドに移動する主な理由は、オプティミスティック コンカレンシー エラーが発生する可能性を減らすためです。

また、基本クラス ICommand を呼び出すことは適切な方法ではなく、将来的に混乱を招く可能性があると感じています。CommandBase を呼び出すか、もう一度インターフェイスに変更することをお勧めします。

于 2012-12-09T19:27:33.053 に答える