J'utilise le cadre d'entité pour la première fois et je dois ajouter une logique commerciale avant d'insérer de nouveaux objets dans la DB, voici les options que j'ai pensées:
Quelle méthode est la meilleure pratique lors de la gestion de la logique commerciale sur l'entité framework
8 Réponses :
Peut-être que votre réponse se tient dans les lignes de those;)
Validation des meilleures pratiques ASP.NET MVC & Ado.net Entity Framework
Un autre moyen d'envisager est de composer complètement votre couche d'accès aux données de votre couche logique de votre entreprise complètement.
Créer une interface d'accès aux données qui accède directement à l'embrayage d'entité, puis dans un projet séparé, je créerais les classes de votre logique commerciale qui interface avec la couche d'accès aux données via l'interface. Aucun cadre d'entité ne fait référence au projet logique de votre entreprise.
De cette façon, les couches sont composalisées et plus faciles à distribuer sous forme d'assemblages multiples pour un accès à deux niveaux ou à trois niveaux.
Cela semble que je cherche vraiment, pourriez-vous ajouter plus d'explications sur la manière de lier les deux composants (entité - logique commerciale)
A manqué d'espace sur mon commentaire précédent, mais mes cours de la couche logique d'entreprise seront structurés de la même manière et dans leur propre espace de noms. Dans la catégorie, j'ai mis des opérations personnalisées, une validation et à peu près tout le reste ici. Les classes de votre logique d'entreprise peuvent simplement utiliser les interfaces d'accès aux données nécessaires. Vous pouvez également prendre une étape plus loin et séparer vos couches dans des projets et des assemblages séparés, ce qui peut être trop à la mer. L'avantage de vos interfaces de classe BL est qu'elles sont accessibles directement via des services Web ou directement via WPF. Il est flexible et composé.
Mon expérience:
valider la méthode qui vérifiera que l'état de l'ensemble de l'entité est correct.
Mais tout cela ne fonctionne que si vous utilisez toujours toute l'entité. Une fois que vous avez commencé à utiliser des mises à jour partielles et d'autres fonctionnalités, vous devrez toujours gérer la validation ailleurs. C'est un autre +1 pour la validation à la demande.
Je suis d'accord, quelle alternative utilisez-vous pour résoudre vos problèmes?
regarder Validation avec EF - La validation est à l'intérieur les entités elles-mêmes.
C'est un moyen très propre d'organiser votre projet.
Lorsque vous avez POCO S, l'endroit évident pour la validation de l'entité est dans le Poco lui-même.
Il est logique que toute validation de l'objet client soit réellement dans la classe client.
Je préfère une version de numéro 3. J'aime tout de toute façon Utilisation d'un référentiel ou quelque chose de similaire, au cas où je voudrais / besoin de remplacer EF à l'avenir.
Ensuite, pour la validation / la logique commerciale, j'utilise toutes les techniques de validation du sens de l'application, mais généralement une combinaison de dataannotations (pour la validation minimale de l'interface utilisateur) et un cadre de validation comme fluent Validation pour une validation maximale / des règles commerciales. Cette logique de validation / entreprise vit à la fois la classe d'entité (dataannotations) et dans une couche d'abstraction, qui est généralement une couche de service dans mes applications.
Vous pouvez également étendre vos classes en créant une autre définition de classe partielle, la plupart des modèles EF définissent les entités comme définitions partielles uniquement pour les personnes qui les prolongent facilement. Vous voudrez faire cela si vous travaillez avec WPF ou Silverlight, car la plupart des choses ne sont pas liées directement, vous avez une booléenne et souhaitez-vous convertir cela en une couleur, etc. Les convertisseurs d'écriture sont lents et nécessitent beaucoup plus de code à Configuration puis crée des nouveaux getters sur vos BusinessObjects.
Nous utilisons EF 4.0 Ste (entités de suivi automatique) depuis un moment et nous étendons la plupart d'entre eux avec nos propres définitions partielles. Nous avons changé un peu du modèle T4 qui crée les bêtes pour permettre l'accès au constructeur sur la définition de classe partielle personnalisée et d'autres petites améliorations.
Article du magazine Visual Studio Adressant le problème:
Quelle version de EF utilisez-vous?
Bon. Vous pouvez facilement créer des pocos alors, le lien que j'ai utilisé est un bon point de départ. C'est le plus proche de l'option 3.
Merci pour toutes les grandes réponses