asp.net - visual - framework asp net

Enrutamiento ASP.NET MVC basado en valores de almacén de datos

Question

¿Cómo abordarías este problema?

Tengo datos en mi tienda de datos. Cada elemento tiene información sobre:

• URL = una cantidad arbitraria de los primeros segmentos de ruta que se usarán con las solicitudes
• algún tipo de elemento = visualización se relacionará con este tipo (seguir leyendo)
• title = usado, por ejemplo, en la navegación alrededor de mi aplicación
• etc.

Como cada elemento puede tener un número arbitrario de segmentos, creé una ruta personalizada, que me permite manejar este tipo de solicitudes sin usar la ruta predeterminada y tener un único parámetro de ruta codicioso.

El tipo de elemento realmente definirá de qué forma se debe mostrar el contenido de un artículo en particular al cliente. Estaba pensando en crear la misma cantidad de controladores para no tener demasiados códigos en una sola acción de controlador.

Entonces, ¿cómo harías esto en ASP.NET MVC o lo que sugerirías sería la forma más factible de hacer esto?

Editar: algunos detalles más

Mis artículos se almacenan en una base de datos. Como pueden tener tipos muy diferentes (no heredables) pensé en crear tantos controladores como sea posible. Pero surgen preguntas:

1. ¿Cómo debo crear estos controladores en cada solicitud ya que están relacionados con algunos datos dinámicos? Podría crear mi propia fábrica de Controller o Route Handler o posiblemente algunos otros puntos de extensión también, pero ¿cuál sería el mejor?

2. Quiero usar la funcionalidad básica MVC de usar cosas como Html.ActionLink(action, controller, linkText) o hacer mi propia extensión como Html.ActionLink(itemType, linkText) para hacerlo aún más flexible, por lo que el enlace de Acción debería crear las rutas correctas basadas en los datos de la ruta (porque eso es lo que sucede en segundo plano: recorre las rutas de arriba hacia abajo y ve cuál devuelve una URL resultante).

3. Estaba pensando en tener una configuración de relación entre itemType y valores de ruta (controlador, acción, valores predeterminados). La configuración predeterminada puede ser complicada ya que los valores predeterminados se deben deserializar de una cadena de configuración a un objeto (que también puede ser complejo). Así que pensé en tal vez incluso tener una relación configurable entre itemType y el tipo de clase que implementa una cierta interfaz como se escribe en el siguiente ejemplo.

4. Mis rutas se pueden cambiar (o agregar algunas nuevas) en el almacén de datos. Pero los nuevos tipos no deberían agregarse. La configuración proporcionaría estos escenarios, ya que vincularían los tipos con los valores predeterminados de las rutas.

Ejemplo :

Definición de la interfaz:

public interface IRouteDefaults
{
    object GetRouteDefaults();
}

Ejemplo de implementación de interfaz:

public class DefaultType : IRouteDefaults
{
    public object GetRouteDefaults()
    {
        return new {
            controller = "Default",
            action = "Show",
            itemComplex = new Person {
                Name = "John Doe",
                IsAdmin = true
            }
    }
}

Ejemplo de configuración:

<customRoutes>
    <route name="Cars" type="TypeEnum.Car" defaults="MyApp.Routing.Defaults.Car, MyApp.Routing" />
    <route name="Fruits" type="TypeEnum.Fruit" defaults="MyApp.Routing.Defaults.Fruit, MyApp.Routing" />
    <route name="Shoes" type="TypeEnum.Shoe" defaults="MyApp.Routing.Defaults.Shoe, MyApp.Routing" />
    ...
    <route name="Others" type="TypeEnum.Other" defaults="MyApp.Routing.Defaults.DefaultType, MyApp.Routing" />
</customRoutes>

Para abordar el impacto en el rendimiento, puedo almacenar en caché mis elementos y trabajar con datos en memoria y evitar acceder a la base de datos en cada solicitud. Estos artículos tienden a no cambiar con demasiada frecuencia. Podría almacenarlos en caché durante 60 minutos sin degradar la experiencia de la aplicación.

Answer 1

El concepto general que mencionas no es infrecuente y hay algunas cosas que debes considerar:

1. En el momento en que escucho que el enrutamiento de URL toma una dependencia de los datos provenientes de una base de datos, lo primero que pienso es en el rendimiento. Una forma de aliviar las preocupaciones potentes sobre el rendimiento es usar la clase incorporada en la ruta y tener un patrón muy genérico, como "somethingStatic/{*everythingElse}" . De esta forma, si la URL no comienza con "somethingStatic", no coincidirá de inmediato y el enrutamiento continuará en la siguiente ruta. A continuación, obtendrá todos los datos interesantes como el parámetro catch-all "everythingElse".

2. A continuación, puede asociar esta ruta con un controlador de ruta personalizado que deriva de MvcRouteHandler e invalida GetHttpHandler para ir a la base de datos, dar sentido al valor "everythingElse" y quizás determinar dinámicamente qué controlador y qué acción se deben usar para manejar esta solicitud. Puede obtener / establecer los valores de enrutamiento accediendo a requestContext.RouteData.Values .

3. Ya sea para usar un controlador y una acción o muchos de uno o muchos de cada uno es una discusión en sí misma. La pregunta se reduce a cuántos tipos diferentes de datos tienes? ¿Son en su mayoría similares (son todos libros, pero algunos son de tapa dura y otros son de tapa blanda)? Completamente diferente (algunos son autos, algunos son libros y algunos son casas)? La respuesta a esto debería ser la misma respuesta que tendrías si se tratara de una clase de programación informática y tuvieras que decidir desde una perspectiva de POO si todos tienen una clase base y sus propios tipos de derivación, o si podrían representarse fácilmente por un tipo común. Si son todos tipos diferentes, recomendaría diferentes controladores, especialmente si cada uno requiere un conjunto distinto de acciones. Por ejemplo, para una casa, es posible que desee ver un informe de inspección. Pero para un libro es posible que desee obtener una vista previa de las primeras cinco páginas y leer una reseña del libro. Estos elementos no tienen nada en común: las acciones para uno nunca se usarían para el otro.

4. Sin embargo, el problema descrito en el n. ° 3 también puede ocurrir al revés: ¿qué pasa si tienes 1,000 tipos de objetos diferentes? ¿Quieres 1000 controladores diferentes? Sin tener más información, diría que para este escenario, 1000 controladores es demasiado.

Esperemos que estos pensamientos lo guíen a la solución correcta. Si puede proporcionar más información sobre algunos de los escenarios específicos que tiene (por ejemplo, qué tipo de objetos son y qué acciones pueden aplicarse a ellos), la respuesta también puede refinarse.

Answer 2

No hay un problema de rendimiento significativo si define un diccionario de enrutamiento complejo, o simplemente tiene una entrada de enrutamiento genérica y maneja todos los casos usted mismo. El código es código

Incluso si sus tipos de datos no son heredables, lo más probable es que tenga patrones de visualización comunes. p.ej

• Lista de títulos y texto resumen
• visualización del elemento, con título, imagen, descripción
• etc

Si puede desglosar su sitio en un número finito de patrones de visualización, entonces solo necesita hacer esos controles finitos y vistas

Usted les proporciona una capa de servicios que se selecciona mediante el parámetro de enrutamiento que utiliza un patrón de objetos de transferencia de datos (DTO) para tomar los datos del caso y moverlos a la estructura de datos estándar para la vista