Tengo una clase de fábrica que rellena objetos con datos. Quiero implementar el guardado del objeto, pero no quiero rellenar el objeto con cosas db. ¿Es estúpido que mi Factory que crea la clase también guarde los datos?Clase de fábrica - Guardar objetos
ie: en mi método .Save() en el objeto que llamaría Factory.Save (myObject);
Si le preocupan las cosas de la base de datos en las clases, ¿ha considerado utilizar el asignador O/R?
Esto mantendría las cosas de la base de datos completamente fuera de su código y sus objetos de dominio limpios.
Quizás eche un vistazo a NHibernate o Active Record.
No, no es estúpido en absoluto, de hecho, esa es la forma en que todo el mundo debería hacerlo. El objeto comercial no debe contener ninguna lógica de persistencia.
Por cierto, si estás usando C# 3.0, entonces es posible que ni siquiera te molestes con la clase de fábrica. Solo crea métodos de extensión. De esta forma, aún puede tener su código de persistencia aislado de un objeto comercial y aún así poder llamar a myObject.Save().
La clase de fábrica es un patrón creacional que ayuda a crear objetos nuevos.
Hay varios patrones que se ocupan de objetos persistentes, uno de los cuales es asignador de datos http://martinfowler.com/eaaCatalog/dataMapper.html
Esto se utiliza a menudo en conjection con Repositorio http://martinfowler.com/eaaCatalog/repository.html
Puede utilizar estos patrones para abstraer la base de datos de distancia desde su dominio/objetos comerciales, y acceder a ellos desde su aplicación para consultar y guardar objetos.
Por lo tanto, el correlacionador/repositorio de datos es responsable de ambos aspectos de la persistencia (rellenando desde la base de datos y volviendo a guardar en la base de datos).
Tienes un voto positivo en la primera línea solo ... He tratado de convencer a la gente de eso desde hace mucho tiempo. – ckramer
Simplemente no lo llames fábrica después: comenzarás a confundir a las personas que saben lo que es una fábrica. – jop