Как стать автором
Обновить

Комментарии 18

НЛО прилетело и опубликовало эту надпись здесь
Согласен! использование try catch для обработки бизнес логики не самый красивый вариант.
Считаю, что использование Exception'ов для таких операций, как проверка логина и пароля при регистрации пользователя не совсем корректна. Для этих целей лучше использовать какие-нибудь кастомные классы, например OperationResult и ResultCode примерно так:

public OperationResult RegisterUser(string username, string password, string email) {
var operationResult = OperationResult.SuccessfulResult;

if (/*проверяем username*/)
operationResult.AddResultCode(ResultCode.UserNameError);

if (/*проверяем password*/)
operationResult.AddResultCode(ResultCode.PasswordError);

if (/*проверяем email*/)
operationResult.AddResultCode(ResultCode.EmailError);
}


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

Мне такой способ нравится больше, хотя бы потому, что если вдруг на сервере забыли поймать Exception, то всё свалится. А разве невалидный логин является критической ситуацией? Думаю нет. Это ошибка валидации. Тут нужно чётко отделять валидацию данных и критические ситуации (нет доступа к бд, null exception и т. д.).

И ещё немного про предложенную валидацию:
Считаю, что лучший вариант — это использование фабрики валидаторов, построенных по паттерну композит. Каждый валидатор проверяет на свои условия и возвращает результат проверки главному объекту. В итоге мы получим результат проверки со всеми ошибками, если они произошли.
Возможно вы и правильно считаете, но пост я написал не про то, что в таких операциях круто использовать Exceptions, а про то, как этот Exception можно отправить из WCF сервиса и поймать на клиенте.

А в остальном — я с вами соглашусь.
Валидаторы вообще в принципе должны быть написаны на клиенте и в логике представления.
А вот по поводу метода тут думать надо.
Чаще всего хочется, чтобы RegisterUser возвращал сущность зарегистрированного юзера

public User RegisterUser(string username, string password, string email)

Тогда сложнее нам OperationResult собирать. И приходится думать…
Но топик действительно не об этом, просто это был первый попавшийся более-менее подходящий пример :)
Мы в проекте используем OperationResultдля передачи сущностей. Очень удобно.
К примеру я прицепился сильно, просто наболело)
хабр схавал OperationResult <T>
Бывает :) Джуниоров гоняете?
если б джуниоров. Господа со статусом «сеньёр девелопер» иногда такое выкидывают…
Наследуете все результаты всех методов от класса OperationResult, в котором хранится свойство с одноименным enum'ом?
вы не сможете сделать проверку Login,Password если WCF сервис имеет SecurityContext, т.к. все запросы к нему должны быть авторизованы до того, как ваш метод вызовется, поэтому в этом случае только FaultException
catch (InvalidUsernameException usernameException)
{
// даем знать пользователю что Password произошла ошибка связанная с Email
}
Похоже у вас небольшая опечатка в комментариях, Email вместо Username. Подправьте если не сложно для целостности ). А вообще-с интересом прочитал, метод для меня, в принципе, нов, с wcf только начинаю работать, спасибо за статью.
Ох уж эти опечатки…
Исправил!

Всегда пожалуйста! :)
почему сегодня нет темы про ямабилко?
НЛО прилетело и опубликовало эту надпись здесь
Насколько я понял, здесь описан процесс регистрации, а не аутентификации.
А при регистрации очень даже полезно знать, что именно ты ввел неправильно.
а я по простоте душевной, когда впервые пробовал работать с WCF, посылал исключения как просто так, черех trow и сервис после этого менял статус на fault :) так я вместо того чтобы найти иной способ бросать исключения, просто после срабатывания исключения менял статус сервиса :)

А вообще, как тут уже некоторые говорили, лучше всего использовать свои классы результатов типа CallResult и т. п.
Раз уже вы затронули такую тему, то что произойдет на клиенте, когда в методе RegisterUser на сервере произойдет неучтенный exception? В каком состояние будет channel? Раз уже упомянули FaultContract, тогда расскажите и про MapExceptionToFault и IErrorHandler. Хотелось бы еще услышать, как клиенту узнать что его channel faulted, и что делать в этом случае.
состоянии*
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.