服务器端和客户端WCF可以共享验证库吗？
问候！
我在应用程序服务器上使用 WCF 库，该库由 IIS 服务器（因此是客户端）引用。我想将我的验证放在一个地方，以便我可以调用 .Validate() ，它返回一个错误字符串数组（字段太短、缺失等）。问题是，这样的函数不会跨越 WCF 边界，我真的不想在 WCF 服务和 IIS/WCF 客户端中编写相同的逻辑。有没有办法使用扩展方法或类似的方法，以便双方都可以使用调用相同代码的 .Validat() 方法？
非常感谢您的任何想法！ 史蒂夫
Greetings!
I am using a WCF library on an application server, which is referenced by an IIS server (which is therefore the client). I would like to put my validation in a place so that I can just call .Validate() which returns a string array of errors (field too short, missing, etc). The problem is, such functions don't cross the WCF boundary and I really don't want to code the same logic in the WCF service and in IIS/WCF client. Is there a way to use extension methods or something similar so both side can use use a .Validat() method which calls the same code?
Many thanks for any ideas!
Steve
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您控制线路的两端，即服务器端（服务）和客户端，那么您可以执行以下操作：
ClientBase派生或通过ChannelFactory创建） - 不要使用“添加服务引用” “或 svcutil.exe！如果要使用共享验证程序集，则必须确保服务器和客户端上使用的数据类型相同 - 这只能在以下情况下完成：共享服务和数据合同。不幸的是，这需要手动创建客户端代理（这确实不是什么大问题！）。
如果您使用“添加服务引用”，则 Visual Studio 将根据其元数据检查服务，并创建一组新的客户端对象，这些对象的字段看起来相同等等，但它们是一个单独的、不同的类型，因此您无法在服务器端和客户端对象上使用共享验证。
If you control both sides of the wire, i.e. the server-side (service) and the client-side, then you could do the following:
ClientBase<T>or by creating it from aChannelFactory<T>) - do not use "Add Service Reference" or svcutil.exe!If you want to use a shared validation assembly, you must make sure the data types used on your server and client are identical - this can only be accomplished if you also share service and data contracts. Unfortunately, that requires manual creation of the client proxy (which is really not a big deal!).
If you'd use "Add Service Reference", then Visual Studio will inspect the service based on its metadata, and create a new set of client-side objects, which look the same in terms of their fields and all, but they're a separate, distinct type, and thus you wouldn't be able to use your shared validation on both the server-side and the client-side objects.
您在将数据发送到服务器进行验证时是否遇到问题？换句话说，您的服务接口实际上提供了“Validate”方法，并获取一个充满数据的数据契约，对其进行验证并返回一个列表，其中 T 是某种自定义 ValidationResult 数据契约，其中包含您需要的有关验证警告/的所有信息错误。
在服务架构中，您不能信任客户端（理论上可能是其他公司）为您完成了正确的数据验证。您始终需要在服务层执行此操作，并设计将这些验证问题传达回客户。因此，如果您无论如何都在服务器上完成这项工作，为什么不向客户端开放该逻辑，以便他们可以直接使用它呢？当然，客户端仍然可以（应该）执行某种基本输入验证，例如检查空值、空字符串、超出范围的值等，但核心业务逻辑检查应该发送给服务。
Do you have a problem with sending the data over to the server to be validated? In other words, your service interface actually offers the "Validate" method and takes a data contract full of data, validates it and returns a List where T is some kind of custom ValidationResult data contract that contains all the info you need about validation warnings/errors.
In a service architecture, you can't trust the client, who could theoretically be some other company altogether, to have done proper data validation for you. You always need to do it at the service layer and design for communication of those validation issues back to your client. So if you're doing that work at the server anyway, why not open that logic up to the clients so they can use it directly? Certainly the clients can (should) still do some kind of basic input validation such as checking for null values, empty strings, values out of range, etc, but core business logic checks should be shipped off to the service.