追加/編集機能を組み合わせるのが望ましい場合、およびそれらを別々に保つ場合はいつですか？

アイテムを追加または編集する必要がある状況に定期的に遭遇し、追加と編集に別々のメソッドを使用することもあれば、それらを1つのメソッドに結合することもあります。

ある方法が他の方法よりも優先されますか？もしそうなら、なぜですか？

public void AddItem()
{
    ShowEditingPopup(new Item(), "Add Item");
}

public void EditItem(Item item)
{
    ShowEditingPopup(item, "Edit Item");
}

または

public void EditItem(Item item)
{
    ShowEditingPopup(
        (item ?? new Item()), 
        string.format("{0} Item", (item == null ? "Add " : "Edit "))
    );
}

どこShowEditingPopupのように定義されます

public void ShowEditingPopup(object popupDataContext, string popupTitle)
{
    PopupDataContext = popupDataContext;
    PopupTitle = popupTitle;
    IsPopupVisible = true;
}

編集：明確にするために、アイテムを保存するのではなく、編集用に開いています。ほとんどの場合、データベースに保存するための汎用のSaveメソッドを実装します

編集＃2：私が参照している状況の種類をより正確に反映するようにコードサンプルを編集

しばらくの間、コンテキストについて考えてください...新しい要素の追加と既存の要素の編集の間に違いはありません。あなただけSaveChanges()です。個々の要素の状態は、新しい要素が追加されているか、既存の要素が編集されているかをコンテキストに通知します。

編集：わかりました...まあ、その場合、私はアクションごとに個別のコントローラーアクション（MVC3）を持っていますが、ビューは1つだけです...

Personエンティティを追加または編集しているとしましょう。ほとんどの場合、追加/編集プロセスを処理する2つのモデルがあります。

• AddPersonModel
• EditPersonModel

ほとんどの場合、共通の抽象基本クラスから継承します。

• AddEditPersonModelBase

したがって、基本クラスには抽象Commitメソッドがあり、派生クラスは、新しいPersonエンティティを新しく作成するか、既存のPersonエンティティへの変更を保存するためにオーバーライドします。

追加と編集の両方に共通のビジネスロジックは基本クラス（たとえば、住所の編集）にありますが、追加または編集している場合とサブクラスにある場合では、常に少しずつ異なるビジネスロジックがあります。たとえば、一意の増分ID番号を割り当てたい場合がありますが、エンティティを保存するまで実際には作成しません。その場合、あなただけEditPersonModelがその特性を持っています。

同様に、を追加または編集するための個別のビュー（およびViewModel）Personがありますが、追加と編集の両方のバリアントが同じ基本クラスから継承することは理にかなっています。

私は個人的にはセマンティックであるという原則に従う傾向があります。つまり、私は通常、オールインワンの編集フォームを提供していません。つまり、ユーザーは通常、エンティティの情報全体を編集する必要はありません。むしろ、編集プロセスはよりセマンティックであり、分類することができます。たとえば、ユーザーエンティティの場合、ユーザーは通常、パスワードとプロファイルを編集します。したがって、次のような編集用に2つの関数を作成します。

public bool EditPassword(string userName)
{
    // code here
}

public bool EditProfile(Profile newProfile)
{
    // code here    
}

または、ユーザーは通常、次の方法で記事を編集します。

public bool PutArticleIntoCategories(int articleId, List<Category> categories)
{

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

簡単に言うと、私は通常オールインワンの作成フォームを作成しますが、セマンティック編集操作ごとに小さなチャンク編集フォームを使用する傾向があります。したがって、私は通常それらをマージしません。ただし、これはそれらをマージできないという意味ではありません。作成フォームに似た太くて大きな編集フォームを提供したいときはいつでも、マージがうまくいくと思います。

これは、単一責任の原則をどの程度理解しているかの問題です。より多くのだろうクリーナーとより簡単に、読んで理解し、責任を別々のメソッド/アクションにして分離されている場合は維持します。ただし、これはコーディングの観点からです。

私があなたの例から一つのアプローチを選ばなければならないなら、私は最初のアプローチに行きます。

ユーザーの視点は、新しい項目の追加や既存の項目の編集（クリック数は私が測定する1つの方法です）がどれほど簡単か、そしておそらくいくつかの基本的なルールに従うかどうかに依存します。

機能（UI /フォーム）を実装する必要がある場合、追加と編集の両方で同じ機能がある場合は1つのフォームがあり、異なる場合は2つの別個のフォームがあります。