Pregunta

Tengo una clase de fábrica que llena objetos con datos. Quiero implementar el guardado del objeto, pero no quiero llenar el objeto con material db. ¿Es estúpido que mi Factory que crea la clase también guarde los datos?

es decir: en mi método .Save () en el objeto llamaría Factory.Save (myObject);

¿Fue útil?

Solución

Si le preocupan las cosas de la base de datos en las clases, ¿ha considerado usar el mapeador 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 Registro activo .

Otros consejos

La clase factory es un patrón de creación que ayuda a crear nuevos objetos.

Hay varios patrones que tratan con objetos persistentes, uno de los cuales es el mapeador de datos http://martinfowler.com/eaaCatalog/dataMapper.html

Esto se usa a menudo en conjection con Repository http://martinfowler.com/eaaCatalog/repository.html

Puede usar estos patrones para abstraer la base de datos de su dominio / objetos comerciales, y acceder a ellos desde su aplicación para consultar y guardar objetos.

Por lo tanto, el mapeador / repositorio de datos es responsable de ambos aspectos de la persistencia (poblar desde la base de datos y guardar de nuevo en la base de datos).

No, no es para nada estúpido, de hecho, así es como todos deberían 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 Factory. Solo crea métodos de extensión. De esa manera, aún puede tener su código de persistencia aislado del objeto comercial y aún así poder llamar a myObject.Save ().

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top