J'ai le besoin de versions légères et de versions lourdes d'un objet dans ma demande.
Voici un exemple de classe (à des fins de discussion uniquement): y a-t-il un bon modèle de conception à suivre pour y accomplir? Je peux voir comment il peut être codé dans une seule classe (comme mon exemple ci-dessus), mais ce n'est pas évident dans quelle manière une instance est utilisée. Je devrais avoir des chèques nuls tout au long de mon code. EDIT:
Ce modèle d'objet est utilisé sur le côté client de l'application client-serveur. Dans le cas où j'utilise les objets de poids léger, je ne veux pas une charge paresseuse car ce sera une perte de temps et de mémoire (j'aurai déjà les objets en mémoire sur le côté client ailleurs) < / p>
4 Réponses :
Avez-vous envisagé d'utiliser un outil orm comme NHibernate pour accéder à la DB? Si vous utilisez quelque chose comme NHibernate, vous obtiendrez ce comportement au moyen de chargement paresseux.
La plupart des outils ORM font exactement ce que vous recherchez dans le chargement paresseux - ils obtiennent d'abord les identifiants d'objet et, lors de l'accès à une méthode, ils émettent des requêtes ultérieures pour charger les objets associés.
L'initialisation paresseuse, le proxy virtuel et le fantôme sont trois implémentations de ce motif de chargement paresseux. Fondamentalement, ils se réfèrent aux propriétés de charge une fois que vous en avez besoin. Maintenant, je suppose que vous utiliserez quelques repo pour stocker des objets afin que je vais vous encourager à utiliser l'un des outils ORM disponibles. (Hibernate, cadre d'entité, etc.), ils implémentent tous ces fonctionnalités gratuites pour vous.
Je ne veux pas toujours charger l'objet complet. Et parfois, j'en ai déjà une instance, donc je n'ai pas besoin de ré-charger de DB de toute façon.
@Thesan ça n'a pas d'importance. C'est précisément l'utilité du motif. Si vous avez besoin de les utiliser, vous les chargez, sinon pas. Maintenant, si vous parlez de ne pas exposer les propriétés de version lourdes qui est autre chose, mais peut également être résolu en utilisant (c'est-à-dire deux interfaces: le plus léger et le lourd).
Par exemple, disons que j'ai 1 000 commandes, chacune pour le même produit. Avec votre suggestion au paresseux charger l'objet produit, je chargerais 1 000 instances du même objet. C'est ce que je veux dire par gaspillage de mémoire.
@Thesan je suis à peu près sûr que tous les ORM nommés gèrent ce scénario (joli courant pour les ordres de magnitude élevés), maintenant, si vous souhaitez le gérer à la main, vous pouvez également mettre en œuvre le chargement paresseux -Again :) - mais maintenant Ayez, disons, un cache, où vous gérez des entités déjà instanciées de votre représentant, et étant donné qu'ils sont des types de référence, il ne doit pas y avoir de surcharge. (De toute évidence, la modification de l'entité présentera un autre problème, mais vous pouvez avoir l'idée). Les modèles sont très généraux et il est courant de s'adapter aux besoins spécifiques que nous avons. Mais encore une fois, je suis à peu près sûr que les ormes soutiennent cela.
On dirait que vous pourriez avoir besoin d'un objet de transfert de données (DTO), juste une classe wrapper "muette" qui résume une entité commerciale. J'utilise habituellement quelque chose comme ça lorsque j'ai besoin d'aplatir un objet à l'affichage. Soyez prudent, cependant: la surutilisation entraîne un anti-motif.
Mais le rendu d'un objet à affichage est différent de la limitation des hits contre la base de données. Comme Randolph souligne, si votre intention est celle-ci, utilisez l'un des modèles de chargement différés existants, ou mieux encore, utilisez un orj.
Jetez un coup d'œil au Greffe motif, vous pouvez l'utiliser pour trouver des objets et aussi pour mieux gérer ces objets, comme les garder dans une cache.