Czy lepiej jest mieć osobne akcje Utwórz i Edytuj, czy połączyć Utwórz i Edytuj w jedną?


15

Używamy ASP.NET MVC 2 z warstwą kontrolera / widoku i modelem prezentacji złożonym z warstwy logiki biznesowej, warstwy dostępu do danych [Procedury składowane i klasy / metody komunikowania się z procedurami przechowywanymi].

Wydaje się, że w warstwie biznesowej i wyższych dla większości celów edycja może reprezentować zarówno tworzenie obiektu, jak i edycję obiektu. Jest to dobrze zbieżne z naszym Wzorem Projektu Repozytorium, który definiuje metodę „Zapisz”. Możemy po prostu sprawdzić w procedurze przechowywanej, czy identyfikator ma wartość 0, a następnie utworzyć nowy obiekt, jeśli ma wartość 0, w przeciwnym razie możemy po prostu zaktualizować istniejący obiekt, ponieważ identyfikator kategorii powinien być zgodny z jednym.

Podstawowym punktem dyskusji jest to, czy najbardziej sensowne jest podzielenie Edycji zawierającej Kreację na oddzielne części Utwórz i Edytuj poza warstwą DAL.

Oczywisty przykład można przedstawić jako trasy:

Utwórz - http: // someurl / somearea / edit / 0

Edycja - http: // someurl / somearea / edit / 254

vs.

Utwórz - http: // someurl / somearea / create

Edycja - http: // someurl / somearea / edit / 254

Czy istnieją jakieś ustalone standardy lub najlepsze praktyki w tym zakresie?

Wiem, że to mały szczegół, ale myślę, że jest to logistycznie ważne.


4
Osobiście uważam, że osobne działania Utwórz i Edytuj to znacznie czystsze (i być może łatwiejsze w utrzymaniu) wdrożenie.
— Adam Lear

1
Jedna metoda w DAL, dwie dla API, jeśli ma to sens.
— CaffGeek

Cóż, z mojego punktu widzenia, osobne tworzenie i edycja przychodzą naturalnie do mvc, a takie podejście daje wiele korzyści z pełnego wykorzystania mvc i to powinno być celem każdego.
— maz3tt

Odpowiedzi:


5

Zdecydowanie powiedziałbym, że warto oddzielić Tworzenie / Edycja, gdyby nie przestrzeganie zasady pojedynczej odpowiedzialności .

Można powiedzieć, że poprawne działanie w adresie URL jest lepsze.

Nieoddzielenie tych dwóch sprawiłoby również, że kod byłby trudniejszy do testowania jednostkowego.

Nowy programista czytający kod prawdopodobnie nie uznałby kodu za bardzo intuicyjny w tworzeniu obiektów metodą „edycji”, po prostu nie ma to sensu semantycznego. Mogę jednak sympatyzować z metodą Save () w DAL.

Myśląc o tym, naprawdę nie widzę korzyści płynących z umieszczenia tego wszystkiego w metodzie edycji.


4

Zwykle wolę utworzyć jedną Savemetodę w DAL, ale faktycznie implementuję Create/ Edit/ Deleteosobno.

Na przykład moja Savemetoda sprawdza stan obiektu i wywołuje metodę Create / Edit / Delete w zależności od potrzeb

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

Pozwala mi to po prostu wywołać jedną ogólną metodę zapisywania dowolnego obiektu, ale nadal zachowuje osobną implementację każdej (Utwórz, Edytuj, Usuń).


Jak możesz powiedzieć, że to usunięcie?
— NoChance

Zwykle moje obiekty mają Statewłaściwość. Na przykład kliknięcie Deleteprzycisku oznaczałoby obiekt jako usunięty, a następnie zadzwoniłSaveChanges()
— Rachel
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.