tag route net for data asp all asp.net asp.net-mvc-3 asp.net-mvc-areas

asp.net - route - tag helpers asp net core



MVC3 ¿Cuándo usar áreas? (3)

Estoy trabajando en un proyecto MVC3 ágil y está empezando a ser bastante grande, específicamente mi sección de administración, donde el usuario puede configurar muchas configuraciones, etc. Este es mi primer proyecto MVC3, por lo que siento curiosidad cuando ¿Tiene sentido usar áreas?

¿Qué tan grande debe ser un controlador para una sección específica como administración antes de decidir dividirlo en un área y crear controladores para las operaciones de administración individuales?

Además, al usar áreas, ¿debo refactorizar el uso de áreas para todo o solo para las secciones que necesitan un área?


Es más práctico cuando necesita un control separado y reutilizar los nombres de los controladores. Como si pudieras usarlo para un sitio de administración, una porción de blog, etc.


Hay tantas opiniones sobre cómo organizar esto como desarrolladores, pero mis opiniones son las siguientes;

Los controladores solo deben ser responsables de interactuar con las vistas. Es decir, crear instancias y rellenar objetos de modelo, recuperar datos de sus objetos comerciales o capa de acceso a datos, responder a cualquier solicitud de la página (envíos de formularios, solicitudes AJAX, interfaz con métodos / clases de creación de recursos dinámicos (como crear CAPTCHA u otra dinámica imágenes)), etc. Si se adhiere a esa filosofía, su tamaño y complejidad nunca deben exceder el de sus puntos de vista.

Áreas que tiendo a usar áreas para dividir la aplicación en sub-aplicaciones. Por ejemplo, un sitio puede tener un foro de discusión, catálogo de productos, información de la compañía, base de datos de soporte, etc., todos los cuales serían áreas separadas:

/areas/forum/... /areas/product/... /areas/company/... /areas/support/...

Entonces, en cada área, podrías tener

/areas/support/{views|controllers} /areas/support/search/ /areas/support/contact/ /areas/support/knowledgebase/

etc.

Al igual que en un sitio de formularios web donde cada carpeta representaba un "área" distinta del sitio web, las áreas brindan otro nivel de organización que le permite mantener los controladores, vistas, etc. relacionados en una ubicación común, y se deben usar de manera similar.


Usamos áreas para distinguir preocupaciones separadas notables dentro de la aplicación. Preocupaciones especialmente separadas que pueden requerir autenticación única o diseño / estilo para cada área. Por ejemplo, estoy trabajando en una aplicación que tiene "módulos" de clases. Cada módulo es un área de mvc y cada módulo como una sección de configuración que también es un área de mvc. La aplicación tiene tres módulos, por lo que es un total de seis áreas, con seis derechos de usuario que los acompañan. Esto permite que cada módulo tenga una nueva "página maestra / diseño" (apariencia) y un nivel de seguridad específico.

Ayuda a separar el código también; El código en AreaA no tiene nada que ver con el código en AreaB, pero a veces AreaA y AreaB usan el código común que se encuentra en la raíz del proyecto.

Las partes que no pertenecen al área del sitio tienen elementos como el inicio de sesión del usuario, las páginas de error (404, etc.), el área principal del "iniciador" para ingresar a los módulos, la gestión de excepciones y otras cosas que abarcan todos los aspectos Zonas de mvc.