Это хорошая идея, чтобы извлечь логику контроллера в службу, которая расширяет функциональность хранилища - PullRequest
Новая
       54

Это хорошая идея, чтобы извлечь логику контроллера в службу, которая расширяет функциональность хранилища

2 голосов
/ 25 июня 2010

У меня было действие POST контроллера, которое называется List, которое принимает переменную состояния, которая может принимать следующие значения: {"all", "active", "notactive}. Затем я сделал вызовы репозитория на основе значения" status " "внутри контроллера. Контроллер выглядел так: 

    [HttpPost]
    public ActionResult List(string status)
    {
        return View(GetJobTitlesByStatus(status));
    }

    private IList<JobTitle> GetJobTitlesByStatus(string status)
    {
        IList<JobTitle> jobTitles;

        switch (status)
        {
            case "All":
                jobTitles = jobTitleRepository.GetAll();
                break;
            case "Active":
                jobTitles = jobTitleRepository.GetActive();
                break;
            case "Inactive":
                jobTitles = jobTitleRepository.GetInactive();
                break;
            default:
                jobTitles = new List<JobTitle>();
                break;
        }
    }

Я решил, что код в операторе switch слишком велик, чтобы находиться внутри контроллера, поэтому я извлек это в службу, и эта служба затем выполняет соответствующие вызовы репозитория. Например: 

public class JobTitleService : JobTitleRepository, IJobTitleService, IJobTitleRepository
{
    public JobTitleService(ISession session) : base(session) { }
    public IList<JobTitle> GetJobTitlesByStatus(string status)
    {
        IList<JobTitle> jobTitles;

        switch (status)
        {
            case "All":
                jobTitles = base.GetAll();
                break;
            case "Active":
                jobTitles = base.GetActive();
                break;
            case "Inactive":
                jobTitles = base.GetInactive();
                break;
            default:
                jobTitles = new List<JobTitle>();
                break;
        }

        return jobTitles;
    }
}

Лично я считаю, что это прекрасно работает, тем более, что я использую внедрение зависимостей для передачи службы в контроллер. У меня есть следующие вопросы:

1) Считаете ли вы хорошей идеей извлечь логику оператора switch из контроллера?
2) Считаете ли вы, что иметь JobTitleService наследовать от JobTitleRepository лучше, чем Передача IJobTitleRepository в конструктор Сервиса (с использованием внедрения зависимостей)?
3) Существует ли специальное имя для шаблона проектирования, используемого для JobTitleService?

Ответы [ 2 ]

3 голосов
/ 25 июня 2010

  1. Да - ваш контроллер должен отвечать за выбор результата, подготовку модели и передачу модели в представление для визуализации. Все остальное должно быть делегировано где-то еще, обычно это сервисы. Взято прямо из википедии :

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

  2. Нет, ваш сервис не должен наследоваться от хранилища. Служба должна сотрудничать с хранилищем для выполнения своих функций - таким образом, это отношение «есть», а не «есть». Прямо сейчас это может быть неочевидным, поскольку ваш сервис - это просто проход к хранилищу, но как только ваш сервис начнет делать то, что сервис должен делать (координировать действия одного или нескольких соавторов), он сразу станет очевидно, что вы сможете наследовать только от одного из этих соавторов.

    На самом деле, в этом случае, если ваш сервис всегда будет прямой оберткой вокруг репозитория, он ничего не добавляет, а просто слой косвенности - если он останется таким простым, я обойдусь без него и запросю репозиторий непосредственно. Хотя обычно все не так долго остается простым.

  3. Нет, не совсем.

2 голосов
/ 25 июня 2010

1) Да, бизнес-логика не должна быть в контроллере. Контроллеры действительно просто связывают презентацию с логикой. В идеале логика выполняется в более объектно-ориентированном подходе, чем в более процедурном подходе, который вы здесь используете, но не отговаривайтесь от этого. Процедурный не так уж и плох, если код прост и поддерживается. Для вас этот дизайн позволяет вам переместить ваш класс обслуживания в отдельный сервис, если вам когда-либо это понадобится.

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

3) Я уверен, что есть официальное название, которое можно поместить в резюме где-то :) «Сервисно-ориентированная архитектура» приходит на ум вместе с другими модными словами. Я никогда не разбирался в терминологии, поэтому я не могу сильно помочь в этой части. Но есть много материалов для чтения на эту тему. Это выглядит как хорошее прочтение для такого рода вещей: http://msdn.microsoft.com/en-us/library/ms954638.aspx Может быть, искать ресурсы здесь также: http://www.soapatterns.org/

...