Entity translators???

Topics: User Forum
Jan 26, 2007 at 4:26 PM
Could somebody explain me what the entity translators are and how they work?

TIA
Jan 26, 2007 at 10:02 PM
The entity translators convert one object type into another object type. They are used in the reference architecture to convert wire-format entities to business entities.

In other words, entities that are returned by Web Service calls (such as AccountService.AccountTableEntityType) are converted into Business Entities used internally in the solution (such as Account).

This means that a layer of abstraction between the solution and the services it calls is enforced.

You'll also find entity translation in the Web Service Software Factory.

Hope that helps

Simon
http://www.dotnetblogs.co.uk/
Jan 27, 2007 at 10:38 AM
Thanx for your short explanation. But doesn't create this an performance penalty?
Jan 27, 2007 at 11:14 AM
I think a lot of modern design techniques trade off memory usage and processor cycles against maintainability, clarity of design, flexibility, etc etc. In particular this entity translation approach helps shield changes to your web service from the web application.

The fact is memory and processors are cheap nowadays - when compared with the cost of correcting faulty software, especially if it is badly written.

Therefore my vote is always for this kind of pattern - in reality the amount of processing and memory consumption we're talking about for entity translation is absolutely tiny for most systems.

I would be very surprised if you could get a measurable and significant performance difference between two solutions; one using patterns such as this, and one avoiding.

Also, as long as the "critical" sections of code are well written (i.e. transaction locks etc) you can always add processors, memory, and servers to scale... in real terms this will cost you much less than trying to maintain a solution that has not been sufficiently "engineered".

For example, if the web service contract changes (say just a data type) and you've used entity translation, you can potentially avoid changing any of your solution other than updating the web reference and modifying the entity translator... without using entity translation this could propogate throughout your whole solution; much more expensive to make the change, more expensive to test, and much more risky to the integrity of your application.

That's my vote anyway! Anyone else got any thoughts?

Simon
http://www.dotnetblogs.co.uk/
Jan 29, 2007 at 7:07 PM
This pattern also helps protect the consumer from changes in the entities returned by the other services (the web services in this case).

If you imagine the typical enterprise with 10-20 different teams doing differnt things. Say one team provides a web service for storing, retrieving, and editing Customers. Ten other teams consume this web service. At some point a new field is added to the customer interface. In this design, if the new field is not needed by a consumer, the changes necessary to ensure the consumers app continues to work are minimal (if needed at all). If this layer of abstraction did not exist, it is possible that almost every use of a Customer in the consumer app would need to be changed or updated.

Of course, there are other reasons for the pattern, but this is what I see as the biggest (as a lazy developer who hates re-writing code when someone upstream changes something minor).
Jan 31, 2007 at 11:03 PM
Don Smith from Web Service Factory explains quite well in his Blog Cast about how it works. Although this blog cast walkthrough the Web Service Factory implementation of the Entity Translation but there are 90% of stuff valuable in general. Take a look of http://blogs.msdn.com/donsmith/archive/2006/04/28/586339.aspx

Copied from this above URL:

Service Factory: Entity Translation
For the third installment I've decided to talk about the entity translation (mapping) capability of the guidance package. Specifically, this is mapping between the entities that are deserialized to/from the wire representation and the entities that represent the business domain model.