route - Área de Administración en Asp.Net MVC

select asp-for asp-items

Question

Mi pregunta puede ser obvia, pero me gustaría crear una aplicación web bien diseñada. Al igual que en cualquier área de administración, el administrador debe poder listar / crear / eliminar / modificar usuarios, artículos, publicaciones, etc.

Me gustaría saber cuál es la mejor manera de diseñar la aplicación. Debo crear un controlador para cada uno de esos elementos (/ Users / Create / id o / Posts / Delete / id), o crear toda la acción en mi Administration Controller (/ Administration / CreateUser / id o / Administration / DeletePost / carné de identidad) ?

Answer 1

Actualmente estoy usando ASP.NET para un gran cliente.

El enfoque que he adoptado es poner la funcionalidad de la acción en otra clase.

Ejemplo

También estoy escribiendo una sección de administración. Habrá un controlador de administración (nuestra sección de administración es pequeña, si fuera más grande cambiaría el enrutamiento para permitir más controladores, por ahora estamos usando la configuración lista para usar). Si creo una vista "EditUser". También crearé una clase "EditUserAction". Todo el código de EditUser entrará en la clase. Construyo la clase EditUserAction en la clase del controlador de administración en el método Edit User. Esto elimina todo el código de acción específica de la clase Controller. De esta manera, todo el código específico de la acción se encuentra en el método de acción o en la clase de acción. De lo contrario, el controlador se saturaría rápidamente con el código de varias acciones. La clase de controlador se convertiría en un desastre inmanejable en poco tiempo.

Ejemplos de clase

public class Administration: Controller
{
    public ActionResult EditUser(string userId)
    {
        EditUserAction action = new EditUserAction();
    }
}

public class EditUserAction
{
    public void Save(User user)
    {   
        //save code here
    }
}

Espero que esta explicación sea clara. Si no es así, hágamelo saber y lo aclararé.

Para responder a su pregunta, lo hago a la última ( / Administration / CreateUser / id o / Administration / DeletePost / id ).

Answer 2

Aquí hay otra forma de hacer mi pregunta.

Una parte de mi página maestra:

<% if (!String.Equals(ViewContext.RequestContext.RouteData.GetRequiredString("controller"), "Administration")) { %>
<div>
    <!-- Some Code -->
</div> <% } %>

Como puede ver, en mi página maestra, me gustaría mostrar alguna parte de la página, dependiendo del usuario que trabaja en el área de administración o no. Funciona bastante bien solo con Administration Controller (/ Administration / CreateUser / id) ... pero se convierte en un gran lío cuando uso un controlador diferente como User o Article (/ User / DeleteUser / id o / Article / Details / id) .

Preferiría usar un controlador por entidad, pero no puedo encontrar una manera de vincular este enfoque con múltiples controladores.

Answer 3

Debe escribir un controlador separado para cada entidad para mantener una clara separación de preocupaciones para sus clases de controlador. Si solo tiene un controlador, solo tendrá un directorio de Vistas con docenas de vistas, y su controlador contendrá docenas de métodos, y eso pronto será inmanejable.

Answer 4

Depende del tamaño de la escala de su área de administración, le sugiero que considere hacer lo siguiente (o tal vez documentarlo un poco)

• Considere cuántas entidades desea gestionar de forma independiente,
• Considera cuántas acciones tendrá cada uno,
• Compruebe que exista una dependencia entre su aplicación y el área de administración (acceso de usuario, para direcciones URL fáciles de usar)

luego puede especificar qué enfoque puede ayudarlo, tener un controlador de administrador, acciones de administrador en los controladores de entidad o definir un nuevo proyecto de administrador en caso de aplicaciones funcionales grandes.

* Si la escala del proyecto está creciendo rápidamente y pronto se necesita una gran escala, elegiría la tercera: tener un nuevo proyecto de administración de mvc.

Espero que te ayude a decidir.

Answer 5

La respuesta depende de cuánta funcionalidad habrá en los controladores. Simplemente comience con un controlador y, si se pone demasiado, divídalo en unos pocos. Lo bueno de MVC es que poner las cosas en sus controladores no tiene que tener ningún efecto en las URL. puede fácilmente asignar / Usuarios / Crear a, por ejemplo, la clase UserAdminController.

Answer 6

Podrías usar DynamicData para esto. No es MVC, pero se puede usar junto con él y es muy fácil de configurar y usar.

Answer 7

Simplemente construiría un nuevo sitio web de MVC que maneje la administración. Tiene una solución más flexible siempre que haya separado los datos y la lógica empresarial en diferentes ensamblajes. Luego puede publicar su sitio web en un subdominio, admin.yoursite.com por ejemplo. De esa manera, no tiene que meterse con sus rutas y puede mantenerlas en vistas separadas, ya que imho es la solución más elegante. Pro y Con sería bueno escuchar.

Estoy trabajando en un proyecto que necesitará el mismo sitio de administración, pero aún no he llegado tan lejos, por lo que esta pregunta me interesa mucho.

Answer 8

Sugiero utilizar esta solución .

Pero cambié de definición a esto:

    public ThemedViewEngine()
    {
        base.MasterLocationFormats = new string[] {
            "~/Views/{1}/{0}.master", 
            "~/Views/Shared/{0}.master",
            "~/Themes/{2}/Views/{1}/{0}.master", 
            "~/Themes/{2}/Views/Shared/{0}.master",
            "~/Themes/Default/Views/{1}/{0}.master", 
            "~/Themes/Default/Views/Shared/{0}.master"
        };
        base.ViewLocationFormats = new string[] { 
            "~/Views/{1}/{0}.aspx", 
            "~/Views/{1}/{0}.ascx", 
            "~/Views/Shared/{0}.aspx", 
            "~/Views/Shared/{0}.ascx",
            "~/Themes/{2}/Views/{1}/{0}.aspx", 
            "~/Themes/{2}/Views/{1}/{0}.ascx", 
            "~/Themes/{2}/Views/Shared/{0}.aspx", 
            "~/Themes/{2}/Views/Shared/{0}.ascx",
            "~/Themes/Default/Views/{1}/{0}.aspx", 
            "~/Themes/Default/Views/{1}/{0}.ascx", 
            "~/Themes/Default/Views/Shared/{0}.aspx", 
            "~/Themes/Default/Views/Shared/{0}.ascx" 
        };
        base.PartialViewLocationFormats = new string[] {
            "~/Views/{1}/{0}.aspx",
            "~/Views/{1}/{0}.ascx",
            "~/Views/Shared/{0}.aspx",
            "~/Views/Shared/{0}.ascx",
            "~/Themes/{2}/Views/{1}/{0}.aspx",
            "~/Themes/{2}/Views/{1}/{0}.ascx",
            "~/Themes/{2}/Views/Shared/{0}.aspx",
            "~/Themes/{2}/Views/Shared/{0}.ascx",
            "~/Themes/Default/Views/{1}/{0}.aspx",
            "~/Themes/Default/Views/{1}/{0}.ascx",
            "~/Themes/Default/Views/Shared/{0}.aspx",
            "~/Themes/Default/Views/Shared/{0}.ascx"
        };
    }

El tema predeterminado es el predeterminado por lo que se requiere que exista.

La estructura del directorio será:

• Contenido
• Temas
  • Defecto
    • Contenido
    • Puntos de vista
      • Casa
      • Blog
      • Todo lo que debería ser desollado
  • Otro tema
    • Contenido
    • Puntos de vista
      • Casa
      • Blog
      • Todo lo que debería ser desollado
• Puntos de vista
  • Artículos
  • Mensajes
  • Usuarios
  • Ajustes
  • Otras cosas de la administración