Comments 18
UFO just landed and posted this here
Считаю, что использование 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 и т. д.).
И ещё немного про предложенную валидацию:
Считаю, что лучший вариант — это использование фабрики валидаторов, построенных по паттерну композит. Каждый валидатор проверяет на свои условия и возвращает результат проверки главному объекту. В итоге мы получим результат проверки со всеми ошибками, если они произошли.
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 собирать. И приходится думать…
Но топик действительно не об этом, просто это был первый попавшийся более-менее подходящий пример :)
А в остальном — я с вами соглашусь.
Валидаторы вообще в принципе должны быть написаны на клиенте и в логике представления.
А вот по поводу метода тут думать надо.
Чаще всего хочется, чтобы RegisterUser возвращал сущность зарегистрированного юзера
public User RegisterUser(string username, string password, string email)
Тогда сложнее нам OperationResult собирать. И приходится думать…
Но топик действительно не об этом, просто это был первый попавшийся более-менее подходящий пример :)
вы не сможете сделать проверку Login,Password если WCF сервис имеет SecurityContext, т.к. все запросы к нему должны быть авторизованы до того, как ваш метод вызовется, поэтому в этом случае только FaultException
catch (InvalidUsernameException usernameException)
{
// даем знать пользователю что Password произошла ошибка связанная с Email
}
Похоже у вас небольшая опечатка в комментариях, Email вместо Username. Подправьте если не сложно для целостности ). А вообще-с интересом прочитал, метод для меня, в принципе, нов, с wcf только начинаю работать, спасибо за статью.
{
// даем знать пользователю что Password произошла ошибка связанная с Email
}
Похоже у вас небольшая опечатка в комментариях, Email вместо Username. Подправьте если не сложно для целостности ). А вообще-с интересом прочитал, метод для меня, в принципе, нов, с wcf только начинаю работать, спасибо за статью.
почему сегодня нет темы про ямабилко?
UFO just landed and posted this here
а я по простоте душевной, когда впервые пробовал работать с WCF, посылал исключения как просто так, черех trow и сервис после этого менял статус на fault :) так я вместо того чтобы найти иной способ бросать исключения, просто после срабатывания исключения менял статус сервиса :)
А вообще, как тут уже некоторые говорили, лучше всего использовать свои классы результатов типа CallResult и т. п.
А вообще, как тут уже некоторые говорили, лучше всего использовать свои классы результатов типа CallResult и т. п.
Раз уже вы затронули такую тему, то что произойдет на клиенте, когда в методе RegisterUser на сервере произойдет неучтенный exception? В каком состояние будет channel? Раз уже упомянули FaultContract, тогда расскажите и про MapExceptionToFault и IErrorHandler. Хотелось бы еще услышать, как клиенту узнать что его channel faulted, и что делать в этом случае.
Sign up to leave a comment.
Exceptions through WCF