• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

WCF: DataMember attribute on property vs. member

开发技术 开发技术 5小时前 3次浏览

遇到的问题,property的get有逻辑,然后DataMember给了field

这种情况,应该把DataMember给property,可以确保触发get的逻辑

 

 

WCF: DataMember attribute on property vs. member

In general, you should favor applying the DataMember attribute on the property, rather than on the private field. The only reason to apply the attribute to the field instead is if the property were read-only (i.e. it has no setter).

 
评论:
It’s also useful to put the DataMemberAttribute on a field if your property’s getter/setter has any code that might alter its value. – rossisdead May 21 ’10 at 3:28
@rossisdead Except where this may be the intended behavior. – Tri Q Tran Nov 9 ’12 at 4:40
 
 

WCF: Exposing readonly DataMember properties without set?

 

Your “server-side” class won’t be “made available” to the client, really.

What happens is this: based on the data contract, the client will create a new separate class from the XML schema of the service. It cannot use the server-side class per se!

It will re-create a new class from the XML schema definition, but that schema doesn’t contain any of the .NET specific things like visibility or access modifiers – it’s just a XML schema, after all. The client-side class will be created in such a way that it has the same “footprint” on the wire – e.g. it serializes into the same XML format, basically.

You cannot “transport” .NET specific know-how about the class through a standard SOAP-based service – after all, all you’re passing around are serialized messages – no classes!

Check the “Four tenets of SOA” (defined by Don Box of Microsoft):

  1. Boundaries are explicit
  2. Services are autonomous
  3. Services share schema and contract, not class
  4. Compability is based upon policy

See point #3 – services share schema and contract, not class – you only ever share the interface and XML schema for the data contract – that’s all – no .NET classes.

 

 

WCF DataMember attribute for read-only fields?

 

Generally speaking, your data contract classes should be very lightweight data transfer objects without any logic or deeper meaning attached to them. Just containers to ferry data across the cloud. They should be public classes, with just a set of public read-write properties. In your business logic classes, you should convert these into some internal business entities and do the reverse when transmitting data.

This separates the data transfer model from any internal entity model and ensures optimal maintainability, allowing you to avoid problems such as the one you are facing – where OO design issues conflict with WCF operating behavior.

With very small projects the overhead of keeping a separate model might not be worth it. AutoMapper can be of some help minimizing the manual labor required.

Speaking of your specific scenario, I am not sure I exactly understand the problem statement. You do not want some field to be modified? But this field is just a part of the data model – parts of the data model are never “modified” – there is no “old” data, just data your client makes up. Your client code just sends a data object to the server. If the server does not care about one member of the class, it should just ignore it.

It’s not like instnaces of the data contract objects exist on the server and wait for clients to manipulate them. A read-only field might conceptually make sense in such a scenario but this is not so with WCF. The client just makes up an object and sends it to the server. If you do not want the server to listen to some data, either do not add it to the data model or (if perhaps it is sometimes needed, only for specific users or such) make the server ignore it when it is not desired.

 

 

DataMember attribute on private members – Whats happening under the hood

You can access non-public members via the .NET reflection API. For this reason, although public/private/internal modifiers imply some sort of security, they should really be thought of as organizational in nature, since they are easily circumvented by reflection.

WCF: DataMember attribute on property vs. member


程序员灯塔
转载请注明原文链接:WCF: DataMember attribute on property vs. member
喜欢 (0)