où va le modèle?

Question

J'ai une solution de VS avec les projets suivants.

-GUI
-DataAccess
-BusinessLogic
-BusinessObjects

mais où la classe de modèle principale doit-elle résider? Il s'agit généralement d'un cache d'un ensemble d'objets représentant les résultats de la couche d'accès aux données et de l'interface graphique utilisant des grilles virtuelles pour afficher les données à l'intérieur du modèle. La question serait la même en utilisant MVC ou MVP

pensées?

Answer 1

Il s'agit d'une question subjective, mais souvent, pour que les objets de votre modèle ne dépendent pas directement de l'infrastructure, les utilisateurs les placent souvent dans un projet distinct. vous devez également déterminer quels autres projets pourraient utiliser ces objets de modèle.

Une autre option permettant de scinder la fonctionnalité en plusieurs unités déployables (assemblées) consiste à permettre aux équipes de fonctionner de manière plus autonome. Séparez les projets en fonction de la fréquence de déploiement et de l'autonomie de l'équipe.

Enfin, j'ai vu des projets dans lesquels les objets du modèle étaient appelés à distance (comme avec le remoting .NET) et servis sur un serveur d'applications distinct du serveur Web. Je ne recommande vraiment pas cette approche, mais c'est une option.

Si vous ne prévoyez pas de les réutiliser et que vous êtes conscient du fait de les placer dans le même assemblage vous permet de créer des dépendances croisées avec tout ce qui est défini dans ce projet, mais vous êtes assez intelligent pour ne pas le faire, vous pouvez tous les placer dans le même projet.

Cela dit, 99% du temps, j'ai ces projets:

• interface utilisateur
• Noyau
• Persistance
• Tests

Mais vous devez toujours prendre en compte les besoins de votre projet.

Answer 2

j'ai tendance à avoir

• Justice.Project.Core & # 8212; le modèle de domaine POCO & # 8212; c'est-à-dire des objets métier)
• Justice.Project.Data & # 8212; Mappages NHibernate, etc., où le schéma de persistance réside
• Justice.Project.Services & # 8212; les référentiels, ainsi que la logique métier qui ne peut pas être facilement insérée dans les objets métier
• Justice.Project. (Web | UI)

Le modèle est & # 8211; ou devrait être & # 8211; les objets métier.

Answer 3

Mes solutions ont 3 projets (non testés)

1. UI - évidente
2. Noyau - tous les objets de domaine et la logique métier
3. Accès aux données - Modèle de référentiel pour le remplissage / enregistrement des objets du modèle

Answer 4

  

je suis d'accord que les objets du modèle vont dans   POCO. alors disons que j'ai un ordre   objet. Ma question est où dois-je   la classe qui stocke une collection de   commandes ??

Cela dépend de votre entreprise. Très probablement, vous aurez une collection de commandes dans quelques endroits différents ...

Sur votre objet client, chaque client doit avoir une collection de commandes afin que vous en ayez une.

Si vous avez des départements, chaque service doit avoir une collection de commandes qu’il a créée.

Si vous avez des entrepôts, chaque entrepôt peut disposer d'un ensemble de commandes qu'il est chargé de remplir.

Certains objets n'ont pas de parent, et c'est bien. Dans mon système, nous avons des clients. Le propriétaire réel des clients est nous (l’entreprise), mais il n’existe pas de lien "Nous". objet dans le système. Si vous souhaitez obtenir une liste de vos clients (dans notre cas), nous interrogeons le référentiel.

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

La même chose pourrait s’appliquer à vos commandes.

Je vous conseillerais de consulter ce livre DDD: http: //www.amazon .com / gp / product / 0321268202 / ref = s9k22_cf_rd_m = p_pf_rd_m = p_f_rd_m = p_pf_rd_m = p_pf_rd_m = p_pf_rd_m