Haricots, méthodes, accès et changement? Quelle est la pratique recommandée pour les manipuler (c'est-à-dire dans ColdFusion)?

Question

Je suis novice en programmation (6 semaines maintenant). Je lis beaucoup de livres, de sites et de blogs en ce moment et j'apprends quelque chose de nouveau tous les jours.

Actuellement j'utilise coldfusion (job). J'ai lu un grand nombre d'articles sur le web et j'ai l'intention d'entrer dans mxunit ensuite et ensuite de regarder quelques frameworks. Une chose me dérange et je ne suis pas en mesure de trouver une réponse satisfaisante. Les beans sont parfois décrits comme DataTransferObjects, ils contiennent des données provenant d'une ou de plusieurs sources.

Quelle est la pratique recommandée pour gérer ces données? Dois-je utiliser un objet séparé qui lit les données, les mute et les réécrit dans le bean, de sorte que le bean est juste un stockage de données (accessible via getters) ou devrais-je mettre en œuvre les méthodes pour manipuler le les données dans le bean.

Je vois deux options.
1. Le bean est seulement le stockage, d'autres objets doivent faire quelque chose avec ses données.
2. Le bean est le stockage et la logique, d'autres objets lui disent de faire quelque chose avec ses données.

La deuxième option me semble plus adhérer à l'encapsulation tandis que la première semble être la façon dont les haricots sont utilisés. Je suis sûr que les deux options correspondent aux besoins de quelqu'un et sont recommandées dans un contexte spécifique, mais ce qui est recommandé en général, surtout quand quelqu'un ne sait pas assez sur la plus grande image de l'application et est un débutant?

Exemple:
J'ai créé un bean qui contient un élément d'une base de données avec l'ID d'élément, un nom et un tableau 1d. Chaque élément de tableau est une structure qui contient un identifiant, un nom et le montant de l'élément. Grâce à un getter je produis les données dans un tableau dans lequel je peux aussi changer le montant pour chaque utilisateur ou vérifier un utilisateur pour la suppression de cet article. Où dois-je mettre la logique pour gérer l'entrée des utilisateurs de l'application?
Dois-je dire au bean de changer son tableau en fonction de l'entrée de l'utilisateur?
Ou est-ce que je crée un objet qui modifie le tableau et écrit ce nouveau tableau dans le bean?

(Tous les accès à la base de données (CreateReadUpdateDelete) sont gérés par un objet DataAccessObject qui reçoit le bean en tant qu'argument.Le DAO contient également une méthode de passerelle pour lire plusieurs enregistrements de la base de données. éléments, sur lesquels je peux cliquer pour créer le bean et ses données.)

Answer 1

Vous observez quelque chose de connu sous le nom "anemic domain model". Oui, c'est très commun, et non, ce n'est pas un bon design OO. Généralement, la logique devrait être avec les données sur lesquelles il opère.

Cependant, il y a aussi le problème de separation of concerns - vous ne voulez pas tout bourrer dans le modèle de domaine. Par exemple, l'accès à la base de données est souvent considéré comme une couche techniquement distincte et pas quelque chose que les modèles de domaine eux-mêmes devraient faire - il semble que vous ayez déjà cette séparation. Ce qui devrait et ne devrait pas faire partie du modèle de domaine dépend du cas concret - une bonne conception ne peut pas vraiment être exprimée dans des règles absolues.

Une autre préoccupation concerne les modèles qui sont transférés sur le réseau, par ex.entre un serveur d'applications et une interface Web. Vous souhaitez que ceux-ci ne contiennent que les données elles-mêmes afin de réduire l'utilisation et la latence de badnwidth. Mais cela ne signifie pas qu'ils ne peuvent pas contenir de logique, puisque les méthodes ne font pas partie des objets sérialisés. Les champs et les caches dérivés sont - mais ils peuvent généralement être marqués comme transitoires d'une manière ou d'une autre afin qu'ils ne soient pas transférés.

Answer 2

Votre bean doit contenir à la fois vos données et votre logique.

Les objets de transfert de données sont utilisés pour transférer des objets sur le réseau, par exemple de ColdFusion vers une application Flex dans le navigateur. Les DTO contiennent uniquement les champs pertinents des données d'un objet. Dans la mesure du possible, vous devriez essayer de minimiser l'exposition interne de votre bean, (comme le tableau des structures utilisateur) à d'autres objets. Pour modifier le tableau, vous devez simplement appeler les fonctions de mutateur directement sur votre bean, par exemple yourBean.addUser(user) qui ajoute la structure de l'utilisateur au tableau interne.

Pas besoin de créer un DAO séparé avec un objet Gateway composé pour votre accès aux données. Mettez simplement toutes vos méthodes d'accès à la base de données (requêtes CRUD plus table) dans un seul objet Gateway.