Лучше иметь отдельные действия Create и Edit или объединить Create и Edit в одно?

15

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

На бизнес-уровне и выше для большинства целей редактирование представляется способным представлять как создание объекта, так и редактирование объекта. Это хорошо совпадает с нашим шаблоном проектирования репозитория, который определяет метод «Сохранить». Мы можем просто проверить в хранимой процедуре, равен ли идентификатор 0, и затем создать новый объект, если он равен 0, в противном случае мы можем просто обновить существующий объект, поскольку идентификатор категории должен соответствовать единице.

Основной вопрос для обсуждения - если имеет смысл разделить Edit, который включает в себя создание, на отдельные части Create и Edit за пределами уровня DAL.

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

Создать - http: // someurl / somearea / edit / 0

Редактировать - http: // someurl / somearea / edit / 254

против

Создать - http: // someurl / somearea / create

Редактировать - http: // someurl / somearea / edit / 254

Существуют ли какие-либо установленные стандарты или лучшие практики в этом отношении?

Я знаю, что это маленькая деталь, но я думаю, что она важна с логистической точки зрения.

design design-patterns asp.net-mvc

— Джошуа Энфилд
источник

4

Лично я считаю, что отдельные действия Create и Edit - намного более чистая (и, возможно, более простая в обслуживании) реализация.

— Адам Лир

1

Один метод в DAL, два для API, если это имеет смысл.

— CaffGeek

Ну, с моей точки зрения, отдельное создание и редактирование естественно приходят в mvc, и использование такого подхода дает массу преимуществ использования mvc в полной мере, и это должно быть целью для всех.

— maz3tt

5

Я бы определенно сказал, что стоит отделить Create / Edit, если бы не соблюдение принципа единой ответственности .

Можно было бы утверждать, что лучше иметь SEO в правильном действии в URL.

Если не разделить их, это также затруднит тестирование кода.

Новый программист, читающий код, вероятно, не найдет код очень интуитивно понятным для создания объектов методом «редактирования», это просто не имеет смысла семантически. Однако я могу посочувствовать методу Save () в DAL.

Размышляя об этом, я не могу увидеть преимущества использования всего этого в методе редактирования.

— nillls
источник

4

Я обычно предпочитаю создать один Saveметод в DAL, но на самом деле реализовать 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;
}

Это позволяет мне просто вызывать один универсальный метод для сохранения любого объекта, но по-прежнему сохраняет реализацию каждого (Create, Edit, Delete) отдельно.

— Рейчел
источник

Как вы могли бы сказать, что это удаление?

— NoChance

Обычно мои объекты имеют Stateсвойство. Например, нажатие Deleteкнопки пометит объект как удаленный, а затем вызоветSaveChanges()

— Rachel