Estoy con la capa de servicio de una aplicación en la que estoy trabajando y estoy aplicando los principios de DDD.
Cuando me he planteado llamar desde el cliente al servicio en un principio me plantee devolver un ValueObject como respuesta, pero cual fue mi sorpresa cuando me di cuenta que eso no era posible.
Un ValueObject debe ser inmutable, y resulta que el WebService trata de reconstruir el objeto en el destino... ESO NO ES POSIBLE, ya que el ValueObject al ser inmutable no le va a permitir setear los parametros (No tiene un constructor por defecto ni tampoco los métodos setter).
Eso me ha hecho documentarme un poco y darme cuenta que en general hay una equivocación extendida entre el patrón "Data Transfer Object" y el patrón "Value Object".
Ambos sirven para reducir la carga en la transferencia de datos entre capas de aplicación, pero como he dicho antes mientras que un DTO es MUTABLE un ValueObject debe ser utilizado en aquellas zonas de la aplicación donde se necesite que el objecto sea INMUTABLE.
Lo mas probable es que la situación requiera un transformador entre el DTO y el VO. El WebService devolvería un DTO y en el cliente se crearía a través de una factoría los Value Object necesarios.
Para ponerle la guinda a esta discusión, resulta que Martin Fowler después de aclarar la distinción entre ambos le cambia el nombre a los Value Object y nos quedamos con que tenemos que distinguir entre... agarrate que vienen curvas: Data Transfer Object y Transfer Object. ¿No podrían haberse estrujado la cabeza para que formalmente se llamaran de manera totalmente diferente? Con esos nombres no me extraña que la gente se haga un lio.
Referencias:
Data Transfer Object (Martin Fowler)
Value Object (Martin Fowler)
Blogs sobre el tema
http://rrees.wordpress.com/2007/05/13/transfer-objects-versus-value-objects/
http://www.adam-bien.com/roller/abien/entry/value_object_vs_data_transfer
No comments:
Post a Comment