Perceived Inefficiencies in Data translation in web Services

Question

I have been writing web services for about a year now and it seems that the process I use to get data from the Database all the way to display to the user and back again has some inefficiencies.

The purpose of this question is to make sure that I am following best practices and not just adding extra work in.

Here is the path for data from the DB, to the end user and back.

1. Service gets it from the database into a Data Access Layer (DAL) object.
2. Service Converts it to a DataContract to send to the client.
3. Client gets the DataContract and converts it to a client side object
4. Client displays the object / the user makes changes / objects are added
5. Client converts the client side object to a DataContact and sends it to the Service
6. Service recives the DataContract and converts it to a Data Access Layer object.
7. Service updates the Database with the changes/new objects.

If you were keeping track the object is converted 4 times (DAL->Contract->Client Object->Contract->DAL). That seems like a lot of conversions when your app starts to scale out it's data.

Is this the "Best" way to do this? Am I missing something?

In case it matters, I am using Visual Studio 2008, WCF, LinqToSQL and Windows Mobile 5.0 (NETCF).

Answer 1

You may be missing the issue of what happens if you reduce the number of conversions (that is, if you couple the layers more tightly together).

The service could directly return a DAL object. The problem is that DAL objects are likely to contain data that is about the fact that they are DAL objects, and not about the data they carry. For instance, LINQ to SQL classes derive from base classes that contain LINQ to SQL functionality - this base class data is not required on the client, and should not be sent.

The client could directly use the DAL object sent back from the server. But that requires the client and server use the same platform - .NET, for instance. They would also have to use compatible versions of .NET, so that the client can use the server-side DAL object.

The client could now display the DAL object however it likes, assuming it doesn't need client-side interfaces like INotifyPropertyChanged, The server doesn't need such code to run, but the client might need it for data binding and validation.

Note that each layer contributes its own requirements. By keeping these requirements independent, the code is easier to design and maintain. Yes, you have to do some copying of data, but that's cheap compared to the cost of maintaining code that has to do four different things at the same time.