是否可以在SOAP Web服务中创建只读元素？ [英] Is it possible to create read only elements in SOAP web services?

问题描述

我有一个定义了只读属性的类。在我的代码中，我将此定义为仅具有getter的属性。

I have a class with a read-only property defined. In my code I define this as a property with a getter only.

我希望能够通过Web服务来回发送该对象。当我在服务中调用 Get方法时，将在服务端填充一个值。定义此属性后，我不希望Web服务的使用者能够设置/更改此属性。

I want to be able to send this object back and forth across a web service. When I call a "Get" method in the service, it would be populated with a value on the service side. Once I define this property, I don't want the consumer of the web service to be able to set/change this property.

当我添加对此Web的引用时服务到项目，该对象的属性具有几种不同的序列化方式，具体取决于我如何在服务端定义对象：

When I add a reference to this web service to a project, the object has the property serialized a few different ways depending on how I try to define the object on the service side:

• 内部设置器：在WSDL中创建属性。 Visual Studio会同时使用getter和&此属性的设置器。


• 无设置器：不在WSDL中创建属性。然后，Visual Studio显然根本不会定义该属性。


• 只读的公共成员变量-不会在WSDL中创建该属性。再次，Visual Studio将对该属性不做任何事情，因为它不知道该属性。

• internal setter: Creates the property in the WSDL. Visual Studio generates a class with both a getter & a setter for this property.
• no setter: Does not create the property in the WSDL. Visual Studio then obviously does not define this property at all.
• Read-only public member variable - Does not create the property in the WSDL. Again, Visual Studio will not do anything with this property since it doesn't know about it.

允许使用Web服务的用户为该属性设置值不会造成任何伤害。如果设置了该值，则在Web服务端将其忽略。我只希望消费者不能更改/设置该属性以使其开始。

Allowing the consumer of the web service to set a value for this property will not cause any harm. If the value is set, it is ignored on the web service side. I'd just prefer if the consumer can't change/set the property to begin.

是否可以将属性定义为只读？目前，我们正在为Web服务使用C＃/。NET 2.0，并且（至少到目前为止）我们可以控制该服务的所有使用者，因此我可以尝试根据需要更改配置，但我更喜欢仅更改

Is there any way to define a property as read-only? Right now we're using C#/.NET 2.0 for the web service, and (for now at least) we have control over all of the consumers of this service, so I can try changing configurations if needed, but I prefer to only change things on the web service and not the consumers.

推荐答案

我是Java专家，所以我回答的第一部分重点是

Caveat, I am a Java guy so the first part of my answer focuses on what may be possible in C#.

首先，使用Java中的自定义序列化程序，您几乎可以执行任何操作，包括直接设置受保护或私有字段的值。只要安全管理器不会阻止此活动，就可以使用反射。我不知道C＃中是否有用于安全管理器，字段访问和自定义序列化程序的类似组件，但我怀疑有这些组件。

Firstly, with a custom serializer in Java, you can do almost anything you want, including directly setting values of a protected or private field using reflection so long as the security manager doesn't prevent this activity. I don't know if there are analogous components in C# for the security manager, field access, and custom serializers, but I would suspect that there are.

第二，我认为在作为应用程序一部分查看Web服务和Web服务接口方面存在根本差异。右键单击从现有代码（称为代码优先）生成Web服务接口。关于WSDL首先是首选方法的文章很多。 这一个很好地总结了一些事情，但是我也建议您阅读其他书籍。当您考虑Web服务的客户端和服务器端之间的共享代码库并维护对象结构和可访问性时，一旦将API发布为Web服务并且没有控制权，就无法获得这种保证。所有的消费者。 WSDL和XSD充当Web服务API的通用描述，并且可以使用不同的数据绑定配置，对象类或语言来实现服务器和客户端。您应该将Web服务接口以及您传入和传出的XML描述为交换的语义，但不必将数据（您的类结构）在客户端中进行内部化（反序列化）后的语法进行描述。

Secondly, I think there is a fundamental difference in how you are viewing Web services and the Web service interface as part of your application. You are right-click generating the Web service interface from existing code - known as "code first". There are many articles out there about why WSDL first is the preferred approach. This one summarizes things fairly well, but I would recommend reading others as well. While you are thinking in terms of a shared code library between the client side and server side of your Web service and maintaining object structure and accessibility, there is no such guarantee once you publish an API as a Web service and don't have control over all of the consumers. The WSDL and XSD serve as a generic description of your Web service API and your server and client can be implemented using different data binding configurations, object classes, or languages. You should think of your Web service interface and the XML that you pass in and out of it as describing the semantics of the exchange, but not necessarily the syntax of the data (your class structure) once it is internalized (deserialized) in your client or server.

此外，建议将与传输相关的结构与内部业务逻辑结构分离，以免发现自己不得不重构服务器实现和Web服务。 API，以及您（和其他人）的客户端实现都在同一时间。

Furthermore, it is advisable to decouple your transport related structures from your internal business logic structures lest you find yourself having to refactor both your server implementation, your Web service API, and your (and other's) client implementations all at the same time.

这篇关于是否可以在SOAP Web服务中创建只读元素？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！