WCF - накладные расходы на выброс исключений FaultExceptions в вашем сервисе

Я разместил вопрос об использовании сообщений и исключений сбоев для обмена бизнес-правилами между службами.

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

Но это заставило меня задуматься о генерации исключений в целом или, более конкретно, о создании исключений FaultExceptions.

Теперь в моих услугах, если я использую

throw new FaultException

сообщить простое бизнес-правило, такое как «Ваша учетная запись не активирована», Какие накладные расходы теперь возникают? Это те же накладные расходы, что и создание обычных исключений в .NET? или служба WCF обрабатывает их более эффективно с помощью контрактов на сбой.

Итак, в моем примере с пользователем, это оптимальный / предпочтительный способ написать мой метод обслуживания

вариант а

public void AuthenticateUser()
{
    throw new FaultException("Your account has not been activated");
}

вариант б

public AutheticateDto AutheticateUser()
{
     return new AutheticateDto() { 
          Success = false,
          Message = "Your account has not been activated"};
}

exception optimization wcf
person WebDude    schedule 19.09.2008    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Что ж ... В общем, вы не должны выбрасывать исключения для ожидаемых условий или чего-то, что, как вы ожидаете, должно происходить регулярно. Они намного медленнее, чем обычные методы. Например, если вы ожидаете, что при открытии файла произойдет сбой, не передавайте это исключение вызывающей стороне, передавайте обратно код ошибки или предоставляйте метод «CanOpenFile» для выполнения теста.

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

Честно говоря, при небольшом количестве звонков вы, вероятно, не получите заметного удара, но в любом случае это не лучшая идея. Кто хочет поместить бизнес-логику в блок catch :)

Microsoft: исключения, производительность и альтернативы

Developer Fusion: Performance, с примером

person Andrew Backer    schedule 19.09.2008

arrow_upward
0
arrow_downward

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

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

person blowdart    schedule 19.09.2008