WCF: подавление исключений FaultException и ObjectDataSource

Question

Я разработал веб-службу , которая при каждом вызове метода возвращала бы структуру некоторого типа T, если запрос был успешно выполнен, или иначе выдала бы клиенту FaultException сигнализировать об ошибке. Одним из клиентских приложений было приложение ASP.NET с кучей ObjectDataSource объектов, напрямую связанных с методами сервиса. Эти объекты будут заботиться о таких вещах, как подкачка GridView или заполнение DropDown для себя.

К сожалению, мне только что приказали удалить все FaultException из службы и обернуть типы, которые я возвращал, в общую структуру ServiceResponse<T>, которая оборачивает исходную структуру возврата типа T и добавляет еще несколько полей к передавать информацию об исключениях. Не имея другого выбора, я сразу же сделал это и заменил все старые вызовы прокси-служб вызовом общего метода ExecuteMethod<TChannel, TReturn>, который позаботился о том, чтобы развернуть значение, если запрос был выполнен успешно, или вызвать другое исключение в противном случае. Теперь проблема в том, что, поскольку этот новый метод является общим, я не могу привязать к нему ObjectDataSource, и автоматическое разбиение по страницам в GridView пропало.

Поскольку ObjectDataSource не поддерживает универсальные методы, а также не поддерживает универсальные классы без большого количества искажений с именами типов, соответствующих сборке, которых я хотел бы избежать, у меня остаются параметры любой страницы GridView вручную, чего я также хотел бы избежать, или написания прокси, чтобы обернуть каждый необходимый сервисный вызов и вернуть желаемое значение, которое затем является «оберткой». Можете ли вы помочь мне решить, какой из них не будет худшим? У меня есть другие варианты в этом случае?

Answer 1

Я предпочитаю подход "упаковка в оболочку", как вы его называете. С архитектурной точки зрения это совершенно справедливо, поскольку у каждого есть отдельная ответственность.

Поддерживать будет сложно, если контракт на обслуживание нестабилен, но, вероятно, его легче поддерживать, чем подход с подходящим именем сборки в тех же обстоятельствах.

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