Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I am implementing a SOAP-Webservice which receives different Requests. Should my Manager-class transform this Request objects into an internal representation before delegating them to implementation classes?
I think this would be a good idea concerning decoupling. But doing this I have to create a copy of each RequestObject class and name it InternalRequestObject which stores the same data as the original Request.
Does this make sense?
It makes sense if you intend to reuse those implementation classes which I would call your business layer.
In your current setup, you have the business layer exposed as a web service. The skeleton of the web service is – if you will – a client for your business layer.
Now the question that arises is: should your business layer care what kind of clients it will have? Should the data contract of the business layer be dictated by the clients, or should the clients respect the data contract exposed by the business layer?
The obvious response is the clients should respect the data contract of the business layer, so the answer to your question would be: Yes, you should map the SOAP requests to an internal request type used by the implementation classes in order to obtain a better decoupling between the two.
There is only one case in which I would consider using the request types directly all the way down into my business layer: If I would be absolutely (101%) sure that I will never have to expose my business layer as anything else than a SOAP web service.
The idea is that you only have two main options at this:
1. keep the same request type all over the place. The disadvantage to this is that you will suffer a lot of rewrites ripping through your business layer if at some point you have to add other (non SOAP) clients.
OR
2. map the SOAP request type to an internal type. The disadvantage to this will be that you risk duplicating code and working extra just to find out at the end that all was for nothing and you didn’t need to add other clients after all.
Think about your situation and choose carefully! But I must tell you that, personally, I haven’t encountered the disadvantage of number 2 so far. I always ended up adding new clients to the thing and at that point it helped having mapped the types from the very beginning.