WCF：抑制FaultExceptions &对象数据源绑定
我设计了一个 Web 服务，在每次方法调用时，如果请求成功执行，它将返回某种类型 T 的结构，否则抛出 FaultException 向客户端发出一些错误信号。其中一个客户端应用程序是一个 ASP.NET 应用程序，其中有一堆直接与服务方法相关联的 ObjectDataSource 对象。这些对象将负责处理诸如 GridView 分页或 DropDown 自行填充之类的事情。
不幸的是，我刚刚被命令从服务中删除所有 FaultException 并将我返回的类型包装到通用 ServiceResponse 结构中，该结构包装了原始返回结构输入 T 并添加更多字段来传输异常信息。由于别无选择，我立即执行此操作，并将所有旧的服务代理调用替换为对通用 ExecuteMethodObjectDataSource 绑定到它，并且 GridView 自动分页消失了。
由于 ObjectDataSource 不支持泛型方法，也不支持泛型类，而无需对我想避免的程序集限定类型名称进行大量修改，因此我只剩下 GridView 任一页面的选项手动，我也想避免，或者编写代理来包装每个必要的服务调用并返回所需的值，这就是“包装包装器”。你能帮我决定哪一个不会是最糟糕的吗？在这种情况下我还有其他选择吗？
I had designed a web service which, upon each method call, would return a structure of some type T if the request were successfully conducted, or otherwise throw a FaultException to the client to signal some error. One of the client applications was an ASP.NET application with a bunch of ObjectDataSource objects directly tied to the methods of the service. Those objects would take care of things such as GridView paging or DropDown populating for themselves.
Unfortunately, I was just now ordered to remove all FaultException from the service and wrap the types I was returning into a generic ServiceResponse<T> structure which wraps the original return structure of type T and adds some more fields to transmit exception information. Having no other choice, I did this right away and replaced all the old service proxy calls with a call to a generic ExecuteMethod<TChannel, TReturn> method which takes care for itself of unwrapping the value if the request was successful or throw some exception otherwise. The problem now is that, since this new method is generic, I can't tie an ObjectDataSource to it, and GridView automatic paging is gone.
Since ObjectDataSource doesn't support generic methods, nor it supports generic classes without a lot of mangling with assembly-qualified types names which I would like to avoid, I am left with the options of either page the GridView manually, which I would like to avoid as well, or writing a proxy to wrap every necessary service call and return the desired value, which then is "wrapping a wrapper". Can you please help me decide which one will not be the worst? Do I have any other options in this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我更喜欢您所说的“包装包装器”方法。从架构上来说，它是完全有效的，因为每个人都有单一的责任。
如果服务合同不稳定，维护起来会很痛苦，但在相同情况下，它可能比程序集限定名称方法更易于维护。
（咆哮：顺便说一句，我相信“命令”您从服务中删除故障的人了解这将对服务的互操作性产生的影响。此外，该方法允许服务实现者和消费者在以下情况下陷入困境：他们无法正确实现您的新专有协议，因为您所更改的只是在客户端将故障转换为异常的机制。）
I prefer the "wrapping a wrapper" approach as you call it. Architecturally it's entirely valid since each has a single responsibility.
It will be a pain to maintain if the service contract is not stable but it's probably more maintainable than the assembly qualified name approach will be in the same circumstances.
(RANT: As an aside I trust the person who "ordered" you to remove the Faults from the service understands the impacts this will have on interoperability of the service. Also, the approach allows the service implementors and consumers to get themselves into difficulty if they fail to properly implement your new proprietary protocol. It seems like it doesn't actually achieve anything anyway since all you're changing is the mechanism by which a Fault gets converted to an Exception at the client.)