Besoin d'aide avec une grande application ASP.NET

Question

Nous avons un ASP classique ERP (très grande application) que nous voulons réécrire en utilisant ASP.NET.

Je suis à la recherche d'un moyen d'organiser l'application de sorte que nous serons en mesure de séparer chaque programme/page Web (plus de 400) les uns des autres. Chaque programme doit être indépendant car de nombreux développeurs travailleront sur le projet en même temps.

Visual Studio semble créer une DLL pour chaque assembly, donc je me demandais si c'était une bonne idée de faire une énorme solution avec un projet par DLL.

Ex. :

Clients.aspx + Customers.aspx.vb (compilé) pour la présentation

Customers.DLL pour l'entité objet

CustomersManager.DLL pour la logique métier

CustomersData.DLL pour l'accès aux données De cette façon, nous serions en mesure de déployer chaque programme séparément sans modifier les autres. Nous aurions également plus d'un millier de DLL à gérer ...

Cela semble-t-il être une bonne solution pour une application à grande échelle? Quelqu'un a une meilleure idée?

Merci

Answer 1

de contrôle à la source a été inventé exactement dans le but d'avoir de multiples travailler simultanément sur développe de grandes solutions. J'apprécie la valeur d'avoir des composants qui peuvent être déployés indépendamment, mais peut-être que la valeur est perdue à mesure que le nombre de composants indépendants nécessitant une maintenance approche les centaines et les milliers?

La séparation de l'application en une présentation/une logique métier/des DLL DAL distinctes a un sens par module, mais généralement pas par page. Considérez les différents domaines fonctionnels de votre application susceptibles de partager du code et de commencer par là (un ensemble de projets pour chacun).

Answer 2

Cela me semble être un énorme cauchemar impossible à gérer.

J'ai fait partie de plusieurs grands projets .Net et, comme JeffN825, la meilleure façon de fonctionner est d'utiliser un contrôle de source, ainsi que des classes qui supportent directement votre modèle (base de données).

dossiers sous la racine du projet peut vous aider à diviser les choses logiquement «/clients », «/Ordres », etc.

Si vous voulez faire des projets séparés pour vos classes, qui est également fait un peu . Avoir un projet distinct contenant tous vos objets de base de données. Créez un autre projet pour Business Logic. En fait, créez plusieurs projets Business Logic si vous en avez besoin "CustomerBO", "OrderBO", etc.

Mais gérer plus de 1000 dll et leurs pages web associées ... ça va être un cauchemar.

Answer 3

Je pense que la question était de savoir si avoir une DLL séparée pour chaque couche de chaque page était une bonne architecture, ce qui n'est pas le cas, sinon pour Visual Studio, il est plus probable que crawl stopper pour charger des centaines de projets séparés (je frémis de penser à ce que cela ferait, et comment il serait impossible de maintenir toutes ces DLL). Maintenant, une solution plus raisonnable serait d'avoir une DLL pour chaque couche et de séparer le code de chaque page dans un fichier différent et d'utiliser un système de contrôle de la source. Cela permettrait aux développeurs de partager du code même avec les pires systèmes de contrôle de source. Si votre système de contrôle de source a un bon support Branching/Merging (comme SourceSafe) comme TFS, SVN, Git vous ne vous inquiétez pas vraiment des personnes qui travaillent sur le même fichier de façon simulatan, et vous pouvez organiser votre code par fonction et non par page . Je devrais deviner à partir de la question, qu'il y a probablement une quantité astronomique de code dupliqué qui pourrait être simplifié et rendu plus facile à maintenir en cassant une connexion rigide au code Web et en réutilisant le code. Il peut être étonnant de voir combien moins de code il y aura. Vous pouvez faire la même chose du côté de l'interface utilisateur en utilisant judicieusement les contrôles utilisateur pour encapsuler les fonctionnalités partagées. De plus, en passant d'ASP à .NET, vous récupérez des choses comme les contrôles SiteMap qui devraient également réduire l'empreinte du code.