支持使用面向服务的体系结构传输富对象的设计模式？

Question

I have an Employee class that lives on the server and I wish to expose it in a web-service so that it can be consumed by a client.

Here is my class:

public class Employee
{
    public CountryCode { get; private set;} 
    public EmployeeType {get; set;}

    public bool IsTaxable
    {
       get
       {
           return (CountryCode != Codes.CaymanIslands 
                  && Status != EmployeeType.Contract);
       }
    }

    public void Employee(EmployeeType type, CountryCode code)
    {
        EmployeeType = type;
        CountryCode = code;
    } 

    private void Employee() {}
}

The private constructor and private setters help this class to be strongly typed, adhere to the DRY principle and also ensure it can only be instantiated in a valid state.

For example, I ensure that IsTaxable is not set in the constructor but is dynamically evaluated based on the other class properties. In this way, if EmployeeType is modified the result of IsTaxable will reflect this change. I use this simple example to highlight the fact that this object is rich in logic.

Let's say that this Employee class lives on the server and I wish to gain access to it on the client. I build up a WebService (in .NET I'll use WCF), expose the class and using the out-of-the box tools connect and am able to use this class across the wire in my client.

The problem is that, doing so, will result in me losing most of this encapsulated logic . At the receiving end, the client cannot see this rich class with it's private setters, it's hidden constructor, the logic in the IsTaxable property, etc. Instead, at client-side I will see a lightweight class like this:

public class Employee
{
    public CountryCode { get; private set;} 
    public EmployeeType {get; }
    public bool IsTaxable {get; }
}

It is now possible for the client to instantiate the class in an invalid state by doing something like this:

Employee e = new Employee();
e.EmployeeType = EmployeeType.Contractor;
e.IsTaxable = true;

Is the loss of the rich object just a fact of service-oriented life and something that we have to live with?

Are such service transferred objects to be seen as weak data transfer entities solely for the purpose of transmitting information and should be read-only.

At the client side should you (if required) wrap these in richer objects?

Is there any method of passing logic-intact rich objects across a wire or is there really a need to?

Are there any established patterns for dealing with such scenario?

Answer 1

Before looking at design patterns, the first thing you need to look into is where you actually want the logic to take place, and what actually happens if a 'rogue' client changes the data it is receiving over the wire.

The way most client-server architectures are designed is that whatever the client tries to do has to be validated by the server. So if the client decides to change IsTaxable to true, or change the Employee's name or ID etc., its won't have any effect on the real data that is stored on the server side. The client has to perform an operation to update the data on the server and only if he has the right to do so will that data be propagated to the database and the rest of the system.

The client is always 'at risk' (it can be manipulated by the user, hacked by hackers, sniffed over the wire etc.) so the server must be secure enough to withstand such situations.

'Transfer Objects' are normally just intended to carry data. Any logic is then either performed by the client (for example formatting data to a more user-friendly presentation), or by the server. If the clients needs to perform operations on the data then it needs to ask the server to do it (so that it is updated centrally).

So in your case, your webservice needs to expose operations for your clients to perform any logic you might need.

One other thing you might want to look at is how to create Contract First web services. This is considered a best practice, because it not only ensures your web services are interoperable with other platforms (eg Java), but also makes you think in terms of what operations and data you want to expose to your clients, and helps you avoid making mistakes (like expecting instances of objects which only the server has access to).

Contract First means that you create your WSDL describing your operations and XSD describing the messages and objects to be transferred in XML. They you just generate your code automatically from those WSDL and XSD documents.

Answer 2

You can't do this for an arbitrary client, but if you control both client and server, you can add a reference to the assembly containing your Employee class to the client, then reuse this type for the WCF contract.

In Visual Studio, you can do this with "Add Service Reference" / "Advanced" / "Reuse types in referenced assemblies".

Is the loss of the rich object just a fact of service-oriented life and something that we have to live with?

Yes, this is true. In a true service-oriented architecture, you don't share behavior between client and server, only exchange messages. But if you're using WCF in a client-server architecture where you control both sides, you can use the above approach.