Entity Framework and Encapsulation

Question

Je voudrais appliquer expérimentalement un aspect de l'encapsulation que j'ai lu une fois, où un objet entité inclut des domaines pour ses attributs, par ex. pour sa propriété CostCentre, elle contient la liste des centres de coûts valides. De cette façon, lorsque j'ouvre un formulaire d'édition pour une extension, j'ai seulement besoin de passer le formulaire un objet Extension, où j'accède normalement à un objet CostCentre lors de l'initialisation du formulaire.

Cela s'applique également lorsque j'ai une liste d'extensions liées à une grille (telerik RadGrid), et que je gère une commande d'édition sur la grille. Je veux créer un formulaire d'édition et lui passer un objet d'extension, où maintenant je passe le formulaire d'édition un ExtensionID et crée mon objet dans le formulaire. Ce que je demande en fait ici, c'est de donner des conseils sur la manière de procéder de cette façon, ou la façon «correcte» de réaliser quelque chose de semblable à ce que j'ai décrit ici.

Answer 1

Cela dépend de votre source de données. Si vous récupérez la liste des centres de coûts à partir d'une base de données, ce serait une approche. Si c'est une courte liste de valeurs prédéterminées (comme Oui/Non/Peut-être), alors les attributs de propriété peuvent faire l'affaire. S'il doit être plus configurable par environnement, alors IoC ou le modèle Provider serait le meilleur choix. Je pense que votre problème est similaire à une page de recherche ad-hoc personnalisée que nous avons effectuée sur un projet précédent. Nous avons décoré nos classes et propriétés d'entités avec des attributs qui contenaient des «pointeurs» prédéterminés pour les méthodes de valeur de recherche et leurs relations. Ensuite, nous avons créé un seul contrôle d'interface utilisateur personnalisé (comme votre page d'édition décrite dans votre message) qui utilisait ces attributs pour générer les listes déroulantes et auto-complétées en générant dynamiquement une expression LINQ, puis en l'exécutant au moment de l'exécution. tout ce que l'utilisateur faisait. Ceci a été accompli avec essentiellement trois parties mobiles: A) les attributs sur les objets d'accès aux données B) les méthodes 'attribut facade' aux expressions dynamiques LINQ de compilation et de génération de niveau intermédiaire et C) le contrôle d'interface utilisateur personnalisée qui a appelé nos méthodes de service de niveau intermédiaire. Parfois, des plans comme ceux-ci se retournent, mais dans notre cas, il a bien fonctionné. Décorer nos objets avec des attributs, puis créer un seul chemin de logique nous a donné juste assez de puissance pour faire ce que nous devions faire tout en minimisant la quantité de code requise, et complètement éliminé toute passe-partout. Cependant, cette approche n'était pas très configurable. En compilant ces attributs dans le code, nous avons étroitement couplé notre application à la source de données. Pour ce projet particulier, ce n'était pas un gros problème parce que c'était un système interne de clients et qu'il correspondait au calendrier du projet. Cependant, sur un «vrai produit» mettant en œuvre la logique avec le modèle Provider ou en utilisant quelque chose comme les projets Castle IoC nous aurait permis la même puissance avec beaucoup plus de configurabilité. L'inconvénient de ceci est qu'il y a plus à gérer, et plus qui peut mal se passer avec les déploiements, etc.