Meilleures approches pour concevoir une application ASP.NET bien organisée avec modularité

Question

J'essaie de réfléchir à un cadre de développement d'applications Web pour le développement de nos produits. Je veux construire une application ASP.NET qui contient de nombreux sous-modules. Mes exigences sont comme:

1. L'application sera une suite de différents modules tels que CRM, Bugtracker, gestion des stocks, gestion des finances, etc.

2. Chaque module doit avoir leurs propres DLL.

3. Un projet devrait être pour le conteneur externe de l'application (comme le framework) et ce projet devrait amener tous les autres modules (d'application Web de type) dans la solution vers le conteneur externe. (Une certaine chose comme nous avons des cadres en HTML). Nous ne publierons donc l'application Web du conteneur externe qu'à la fin de la journée et tous les autres projets d'application Web y seront accessibles.

Je voudrais avoir DLL séparée pour chaque module, donc je ne dois pas craindre de la rupture de l'application lorsque je déploie mon DLL unique qui contrôle toute la suite. Je ne suis pas sûr que mes pensées vont dans la bonne direction. Le résultat final que je recherche est une suite d'applications Web bien entretenue, organisée et modulaire.

Ce sont des formulaires Web ASP.NET, pas MVC. Je vais utiliser VS2010 pour le développement.

Quelles sont les meilleures approches pour ce faire?

Edit:

Le terme conteneur externe signifie qu'il agit comme une page principale qui a des liens vers différents modules et les différents modules ne sont pas toujours dans le même projet. Ils peuvent être projet séparé sous la même solution. Et j'ai l'impression que, d'ici la fin de la journée, je ne publierai que ce projet et qu'il apportera les différents modules.

Answer 1

Je ne vais pas dire que c'est une "meilleure approche" mais je recommanderais de regarder par dessus Dot Net Nuke (DNN) pour avoir quelques idées. Cela a commencé comme l'ancien projet Web de démarrage "I Buy Spy" que Microsoft a distribué pour montrer les projets ASP.NET, et il a décollé de là.

modifier:

1. application sera une suite de différents modules tels que CRM, Bugtracker, gestion des stocks, gestion des finances, etc.

Vous pouvez le faire avec DNN. Ils sont aussi appelés "modules" dans DNN et Drupal.

2. Chaque module doit posséder ses propres DLL.

Oui, c'est une bonne idée. Et vous verrez ce genre de chose dans plusieurs systèmes de gestion de contenu comme DNN et Drupal. De cette façon, toutes les implémentations du même site Web ne nécessitent pas l'installation de tous les modules.Nous avons un site Web important qui sert à héberger une application «service comme solution» que nous facturons (si vous n'êtes pas un actuaire ou un comptable, vous n'en aurez pas entendu parler). Le développeur principal des deux dernières années a utilisé une version antérieure de DotNetNuke comme modèle pour refactoriser les parties de l'application qu'il était autorisé à modifier.

Answer 2

En fait, je pense que la meilleure approche serait celle qui ne serait pas trop architecturale. Je crains qu'il semble que vous produisez une architecture globale sans raison suffisante.

S'agit-il de tous les nouveaux modules? Ensuite, commencez simplement à écrire le premier. Utilisez les meilleures pratiques applicables aux modules simples.

Ensuite, écrivez le second. Vous trouverez que vous voulez utiliser les choses que vous avez déjà écrites dans le premier module. Génial. C'est ce que le refactoring est pour. Réorganisez ces éléments en un ou plusieurs projets de «bibliothèque», réexécutez tous vos tests unitaires, puis passez au deuxième module.

Répéter jusqu'à ce que tous les modules soient terminés.

À la fin de ce processus, si vous aviez besoin du type d'architecture que vous avez décrit, alors vous l'aurez. Si vous en avez besoin de moins, vous en aurez moins, et vous n'aurez pas passé du temps à créer une architecture qui ne soit pas liée aux exigences du monde réel.

Answer 3

Comme d'autres ont suggéré que DNN fonctionnerait probablement pour ce que vous essayez de faire. Si vous voulez rouler complètement le vôtre naturellement, je me tournerais vers une sorte de combinaison d'un conteneur "Framework" et d'un tas de contrôles utilisateur (.ascx). Le conteneur pourrait être aussi simple qu'une page maître avec un menu. En fonction de la flexibilité de votre conception, vous pouvez préfabriquer de nombreuses pages différentes, chacune hébergeant un contrôle différent (dll séparée comme vous le souhaitez). Si vous voulez que ce soit un peu plus dynamique, vous pouvez avoir une page de contenu qui chargera dynamiquement au moment de l'exécution le contrôle de l'utilisateur désiré. Encore une fois, ce n'est qu'une approche générale, probablement une vue à 30000 pieds sur la façon dont DNN est mis en œuvre de toute façon.

Answer 4

Nommez le projet principal après votre entreprise/produit et gardez-le court et simple. Vous aurez probablement besoin d'un ou deux projets de bibliothèque pour le soutenir - ceux-ci contiendront tous les jours, une logique commune pour des choses telles que error reporting, méthodes utilitaires Web, etc.

Ensuite, choisissez un de vos destinées sub-projects (je n'aime pas le terme module dans ce contexte particulier) et ajoutez cela à votre solution. Que vous réutilisiez un projet existant ou, de préférence, que vous commenciez à partir de zéro, vous finirez par avoir une logique commune dans ce projet déplacé vers vos bibliothèques.

Rincer et répéter. Peut-être jeter un coup d'oeil à quelque chose de similaire au projet Sueetie qui comprend plusieurs sous-projets comme CMS, Blog, Calendrier, Forum, etc.

L'article suivant est marqué comme "obsolète" sur MSDN mais je pense toujours que vous devriez prendre un coup d'oeil:

Structuring Solutions and Projects

en outre, quelque chose de similaire aux modèles et pratiques du groupe:

Structuring Projects and Solutions in Team Foundation Source Control