When working with web services, is it a good practice to have some sort of converter that converts the object from the web service to your domain object even if they have almost the exact properties? If it is not a good practice, why not?
Share
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.
When working with web services, is it a good practice to have some sort of converter that converts the object from the web service to your domain object even if they have almost the exact properties? If it is not a good practice, why not?
I generally do this conversion in my code primarily because I prefer to completely abstract the web service and any evidence of it, essentially not wanting to use the objects exposed by the service in my domain. Tools such as AutoMapper are useful in this practice, though I often just do it manually. My preference is just to abstract the external web service behind an internal service or repository interface and have as little code actually depend on the external service as possible (even if the service is also one I wrote and is being used in the same enterprise environment).
Just think of it from the perspective of future re-factoring. If anything in the service ever changes, how much of the consuming application’s code will be affected?