Что вернуть из сервиса в веб-приложение ASP MVC? - PullRequest
0 голосов
/ 25 января 2012

Прямо сейчас у меня есть веб-приложение ASP MVC в проекте Models, проекте Service, проекте Utilities и нескольких проектах Datastores, которые функционируют в качестве хранилища для одной или нескольких моделей домена.Я очень доволен разделением каждого слоя, но застрял на том, что нужно вернуть из сервисного уровня в веб-приложение.

Например, когда пользователь пытается зарегистрироваться, RegisterViewModel получаетконтроллер.Отдельные фрагменты (электронная почта, пароль и т. Д.) Отправляются на сервисный уровень, который создает объект домена-члена с помощью guid, status, createate и т. Д., Отправляет его в хранилище для хранения и, наконец, возвращает объект-член для веб-приложения для перенаправления на/Member/ enjguid rout.

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

Даже если я найду способ вернуть все это, вебслой будет обременен обработкой всего этого и предоставит пользователю различные отзывы.Код контроллера будет громоздким и обрезать ошибки.Есть ли лучшая практика по результату обслуживания до презентации?Должен ли я исключить отдельный уровень обслуживания и иметь код внутри контроллера?Любые мысли приветствуются.

Ответы [ 2 ]

0 голосов
/ 25 января 2012

Я написал для этой цели библиотеку модель работы , которая позволяет писать код, подобный следующему:

public OperationResult Register(RegisterInput input) {

   var errors = new ErrorBuilder();

   if (errors.NotValid(input) // Invoke DataAnnotations validation
      || errors.Not(this.repo.FindUserByEmail(input.Email) == null, "Email '{0}' already exists.", () => input.Email))
      return errors;

   // Do stuff

   return HttpStatusCode.OK;
}

... и в контроллере сообщения об ошибках копируются вModelState:

[HttpPost]
public ActionResult Register(RegisterInput input) {

   var result = this.service.Register(input);

   if (result.IsError)
      return View().WithErrors(result);

   // Do stuff
}

Проверьте исходный код проекта MvcAccount , который написан с использованием этого шаблона.

0 голосов
/ 25 января 2012

Прежде всего вам необходимо решить, пишете ли вы сервисный слой для целей распространения или нет.

Если вы не планируете распространять уровень обслуживания на другой процесс / машину,

  1. Создать класс сообщения
  2. Создать массив классов сообщений и сохранить его в HttpContext.Items
  3. Теперь добавьте любое новое сообщение в любом слое в этот массив
  4. потреблять его в представлениях / контроллере

HttpContext.Items доступен на весь срок действия запроса, и вы можете использовать его вплоть до просмотров.

Если вы используете инфраструктуру DI, вы можете добиться того же, используя запрос на объект времени жизни.

Если вы хотите распределить объект, нет ничего плохого в создании исключений из вашего сервисного уровня.

...