Сервисный слой или контроллер?

Question

У меня есть галерея в моем проекте. Я сохраняю изображения на жестком диске, но теги, описания и т. Д. Сохраняю в базу данных. Работа с базой данных и проверка данных проходят через сервисный уровень. Поскольку пользователь удалил образ, файлы будут удалены с жесткого диска, а запись будет удалена из базы данных.

//Action 
public ActionResult Delete (int id) 
( 
var entity = ServiceLayer.Entities.Get (id); 

System.IO.File.Delete (entity.FileName); //Might it be also be put to the service layer?
ServiceLayer.Entities.Delete (entit); 

return RedirectToAction ( "Index"); 
) 

Лучше ли ставить код для удаления файлов на уровне сервиса или в контроллере?

Answer 1

Вы всегда должны помещать этот вид кода в службу.

Контроллер должен делать как можно меньше - он должен знать, как получить сервис, передать ему любые параметры и вернуть представление.

Несмотря на то, что код в настоящее время прост, он может со временем расти, и это хороший способ убедиться, что у вас есть хорошая структура для начала.

Answer 2

Лучше сделать это на уровне сервиса.

Контроллер должен обрабатывать только выяснение того, что запросил пользователь, вызов необходимых служб, чтобы выполнить то, что хотел пользователь, и показывать пользователю, что он должен увидеть в ответ.

Answer 3

Вы должны задать себе вопрос, за что отвечает мой контролер?

ИМХО, контроллеры должны выступать в качестве посредников между представлением и моделью, где модель в данном случае включает в себя службы.

Тем не менее, никогда не существует строгих правил относительно того, что и куда ставить. В отличие от фанатиков, публикующих строгие ответы, я бы выбрал прагматичный подход. Будет ли добавление зависимости файловой системы к вашей службе базы данных сделать ее более полезной? Приведет ли это к взрыву типа - ваш сервис должен иметь зависимость от файловой системы injectet == +1 интерфейс +1 конкретная реализация +1 класс тестирования в случае модульных тестов и т. Д.

Сомтьемс, это того не стоит, так что используйте свое собственное мнение.

Answer 4

Я бы поместил это на сервисный уровень, чтобы вы могли абстрагировать его и протестировать с помощью TDD.