web-dev-qa-db-ja.com

作成アクションと編集アクションを別々にするか、作成と編集を1つに組み合わせる方が良いですか？

ビジネスロジックレイヤー、データアクセスレイヤーで構成されるコントローラー/ビュープレゼンテーションレイヤーとモデルでASP.NET MVC 2を使用しています[ストアドプロシージャと、ストアドプロシージャと通信するためのクラス/メソッド]。

ビジネスレイヤー以上では、ほとんどの目的で、編集はオブジェクトの作成とオブジェクトの編集の両方を表すことができるようです。これは、「保存」方法を定義するリポジトリ設計パターンとよく一致します。 IDが0の場合はストアドプロシージャをチェックインし、0の場合は新しいオブジェクトを作成できます。それ以外の場合は、既存のオブジェクトを更新できます。これは、カテゴリIDが1に一致する必要があるためです。

議論の主なポイントは、DALレイヤーを超えて、作成を含む編集を作成と編集の個別の部分に分割することが最も理にかなっているかどうかです。

明白な例はルートとして表示できます：

作成- http：// someurl/somearea/edit/

編集- http：// someurl/somearea/edit/254

対

作成- http：// someurl/somearea/create

編集- http：// someurl/somearea/edit/254

これに関して確立された標準やベストプラクティスはありますか？

細かいことはわかっていますが、ロジスティック的に重要なものだと思います。

designdesign-patternsasp.net-mvc
15
Joshua Enfield

単一責任の原則 に従わない場合は、作成と編集を分離する価値があると私は間違いなく言います。

URLで正しいアクションを実行するほうがSEOが優れていると主張する人もいます。

2つを分離しないと、コードの単体テストも難しくなります。

コードを読んでいる新しいプログラマーは、おそらく「編集」メソッドでオブジェクトを作成する必要がある非常に直感的なコードを見つけられないでしょう。ただし、DALのSave（）メソッドに共感できます。

考えてみると、すべてをEditメソッドに配置することの利点は本当にわかりません。

5
nillls

私は通常、DALでSaveメソッドを1つ作成することを好みますが、実際にはCreate/Edit/Deleteを個別に実装します。

たとえば、私のSaveメソッドはオブジェクトの状態をチェックし、必要なものに応じてCreate/Edit/Deleteメソッドを呼び出します。

switch(obj.State)
{
    case ObjectState.New:
        CreateObject(obj);
        break;
    case ObjectState.Modified:
        UpdateObject(obj);
        break;
    case ObjectState.Deleted:
        DeleteObject(obj);
        break;
}

これにより、任意のオブジェクトを保存するための1つのジェネリックメソッドを呼び出すことができますが、それぞれの実装（作成、編集、削除）は分離されたままです。

4
Rachel