Este patrón es de gran ayuda a la hora de separar la manipulación de datos y acceso a la DB de la lógica propia de la aplicación. Una versión simplificada de este patrón posee tres componentes principales: El acceso a los datos El objeto de transferencia de datos (value object) El cliente que consume esos datos Antes de presentar el diagrama de clases analicemos el problema el cual consiste en encontrar una forma de manipular los datos de manera tal que el modo de acceder a los mismos sea transparente al cliente que los consume. Esto quiere decir que el cliente no tiene la necesidad de conocer cómo se acceden a los datos (SQL, conectores, motor de base de datos, tipo de base de datos, etc.). El objeto de acceso a los datos debe ser capaz de poder proveer lo que el cliente requiera y además el cliente debe poder utilizar cualquier otro objeto de acceso sin que esto afecte su lógica interna asegurando así que el sistema funcionará aún cuando se cambie de motor de base de...
Introducción La refactorización siempre es uno de los procesos de desarrollo más complejos y riesgosos, sin embargo es crucial para la evolución del software que se está desarrollando. La forma de comenzar un proceso de refactorización depende de tres factores: Madurez del equipo de desarrollo Antigüedad del proyecto y de las herramientas utilizadas Evolución del cliente Estos factores pueden propiciar el proceso o bien bloquearlo por completo. Razones por las cuales refactorizar Aquellos que piensen que una refactorización no debería suceder nunca, están equivocados, este proceso es la clave de la evolución de todo software. No es factible comenzar desde cero cada vez que hay una revolución en la tecnologia o el mercado. Basta con que el cliente decida invertir para cambiar la tecnología lo cual impacta directamente en los sistemas que tenga implementados y en consecuencia en la velocidad que nuestro producto deba adaptarse. Pero hay muchas más razones por las cuales es n...