.NET Service burden of using Entity Translator

We have incremental burden of maintaining EntityTranslator to transform the business messages to the service message and service message to business message in .NET and WCF application. In fact, I cannot call them as Business object since we just need to fetch from DB and update the same. We read data from device and store to DB and read data from 开发者_运维百科DB and store to device.

All our classes are simple, plain .NET classes and doesn't do anything specific.

It is very similar classes.

Here is my service entity.

[DataContract]
public class LogInfoServiceEntity
{
   string data1;
   string name;
}

public class  LogInfo
{
   string data1;
   string name;
}

Now I need to define the translator just to create the instance type of other side and copy the data other side. We have around 25 classes like this and we feel, very difficult to manage them. So we have 25 Business to Service translator and 25 Service to Business Translator.

I like to have simple POJO kind of classes to store and get the information than using all the translator.

What is the best way to handle the situation? Or Is translator is the best way to handle the situation?

---

Automapper might be what you're looking for.

---

The answer is "it depends". It solely depends on the complexity of your system. Usually WCF service interfaces should be coarse grained and not necessarily map one-to-one to your business layer entities to prevent additional round-trips to server.

For instance, Customer entity in WCF interface can convey much more information, even not related directly to Customer entity in business layer. But you return this information additionally because you predict that in 85% of situations client will not only need Customer data, but also all orders/activities or any other supplementary information within next several minutes.

This is usual trade-off - whether to return more or less.

In your particular case I would stick with code generation: you can always write a tool which will generate all external interfaces and translators out of business logic entities.

---

This may be a daft question, however why don't you

Use the same classs for the DataContract as you use for the "business messages"?

Normally you keep your contracts separate so you can change your business objects without effecting your data contracts, however what benefit do you get from keeping them separate?