some questions regarding web service factory

Topics: General Discussion Forum
Feb 16, 2007 at 1:09 PM
Hi All,
I am developing an application using this factory, I have several questions to ask:
1, if seems that between the client and service the only object exchanging is data transfer object, but what if my business object is suitable for transfer purpose and I want to transfer the business object directly to the client side? do I have to replicate the same object as the business object but specify it in the data transfer object project so it can be transferred?
2, when could the factory support dataset (at least the support for typed dataset?) I do not care about interoperability because all the client are .net. and I do not want to use remoting
3, why between the service and the domain layer there is a bridge called service adaptor? what type of work can it do?
4, it seems we can not transfer the data transfer object either, we have to first build a request or response object and then include the dto into the request or response again, so for a simple data transfer, I need to build request/response object as well as DTO, on top of business object, is that too heavy?

thanks in advance!
Feb 16, 2007 at 10:26 PM
I'm not an expert on these matters but I can share some of my thoughts on the matter.

1. I don't think it's right or wrong to use your business entities or domain objects as DTO's. If you feel you have stable and plain entities that you wouldn't mind sharing with your consumers, go on and send them on the wire.
2. If you like to use typed DataSets, I would recommend you do as we do in our project - use DataSets internally as business entities and map them to DataContracts. Seems that you don't like the extra work of using mappers or translators, but I think it's worth it.
3. The work of the adapter is described by Aaron like this: The service adapter implements the service contract that is exposed on an endpoint (commonly referred to as the service host) and is responsible for adapting the endpoint to the underlying business layer.
4. You can use your DTO's as data contracts if you want to, just add the right attributes to them. No reason to use Request/Response data contracts as "containers" for your DTO's, even though I think it's good practice to do so. Could be useful if you want to add stuff to your DTO's without necessarily breaking the interface for your WCF clients.

I know what you're saying about the use of your internal entities as DTO's - I've done that many times in Java projects. Remember that Service Factory is just guidance, not rules. We changed the Data Access Guidance Package and used DataSets internally instead, nothing wrong with that. But I don't want to use them on the wire, so we translate them into data contracts.

Hope this helps,
Johan Danforth

Feb 21, 2007 at 4:20 PM
I'm agree with Johan, and you could also take a look at this article if you want to make sure you don't get an anti-pattern (CRUD like). On the other hand, as Pablo wrote here I think that you may have serveral kind of services and therefore you may implement your DTO with all the formal "tenets" as any other service.