Это правильный способ кодирования уровня обслуживания MVC? - PullRequest
0 голосов
/ 12 декабря 2011

В моем слое MVC для проверки у меня есть такой код:

protected bool ValidateAccount(Account account)
        {
            var accounts = _accountRepository.GetPk(account.PartitionKey);
            if (accounts.Any(b => b.Title.Equals(account.Title) &&
                                  !b.RowKey.Equals(account.RowKey)))
                _validationDictionary.AddError("", "Duplicate title");
            return _validationDictionary.IsValid;
        }

Однако в методах типа действия я воспринимаю исключения с кодом, подобным этому:

public bool Create(Account account)
{
    if (!ValidateAccount(account))
        return false;
    try
    {
        _accountRepository.AddOrUpdate(account);
    }
    catch
    {
        return false;
    }
    return true;
}

Мой контроллер закодирован так:

public ActionResult Create(BaseViewModel vm)
{
    _accountService = new AccountService(new ModelStateWrapper(this.ModelState), vm.Meta.DataSourceID);
    if (ModelState.IsValid)
    {

            _accountService = new AccountService(new ModelStateWrapper(this.ModelState), vm.Meta.DataSourceID);
            if (!_accountService.Create(vm.Account))
                return View("CreateEdit", vm);
            else
                return RedirectToAction("Created");
        }
        return RedirectToAction("Home");
    }
    return View("CreateEdit", vm);
}

Это разумный подход? Моя единственная проблема в том, что я могу потерять информацию об исключениях на уровне сервиса.

Ответы [ 2 ]

3 голосов
/ 12 декабря 2011

Вы должны по крайней мере log ваше исключение где-либо (журнал событий, файловая система, используя Elmah и т. Д.).

Проблема с вашим кодом заключается в том, что вы никогда не узнаете, случилось ли что-то плохое в производственной среде, или вы не сможете обнаружить, что именно вышло из строя (просто код вернул false).

Кроме того, вы никогда не должны обрабатывать все исключения, как вы (нефильтрованный улов), а только то, которое вы можете вернуть в нормальное состояние.Гораздо лучше позволить сбою приложения, чем поддерживать нестабильность его работы в сети.

Избегайте обработки ошибок, перехватывая в приложении неспецифические исключения, такие как System.Exception, System.SystemException и т. Д.код.Есть случаи, когда обработка ошибок в приложениях является приемлемой, но такие случаи редки.

См. Эту статью MSDN о передовых методах обработки исключений и Рекомендации по разработке исключений

1 голос
/ 12 декабря 2011

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

Я бы по-прежнему возвращал true или false, чтобы указать, была ли операция создания успешной.Тем не менее, я добавлю try / catch в вызывающую программу, чтобы убедиться, что исключения обрабатываются.В вашем случае это может быть в вашем действии контроллера (или OnException в вашем базовом контроллере).

Другой подход состоит в том, чтобы оставить try / catch в вашем методе Create, но @Stephane предложил что-то с ним сделать (например,регистрируйте его), но вы также можете регистрировать его везде, где вы его ловите.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...