Reviewing Workshop Day One Exercises...

Topics: Web Client Software Factory
Jun 5, 2007 at 4:39 PM
In the section on Using the ObjectContainerDataSource and under Task 5, there is a statement that the workshop solution uses the entity defined by the web service proxy class. In most cases you should consider defining a data contract forthe service and translating between your business entities and the data contracts required for the service.

Is there an example somewhere of this?

Jun 6, 2007 at 3:30 AM
Without going into too much detail, thats mostly discussed in the Web Service Software factory. All it is really, is that your client has its own "version" of the object returned by the web service, and then you have an object with a static method, that takes into parameter the web service proxy class, push its data into the client version, and return it. And vice versa.

That way, if the web service changes in nature, which it most likely will, you don't have to do a huge refactoring job. In the WSSF, you have automated guidances for creating all that stuff easily.
Jun 6, 2007 at 1:39 PM
Hmmm...wonder if there is an easy way to integrate the WSSF with WCSF. At least the peice of WSSF that handles the translation.
Jun 6, 2007 at 2:30 PM

Take a look at the Global Bank Reference Implementation included in the WCSF Source Code. In the project EFT.ServiceProxies you will find the entities translator the application use to translate the data contract to a business entities and a business entities to a data contract.

BTW - To know how to integrate WSSF with WCSF you can read this: Creating the Reference Implementation using WCSF and WSSF
Let me know if this helps,

Ezequiel Jadib
Jun 6, 2007 at 4:21 PM
Edited Jun 6, 2007 at 4:27 PM
Your services will be driven by a load of objects that you may not want to expose fully to the client. Additionally your objects may change due to requirements which may mean reworking the client. The idea between DTOs (Data Transfer Objects) is to provide a contract that is less likely to change.

Think to yourself, do you need that in your scenario? Creating a whole load of translators and data types could well be a waste of time and effort and will add to complexity. What do you gain from implementing this in relevance to the application you're creating? It might not be worthwhile, but then again it might be. Make sure you understand the pattern first, and then make a decision.

If you model your objects using behavioural techniques and SRP then you will less likely need translators. You may need to change the objects at a later date but that shouldn't really involve a lot of refactoring. It's likely that any requirement changes mean that you need to refactor your data types regardless.

For the client side of things you will receive the Data Types which are nothing more than structs, or an array of structs. This to me is a downside of SOA as either you need to duplicate business logic, validation, and such on the client (duplicating code always leads to maintenance issues and bugs) or you just utilise the data types as they are and handle your logic in the views - still likely to involve a lot of duplication. You need to think of your webservices as an application and your client as a seperate application.