10
votes

Structure de projet ASP.NET MVC

J'ai créé la structure de projet suivante pour mon nouveau projet ASP.NET MVC tout ce que j'étais après quelques commentaires comme comment d'autres personnes structurent leurs projets et si j'améliore le mien ...

Voici ce que j'ai tellement FAR: P>

+Assets
-+Images 
-+Scripts 
-+Stylesheets 
-+...              'More things like the above here
+Controllers 
-+Support
--+Actions         'Any custom action classes
--+Controllers     'Base controller classes
+Models
-+Domain           'Contains any class that specialise view specific domain logic
--+UrlProcessing   'Encoding/decoding business entities as URL parts 
--+...             'More things like the above here
-+Views            'Contains view models
--+Support
---+Views          'Base classes for any view models
+Support
-+Application      'Global application interface classes (i.e. class that wraps the function of the global asax)
-+Configuration    'Typed config classes
-+Helpers          'Where you put additional html helper classes, etc
-+Services
--+Bootstrap       'Tasks that run on mvc start-up that are specific to the MVC project
--+Inversion       'Specific IoC registration registrations for this project 
--+...             'More things like the above here
+Views
-+Home
-+Shared 
-+...              'More things like the above here


4 commentaires

Mec .. Essayez un coup d'écran la prochaine fois :(


Ya aurait dû faire cet hébergement de l'image est un problème si ...


Ne vous inquiétez pas de l'hébergement. Stackoverflow utilise un service gratuit pour cela ..


Vous ne pouvez pas copier la pâte d'une capture d'écran.


4 Réponses :


1
votes

J'ai écrit quelques sites (petits) et simplement bloqués avec la même structure que Nerddinner avait et cela semblait bien fonctionner.

Je pense que sur des projets plus petits qui est une approche fine tant que vous avez votre séparation des préoccupations, ne placez pas la logique commerciale dans le (des) référentiel (s), etc. La tentation d'un projet plus petit est de brouiller les lignes mais MVC tend Pour vous punir un peu quand vous faites cela. :)

Les projets plus importants peuvent vous voir mettre en œuvre un projet de classe d'entreprise séparé et peut-être même projet de traduction de données, etc.


0 commentaires

4
votes

J'ai eu une structure similaire à la vôtre avec quelques exceptions:

  1. Support est nommé Infrastructure (espace de noms pour l'utilisation de l'Assemblée d'interface utilisateur uniquement)
  2. IOC est dans un projet différent (projet de fonctionnalité d'infrastructure utilisée globalement). L'interface utilisateur a un registre des structures uniquement avec les noms d'assemblage (IOC est initialisé par la Convention). Approchez la source de la source de CodecamServer. La journalisation, les sections de configuration vont aussi ici.
  3. Vues / [nom de commande] a un sous-dossier partiel qui pourrait être encore plus divisé
    (Cela implique de jongler avec une vue sur la vue, de sorte qu'il pourrait trouver des vues / vues partielles).
  4. Vues / [nom de commande] a dossier localResources (avec sous-dossier partiel)
  5. n'a pas ajouté aucun sous-dossier sous Contrôleurs (... encore). J'aime les garder propres et assez stupides.

    Et quelques autres exceptions, liées au modèle:

    1. Toutes les logiques commerciales viennent dans l'assemblage de domaine, domaine.Model Espace de noms avec une aide de la couche d'infrastructure pour des aspects techniques.
    2. Voir les modèles (je les appelle viewdata) Vit dans l'assemblage de l'UI sous le dossier ViewData, structuré dans des dossiers similaires comme des vues. Approche choisie de KIGG (sauf que je les structure par point de vue comme SearchviewData, parfois même par vue partielle).

      Cela fonctionne assez bien jusqu'à présent

      Notez que la structuration ViewData (i My Structure My JavaScript de la même manière, Affichage == fichier JS qui contient tout sous objet nommé [viewname]) par vue peut ne pas être acceptable pour plus compliqué Web des sites.

      Oh ... et => dossier == Espace de noms pour moi. Je suppose que c'est une bonne pratique.


0 commentaires

1
votes

Je pense que c'est un peu surcpliqué mais si cela a du sens pour vous y aller. L'important est de garder l'équilibre.

Une chose que je fais de voir avec des projets séparés dans la solution, car il permet de réutiliser la réutilisation de la réutilisation de l'accès aux données et de la réutilisation des autres types d'applications client telles que les clients WPF ou WinForms.


0 commentaires

5
votes

site MVC
App - tous les fichiers statiques
--Common
---- CSS
------ Styles-Pages-User.CSS
---- imgs
------ images-la plupart des pages-user.png
---- JS
------ Votre-Custom-lib.js
--Files
-----Release_notes.md
---- version_notes.html
--Pages
---- Signin
------ Signin.css
------ logo.png
------ Signin.js
---- Dashboard
------ Dashboard.js
--Vendeurs
---- JQuery
------ JQuery.1.111.1.js
-_references.js

Contrôleurs - Seulement des contrôleurs minces, juste un code pour appeler vos fonctions de bibliothèque principale
Modèles - seuls modèles utilisés pour afficher la vue
Vues - seul code client comme HTML, Razor, CSS, etc.

bibliothèque principale
Fondamentalement, tous les codes ... Accès aux données, attributs personnalisés, utilitaires, etc. Séparer le code central à une bibliothèque est pratique pour de nombreuses raisons. Votre logique n'est pas liée à un site Web maintenant. Si j'ai besoin de construire une extrémité avant rapide dans Winforms pour tester une certaine logique ou je pourrais utiliser le même Fonctionne dans votre couche d'accès aux données pour créer une extrémité avant administrative pour la base de données.

Je trouve cette structure pour être le plus simple et le plus flexible pour moi.

mise à jour
Je suis mis à jour la structure de fichiers de contenu statique pour être plus flexible et moderne. Je suis venu avec cette structure lorsque vous travaillez avec AngularJS. J'ai finalement passé à Ractionjs. Après avoir déménagé à Ractivejs, la même structure a très bien fonctionné.

Mise à jour 8-21-15 Je travaille sur des projets plus importants ces derniers temps et séparez la bibliothèque principale à son propre projet Visual Studio. Cela le rend flexible lorsque vous utilisez Svn Externals. Je peux utiliser la même bibliothèque à travers différents projets et seulement avoir besoin de faire une mise à jour SVN pour obtenir les modifications. A également éclaté le site MVC dans son propre projet également.


2 commentaires

Je sais que tu as répondu il y a ce mois. J'ai un doute que les modèles utilisés uniquement pour afficher la vue, où nous mettons les fonctions de service. Ils sont bloqués avec.say, j'ai un membre membre (qui contient des propriétés pour afficher les points de vue des membres) alors où je mets "DreateMember () '', 'Supprimer ()' Fonctions qui ont un accès à la base de données MySQL. Je mets cela dans une classe nommée des membres et mettez cela dans le fichier MemberModel.Elogère cette bonne voie?


CreateMemember () et les fonctions comme elles doivent exister dans la bibliothèque principale puisqu'il possède une logique commerciale et vous parle de votre base de données. Vous pouvez avoir du code dans votre modèle qui appelle ces fonctions.