Question

J'ai une classe d'usine qui renseigne les objets avec des données. Je souhaite implémenter l'enregistrement à partir de l'objet, mais je ne veux pas remplir l'objet avec des éléments de base de données. Est-il stupide de voir ma fabrique qui crée la classe également enregistrer les données?

C'est à dire: dans ma méthode .Save () sur l'objet, j'appellerais Factory.Save (myObject);

Était-ce utile?

La solution

Si vous êtes préoccupé par les éléments de base de données dans les classes, avez-vous envisagé d'utiliser le mappeur O / R?

Ceci garderait entièrement le contenu de la base de données hors de votre code et vos objets de domaine propres.

Peut-être jetez-vous un coup d'oeil à NHibernate ou Enregistrement actif .

Autres conseils

La classe factory est un modèle de création qui aide à créer de nouveaux objets.

Il existe divers modèles traitant des objets persistants, dont le mappeur de données. http://martinfowler.com/eaaCatalog/dataMapper.html

Ceci est souvent utilisé en conjonction avec Repository http://martinfowler.com/eaaCatalog/repository.html

Vous pouvez utiliser ces modèles pour extraire la base de données de votre domaine / de vos objets métier et y accéder à partir de votre application pour interroger et enregistrer des objets.

Le mappeur / référentiel de données est donc responsable des deux aspects de la persistance (remplissage à partir de la base de données et enregistrement dans la base de données).

Non, ce n'est pas du tout stupide, en fait, c'est ainsi que tout le monde devrait le faire. L'objet métier ne doit contenir aucune logique de persistance.

Btw, si vous utilisez C # 3.0, vous pourriez même ne pas vous embêter avec la classe Factory. Il suffit de créer des méthodes d'extension. De cette façon, votre code de persistance peut toujours être isolé de l'objet métier et tout de même pouvoir appeler myObject.Save ().

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top