Чи краще мати окремі дії "Створити та редагувати" або об'єднати "Створити та змінити" в одну?

15

Ми використовуємо ASP.NET MVC 2 з контролером / переглядом презентаційного шару та моделі, що складається з бізнес-логічного шару, рівня доступу до даних [збережені процедури та класи / методи для спілкування із збереженими процедурами].

На рівні бізнесу та вище для більшості цілей редагування, здається, здатне представляти як створення об'єкта, так і редагування об'єкта. Це добре збігається з нашою схемою дизайну репозиторію, яка визначає метод "Зберегти". Ми можемо просто перевірити збережену процедуру, якщо ідентифікатор дорівнює 0, а потім створити новий об’єкт, якщо він дорівнює 0, інакше ми можемо просто оновити існуючий об’єкт, оскільки ідентифікатор категорії повинен відповідати одному.

Основним моментом обговорення є те, якщо має сенс розділити Правка, що включає в себе створення на окремі частини створення та редагування за межами шару DAL.

Очевидний приклад можна показати як маршрути:

Створити - http: // someurl / somearea / edit / 0

Редагувати - http: // someurl / somearea / edit / 254

vs.

Створити - http: // someurl / somearea / create

Редагувати - http: // someurl / somearea / edit / 254

Чи існують встановлені стандарти чи найкращі практики щодо цього?

Я знаю, що це невелика деталь, але я думаю, що це логічно важливо.

design design-patterns asp.net-mvc

— Джошуа Енфілд
джерело

4

Я особисто думаю, що окремі дії "Створити та редагувати" - це набагато чистіша (і, можливо, простіша в обслуговуванні) реалізація.

— Адам Лір

1

Один метод у DAL, два для API, якщо це має сенс.

— CaffGeek

Ну, з моєї точки зору, окремі створення та редагування приходять природно до mvc, і використання такого підходу дає велику перевагу використання mvc в повній мірі, і це має бути всім.

— maz3tt

5

Я б точно сказав, що варто окремо створювати / редагувати, якби не дотримання принципу єдиної відповідальності .

Можна стверджувати, що є кращий SEO в правильних діях і в URL-адресі.

Якщо не розділити два, це також зробить код складніше для тестування одиниць.

Новий програміст, який читає код, напевно, не знайде код дуже інтуїтивно зрозумілим, що повинен створювати об'єкти методом "редагування", це просто не має сенсу семантично. Однак я можу співчувати методу Save () у DAL.

Думаючи про це, я не можу реально побачити переваги внесення цього методу в редагування.

— ніллі
джерело

4

Зазвичай я вважаю за краще створити один Saveметод у DAL, але реально реалізувати Create// Edit/ Deleteокремо.

Наприклад, мій Saveметод перевірить стан об'єкта та викликав би метод створення / редагування / видалення залежно від необхідності

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

Це дозволяє мені просто викликати один загальний метод для збереження будь-якого об’єкта, але все ще зберігає реалізацію кожного (Create, Edit, Delete) розділеним.

— Рейчел
джерело

Як ви могли сказати його видалення?

— NoChance

Зазвичай мої об’єкти мають Stateвластивість. Наприклад, натискання Deleteкнопки позначить об’єкт як Видалений, а потім зателефонуйтеSaveChanges()

— Рейчел