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):
- Boundaries are explicit
- Services are autonomous
- Services share schema and contract, not class
- 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.
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.
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):
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.