Dans une architecture en couches utilisant un cadre d'entité, devrais-je renvoyer des cours de Poco de la BLL? (Directives d'architecture nécessaires)

Les réponses à vos questions peuvent dépendre de la taille et de la complexité de votre application. Je crains donc d'avoir des arguments valides pour répondre à vos questions avec oui et non aussi.

Personnellement, je répondrai à vos deux questions principales avec oui:

est-il une pratique acceptable d'utiliser des classes POCO (domaine) dans la couche d'interface utilisateur?

Je suppose avec "la couche d'interface utilisateur", vous ne voulez vraiment pas dire la partie de la vue du motif MVVM, mais les images de vue. (La plupart des spécialistes MVVM discuteraient de laisser une vue directement référencer le modèle du tout, je crois.)

Il n'est pas inhabituel d'envelopper un POCO de votre projet de domaine en tant que propriété dans une vue de vue et de lier ce POCO emballé directement à la vue. Le Big Pro est: C'est facile. Vous n'avez pas besoin de classes de menuLodel supplémentaires ou de propriétés répliquées dans une viewModel, puis copiez ces propriétés entre les objets.

Toutefois, si vous utilisez WPF, vous devez prendre en compte que le moteur de liaison écrira directement dans vos propriétés POCO si vous les liez à une vue. Cela pourrait ne pas toujours être ce que vous voulez, surtout si vous travaillez avec des entités attachées et changées dans un formulaire WPF. Vous devez penser aux scénarios d'annulation ou à la manière dont vous restaurez les propriétés après une annulation qui a été modifiée par le moteur de liaison.

Dans mon projet actuel, je travaille avec des entités détachées: je charge le POCO à partir de la couche de données, détachez-le du contexte, jetez le contexte, puis travaillez avec cette copie dans la vue et liez-le à la vue. La mise à jour dans la couche de données se produit en créant un nouveau contexte, chargement de l'entité d'origine à partir de la DB par ID, puis mettant à jour les propriétés du POCO modifié qui a été lié à la vue. Donc, le problème des changements indispensables d'une entité attachée disparaît avec cette approche. Mais il y a aussi des inconvénients pour travailler avec des actionnements détachés (la mise à jour est plus complexe par exemple).

est-ce correct si je implémente l'interface idataerrrorinfo sur la classe POCO générée?

Si vous liez vos entités POCO à une vue (via une vue d'emballageModel), il ne s'agit pas seulement d'ok mais vous ne devez même pas Implément idataerrrorinfo sur la classe POCO si vous voulez exploiter la validation de la propriété intégrée du moteur de liaison WPF. Bien que cette interface soit principalement utilisée avec les technologies d'interface utilisateur, elle fait partie de System.componentModel Espace de noms et donc non directement liés à aucun espaces de noms d'interface utilisateur. Fondamentalement idatarserrorinfo n'est qu'un simple contrat qui prend en charge la déclaration de l'état de l'objet, qui pourrait également être utile en dehors d'un contexte d'assurance-chômage.

La même chose est vraie pour l'interface inotifyproperTychanged que vous auriez également besoin d'implémenter sur vos classes de POCO si vous les liez directement à une vue.

Je vois souvent des opinions qui ne seraient pas d'accord avec moi pour plusieurs raisons architecturales. Mais aucune de ces opinions ne fait valoir qu'une autre approche est plus facile. Si vous voudriez strictement voudriez éviter d'avoir des classes de modèle POCO dans votre couche de viewModel, vous devez ajouter une autre couche de cartographie avec une complexité et une programmation supplémentaires et un effort de maintenance. Donc, je voterais: gardez-le simple aussi longtemps que vous n'avez pas de raison convaincante et d'avantage clair pour rendre votre architecture plus complexe.