ASP.net MVC estructura del proyecto

Question

He creado la siguiente estructura de proyecto para mi nuevo proyecto asp.net mvc cualquiera que fue después de algunos comentarios como la forma en que otras personas están estructurando sus proyectos y si iba a mejorar la mía ...

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 Anthony

Answer 1

llegué estructura similar de los suyos con algunas excepciones:

1. de soporte se llama Infraestructura (espacio de nombres para el uso del conjunto de UI solamente)
2. IoC está en proyecto diferente (proyecto para la funcionalidad de infraestructura utilizada globalmente). La interfaz de usuario tiene StructureMaps Registry solo con nombres de ensamblado (IoC se inicializa por convención). Método de aproximación robado de la fuente CodeCampServer. Las secciones de registro y configuración van aquí también.
3. Views/[ControllerName] tiene una subcarpeta parcial que puede estar aún más dividida
   (esto implica hacer malabares con ViewEngine para que pueda encontrar vistas/vistas parciales).
4. Vistas/[ControllerName] tiene la carpeta LocalResources (con la subcarpeta parcial)
5. No se ha agregado ninguna subcarpeta bajo Controladores (... todavía). Me gusta mantenerlos limpios y bastante estúpidos.

Y algunas excepciones, más relacionados 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. Los modelos de visualización (los estoy llamando ViewData) viven en el conjunto de la interfaz de usuario en la carpeta ViewData, estructurados en carpetas similares a las Vistas. El enfoque elegido de Kigg (excepto que los estructuro por Vista como SearchViewData, a veces incluso por vista parcial).

funciona lo suficientemente bien hasta ahora

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

Oh ... y => carpeta == namespace para mí. Supongo que es una buena práctica.

Answer 2

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 que en proyectos pequeños es un buen enfoque siempre que tenga su separación de preocupaciones, no coloque la lógica de negocios en el (los) repositorio (es), etc. La tentación en un proyecto más pequeño es difuminar las líneas pero MVC tiende a castigarte un poco cuando haces eso. :)

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 3

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

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

Answer 4

MVC Sitio
aplicación - todos los archivos estáticos
--common
---- css
------ estilos-la mayoría-pages-use.css
- --imgs
------ imágenes-la mayoría-pages-use.png
---- js
------ tu-custom-lib.js
--files
- ---release_notes.md
---- release_notes.html
--pages
---- signin
------ ------ signin.css
logo.png
----- -signin.js
---- salpicadero
------ dashboard.js
--vendors
---- jQuery
------ jquery.1.11.1.js
-_references.js

Controladores - únicos controladores delgadas, código sólo para llamar a sus funciones de biblioteca núcleo
modelos - únicos modelos que se utilizan para mostrar la vista
Vistas - único código de cliente como HTML, maquinilla de afeitar, css, etc

Biblioteca principal
Básicamente todo el código ... acceso a datos, atributos personalizados, utilidades, etc. Separar el código del núcleo a solo una biblioteca es útil por muchas razones. Su lógica no está ligada solo a un sitio web ahora. Si lo necesito, puedo construir una interfaz rápida en WinForms para probar algo de lógica o podría usar las mismas funciones en su capa de acceso a datos para construir una interfaz de administrador para la base de datos.

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

actualización
Me'v actualiza la estructura de archivos de contenido estático a ser más flexible y moderna. Se me ocurrió esta estructura cuando trabajo con AngularJS. Eventualmente pasé al RactiveJS. Después de mudarse a RactiveJS, la misma estructura funcionó muy bien.

Actualización 21/08/15 Me'v estado trabajando en proyectos más grandes y últimamente han estado separando la biblioteca Core a 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 hacer una actualización de SVN para obtener los cambios.También estalló el sitio MVC en su propio proyecto también.