Structurer une solution winforms C #

Question

Je suis donc en train de réorganiser une solution winforms en C # pour découpler et la rendre plus propre et plus organisée. La solution permet de suivre les commandes d’une petite entreprise, etc. .

J'ai divisé les projets jusqu'à présent en

App.View : tous les codes liés à l'interface graphique
App.Data : uniquement des structures de données et des interfaces. Pas d'autre code d'implémentation
App.BusinessLogic : tout code de logique métier ne comportant aucune référence d'interface graphique

J'ai des cours que je ne peux pas savoir où ils appartiennent. Dites-moi quel est le projet de chaque classe ou s'il y a un autre projet qui devrait être créé à cet effet.

1. Une classe qui récupère les préférences de l'utilisateur d'une base de données
2. Une classe qui récupère des données statiques de notre serveur de données statiques et renvoie des ensembles de résultats de données.
3. Une classe qui réduit les droits des utilisateurs
4. Une classe modèle qui stocke une table de hachage des commandes
5. Une classe qui envoie des messages par courrier électronique à une action de l'utilisateur

Answer 1

En fait, je pense que vous avez des problèmes avec une architecture en couches traditionnelle. Normalement, les modèles de vos données sur lesquels votre application fonctionne sont conservés dans une couche de gestion, avec le code permettant de les exploiter. Votre couche de données disposerait à la fois des modèles de données de votre infrastructure de persistance et du code permettant d'interagir avec cette infrastructure. Je pense que cela pourrait être la source de la confusion entre les emplacements suggérés de vos cours et votre réaction à cela en fonction de vos commentaires.

Dans cette perspective, tout ce qui récupère ou apporte serait nécessairement situé dans votre couche de données - il accède aux données dans un stockage persistant. Ce qu’il récupère est finalement converti en objets de la couche de gestion sur lesquels votre logique d’entreprise opère. Les choses sont des modèles conceptuels - comme un tableau de commandes - ou les actions commerciales appartiennent à la couche de gestion. Je suis d’accord avec @Adron avec, peut-être, la même confusion quant à savoir où (3) va selon ce qu’il est réellement.

Plus spécifiquement:

1. Les préférences de l'utilisateur sont des affaires objets, la chose qui récupère eux est un objet de couche de données.
2. Les données statiques sont mappées sur une entreprise objet (table ou vue ou quelque chose), la chose qui accède à l'externe le serveur est un objet de couche de données.
3. Le droit d'utilisateur est un objet métier. Ce qui le récupère est un objet de couche de données.
4. Une table d'Ordres est un objet métier
5. L'e-mailing étant une activité commerciale, l'élément qui envoie des messages à un utilisateur est un objet métier

[EDIT] Mon architecture généralisée à 3 niveaux pour les applications Web (simples)

DataAccessLayer

Cela inclurait mes TableAdapters et DataTables et Factories fortement typés qui transforment les lignes de mes DataTables en objets métier dans les projets antérieurs à LINQ. En utilisant LINQ, cela inclurait mes entités LINQ générées par DataContext et par le concepteur.

BusinessLayer

Cela inclut toute logique métier, y compris la validation et la sécurité. Dans pre-LINQ, il s'agirait de mes objets métier et de toute autre classe qui implémenterait la logique de l'application. En utilisant LINQ, ce sont les implémentations de classes partielles de mes entités LINQ pour implémenter la sécurité et la validation, ainsi que toutes les autres classes pour implémenter la logique métier.

Présentation

Ce sont mes formulaires Web - essentiellement l'interface utilisateur de l'application. J'inclus une partie de la logique de validation dans les formulaires en tant qu'optimisation, bien que celles-ci soient également validées dans le BL. Cela comprendrait également les contrôles utilisateur.

Remarque: il s'agit de la structure logique. La structure du projet reflète généralement ce principe, mais certains cas, tels que les connexions à des services Web, peuvent être directement inclus dans le projet Web même si, logiquement, les composants sont réellement dans le BL / DAL.

Remarque: je passerai probablement à MVC sur 3 niveaux une fois que ASP.NET MVC sera en production. J'ai réalisé des projets personnels dans Ruby / Rails et j'aime beaucoup le paradigme MVC pour les applications Web.

Answer 2

Vous avez spécifié que App.Data ne devrait contenir que des structures de données et des interfaces, pas de code d'implémentation, ce qui est bien si vous souhaitez le faire, mais cela ne vous laisse nulle part où mettre votre code d'accès à la base de données, sauf dans votre App.BusinessLogic. Assemblée.

Peut-être devez-vous vraiment renommer App.Data en App.Model (ou quelque chose de similaire) et disposer d’un nouvel assemblage App.DataAccess qui communique avec la base de données (éventuellement en implémentant un modèle de référentiel). Cela fait, je séparerais les choses comme ceci:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. Modèle App
5. App.BusinessLogic

Answer 3

Je voudrais probablement aller avec

1. Données
2. Données
3. Données, bien que je ne sois pas tout à fait sûr de ce que fait la classe
4. Données
5. BusinessLogic

Answer 4

1. - > App.Data
2. - > App.Data
3. - > App.BusinessLogic ou App.Data - vous ne savez pas exactement ce que cela signifie.
4. - > App.BusinessLogic
5. - > App.BusinessLogic