Estructura del proyecto ASP.net MVC

Question

He creado la siguiente estructura de proyecto para mi nuevo proyecto asp.net mvc y buscaba algunos comentarios sobre cómo otras personas están estructurando sus proyectos y si mejoraría el mío...

Esto es lo que tengo hasta ahora:

+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

Saludos Antonio

Answer 1

Tengo estructura similar de los suyos con algunas excepciones:

  

  
1. soporte se llama Infraestructura (espacio de nombres para el uso del montaje de la interfaz de usuario única)
  
2. COI está en diferente proyecto (proyecto para la funcionalidad de Infraestructura utilizado a nivel mundial). UI tiene Registro StructureMaps solamente con nombres de ensamblado (COI se inicializa por convención). Enfoque de tipo robado de una fuente CodeCampServer. La tala, las secciones de configuración va aquí también.
  
3. Vistas / [ControllerName] tiene subcarpeta parcial que podría ser aún más dividido
     (Esto implica malabares con ViewEngine por lo que podría encontrar puntos de vista / vistas parciales).
  carpeta
4. Vistas / [ControllerName] tiene LocalResources (con subcarpeta parcial)
  
5. No se ha añadido ningún subcarpeta bajo Controladores (... aún). Me gusta mantenerlos limpios y bastante estúpida.
  

Y algunos más excepciones, relacionada con el modelo:

  

  
1. Toda la lógica de negocio vive en el montaje de dominio, espacio de nombres Domain.Model con algo de ayuda de la capa de infraestructura para los aspectos técnicos.
  
2. Ver modelos (los estoy llamando ViewData) vive en el montaje de interfaz de usuario en la carpeta ViewData, estructurada en carpetas similares a las vistas son. enfoque escogido de Kigg (excepto que i estructurarlos per View como SearchViewData, a veces incluso por visión parcial).
  

funciona lo suficientemente bien hasta ahora

Tenga en cuenta que la estructuración ViewData (i siquiera estructurar mi javascript de la misma manera, Ver archivo == JS que contiene todo bajo objeto nombrado como [ViewName]) por visión podría no ser aceptable para más complicada red sitios.

... y la carpeta Oh => == espacio de nombres para mí. Supongo que es una buena práctica.

Answer 2

Sitio MVC
aplicación - todos los archivos estáticos
--común
----css
------estilos-la-mayoría-de-las-páginas-use.css
----imágenes
------imagenes-mas-paginas-usadas.png
----js
------tu-lib.js personalizado
--archivos
----release_notes.md
----release_notes.html
--páginas
----iniciar sesión
------signin.css
------logotipo.png
------signin.js
----panel
------panel.js
--vendedores
----jQuery
------jquery.1.11.1.js
-_referencias.js

Controladores - solo controladores delgados, solo código para llamar a las funciones principales de su biblioteca
Modelos - Sólo modelos que se utilizan para mostrar la vista.
Puntos de vista - sólo código de cliente como html, razor, css, etc.

biblioteca principal
Básicamente todo el código... acceso a datos, atributos personalizados, utilidades, etc.Separar el código central en solo una biblioteca es útil por muchas razones.Su lógica ahora no está ligada solo a un sitio web.Si lo necesito, puedo construir un front -end rápido en Winforms para probar alguna lógica o podría usar las mismas funciones en su capa de acceso de datos para construir una parte delantera de administración para la base de datos.

Considero que esta estructura es la más simple y flexible para mí.

Actualizar
Actualicé la estructura del archivo de contenido estático para que sea más flexible y moderna.Se me ocurrió esta estructura cuando trabajaba con AngularJS.Finalmente pasé a Ractivejs.Después de pasar a RactiveJS, la misma estructura funcionó muy bien.

Actualización 21/08/15Últimamente he estado trabajando en proyectos más grandes y he estado separando la biblioteca Core en su propio proyecto de Visual Studio.Esto lo hace flexible al usar SVN Externals.Puedo usar la misma biblioteca en diferentes proyectos y solo necesito realizar una actualización SVN para obtener los cambios.También estalló el sitio MVC en su propio proyecto.

Answer 3

He escrito un par de sitios (pequeño) y simplemente pegado con la misma estructura que tenía NerdDinner y parecía funcionar bien.

Creo en proyectos más pequeños que un enfoque bien siempre y cuando usted tiene su separación de preocupaciones, no coloque la lógica de negocio en el repositorio (s), etc. La tentación de un proyecto más pequeño es difuminar las líneas, pero tiende MVC para castigar un poco cuando haces eso. :)

Los proyectos más grandes pueden ver que la implementación de un proyecto de la clase de negocios independiente y el proyecto de traducción de datos tal vez incluso etc.

Answer 4

Creo que esto es un poco demasiado complicado pero si que tiene sentido que vaya con él. Lo importante es mantener el equilibrio.

Una cosa que me gusta ir con proyectos separados dentro de la solución ya que permite la reutilización de acceso a datos y la lógica de negocios para ser reutilizado por otros tipos de aplicaciones cliente, como WPF o WinForms clientes.