Khi nào nên kết hợp chức năng Thêm / Chỉnh sửa và khi nào nên tách chúng ra?

Tôi thường xuyên gặp các tình huống tôi cần Thêm hoặc Chỉnh sửa một mục và đôi khi tôi sử dụng các phương pháp riêng cho Thêm và Chỉnh sửa và những lần khác tôi kết hợp chúng thành một phương thức duy nhất.

Là một phương pháp được ưa thích hơn phương pháp khác? Nếu vậy, tại sao?

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

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

HOẶC LÀ

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

nơi ShowEditingPopupđược định nghĩa là

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

Chỉnh sửa: Chỉ cần làm rõ, tôi không lưu mục này, tôi đang mở nó để chỉnh sửa. Tôi hầu như luôn luôn thực hiện một phương thức Save chung để lưu vào cơ sở dữ liệu

Chỉnh sửa # 2: Đã chỉnh sửa các mẫu mã để chúng phản ánh chính xác hơn loại tình huống tôi đang đề cập đến

Hãy suy nghĩ về bối cảnh của bạn trong một giây ... Không có sự phân biệt giữa việc thêm một yếu tố mới hoặc chỉnh sửa một yếu tố hiện có. Bạn chỉ cần SaveChanges(). Trạng thái phần tử riêng lẻ cho biết bối cảnh liệu phần tử mới của nó được thêm vào hay phần tử hiện có đang được chỉnh sửa.

EDIT: Ok ... Trong trường hợp đó, tôi có các Hành động điều khiển (MVC3) riêng cho mỗi hành động, tuy nhiên, chỉ có 1 lượt xem ...

Giả sử tôi đang thêm hoặc chỉnh sửa một Personthực thể. Tôi hầu như luôn có hai mô hình để xử lý các quá trình thêm / chỉnh sửa:

• AddPersonModel
• EditPersonModel

Chúng hầu như luôn luôn kế thừa từ một lớp cơ sở trừu tượng chung:

• AddEditPersonModelBase

Vì vậy, lớp cơ sở có thể có một Commitphương thức trừu tượng , mà các lớp dẫn xuất ghi đè lên để tạo ra một Personthực thể mới hoặc để lưu các thay đổi cho Personthực thể hiện có .

Logic nghiệp vụ phổ biến cho cả thêm và chỉnh sửa đi vào lớp cơ sở (ví dụ: để chỉnh sửa địa chỉ), nhưng luôn có một chút logic nghiệp vụ khác nhau nếu bạn thêm hoặc chỉnh sửa và chúng đi trong các lớp con. Chẳng hạn, bạn có thể muốn gán cho họ số ID tăng dần duy nhất, nhưng thực tế bạn không tạo nó cho đến khi bạn lưu thực thể. Trong trường hợp đó, chỉ có bạn EditPersonModelcó tài sản đó.

Tương tự, bạn có các Chế độ xem (và ViewModels) riêng biệt để thêm hoặc chỉnh sửa một Person, nhưng sẽ có ý nghĩa khi cả hai thêm và chỉnh sửa các biến thể kế thừa từ cùng một lớp cơ sở vì rất nhiều trong số đó là phổ biến.

Cá nhân tôi có xu hướng tuân theo các nguyên tắc là ngữ nghĩa . Điều này có nghĩa là tôi thường không cung cấp biểu mẫu chỉnh sửa tất cả trong một. Nói cách khác, người dùng thường không muốn chỉnh sửa toàn bộ thông tin của một thực thể . Thay vào đó quá trình chỉnh sửa của họ là ngữ nghĩa hơn và có thể được phân loại. Ví dụ, đối với thực thể người dùng , mọi người thường chỉnh sửa mật khẩu và chỉnh sửa hồ sơ . Vì vậy, tôi thực hiện hai chức năng để chỉnh sửa như:

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

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

Hoặc, người dùng thường chỉnh sửa một bài viết theo những cách sau:

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

}

public bool EditArticleSummary(int articleId, string newSummary)
{

}

Tóm lại, tôi thường tạo một biểu mẫu tạo tất cả trong một, nhưng tôi có xu hướng sử dụng các biểu mẫu chỉnh sửa nhỏ, chunk cho mỗi thao tác chỉnh sửa ngữ nghĩa. Vì vậy, tôi thường không hợp nhất chúng. Tuy nhiên, điều này không có nghĩa là bạn không thể hợp nhất chúng. Bất cứ khi nào bạn muốn cung cấp một hình thức chỉnh sửa lớn, béo tương tự như hình thức tạo, tôi nghĩ rằng việc hợp nhất có thể hoạt động tốt hơn.

Đây là vấn đề bạn hiểu nguyên tắc trách nhiệm đơn lẻ như thế nào . Sẽ sạch sẽ hơn và dễ đọc hơn, dễ hiểu hơn và duy trì nếu các trách nhiệm được tách rời để tách biệt các phương thức / hành động. Tuy nhiên, điều này từ quan điểm mã hóa.

Nếu tôi phải chọn một cách tiếp cận trong số các ví dụ của bạn, tôi sẽ chọn cách tiếp cận đầu tiên .

Quan điểm của người dùng phụ thuộc vào việc dễ dàng thêm mục mới hoặc chỉnh sửa mục hiện có (số lần nhấp là một cách tôi đo) và có thể tuân theo một số quy tắc vàng.

Nếu tôi phải triển khai chức năng (UI / Form), tôi sẽ có một biểu mẫu duy nhất khi thêm và chỉnh sửa cả hai đều có cùng một định dạng và hai biểu mẫu riêng biệt khi chúng khác nhau.