Thanks for the comment. That’s a cool approach.. If you blog about it, be sure to link from this post. Theoretically I’m a big fan of IoC like this, but practically I find that the data translation layer doesn’t change that often. However, every app is different and if it’s an easy pattern to implement the added flexibility is definitely a nice-to-have.

Thanks again
-adam

Very nice example, and thank you for taking the time to post on Cairngorm related topics – as there hasn’t been much blogging going on in this space for some time.

I essentially use the same pattern of data translation and abstraction but with a factory implementation. Whats nice about this approach is you can leverage Dependency Injection to configure the Factories, so for example, if we needed to translate our domain models to another format other than XML we can do so by changing the Factory implementation via the IoC container. In this way client code need not be modified as the change would be implemented transparently to the clients implementation.

Best,
Eric

Well… you really can’t. If you want typed objects, you need to know the schema before compile time.

Yeah man.. a proxy technique is great in this case. The only gotcha is if you have large volumes of data you’ll use even more ram due to the additional object instances for all the proxies.

Optimization is always a trade off. In the wrapper solution you use more ram but defer execute. In the data translator solution more processor time is used up front with the gain of less ram used and faster access to the data.

As I said in the post, a good engineer considers the many viable solutions to this problem on the basis of what you’re trying to accomplish in your application.

Cheers
-adam