Diseño / herencia del modelo MVC

Question

Perdona el título vago, no estaba seguro de cómo describirlo.

Si tiene un modelo genérico '' Archivo '', ¿cómo muestra diferentes vistas / formularios en función de un 'tipo' seleccionado por el usuario?

Por ejemplo, el usuario crea un nuevo " Archivo " ;, luego obtiene la opción de video, libro, audio, etc. A partir de ahí, obtiene diferentes formularios según el tipo de archivo.

¿O sería mejor dividirlos en diferentes modelos: video, libro, audio?

O pueden heredar los modelos (como Video extiende Archivo). Supongo que esto es OOP / clases básicas, pero no tengo idea de cómo aplicar eso aquí.

¡Los ejemplos de cualquier marco MVC son bienvenidos!

Answer 1

Parece que no desea que el tipo herede de Archive. " Siempre favorece la encapsulación / contención sobre la herencia " ;.

¿Por qué no crear una clase llamada Archive y darle una propiedad de tipo? El tipo puede usar herencia para especializarse en Audio, Video, etc.

Parece que se especializaría en Archive según otros criterios. " FileSystemArchivce " ;, " XMLArchive " ;, " SQLArchive " y el tipo no cambiaría. Pero el agilista en mí dice que esto puede no ser necesario al principio, y siempre puedes refactorizar el diseño más tarde ...

En términos de un controlador, es probable que obtenga el mayor beneficio al encapsular las diferencias de presentación para cada tipo en la vista. Entonces, solo la vista cambia según el tipo. Probablemente la semántica y las reglas para cada una son las mismas y no necesitaría tener controladores separados para cada tipo. Las vistas serán diferentes para cada tipo, ya que tendrán diferentes atributos.

Answer 2

En realidad, mostrar una vista diferente debería ser fácil en cualquier marco MVC. Por ejemplo, en Microsoft ASP.NET MVC no solo devolvería una vista desde un controlador como el siguiente:

return View();

pero en realidad indicaría el nombre de la vista como parámetro:

return View("VideoArchive");

que luego mostraría la vista desde Views / Archive / VideoArchive.aspx

Answer 3

Sus modelos de Video, Libro y Audio pueden heredar de Archivo.

Y cada modelo tendrá un controlador.

http: // yourserver / Books / Edit / 11

Tendrá que hacer que su usuario elija el tipo de archivo que desea antes de crear el modelo correspondiente.

EDITAR (en respuesta al comentario)

En ASP.NET MVC su modelo será una clase.

public class Video : Archive
{  
    public int Id {get;set}
    public string Name {get;set;}     
    ...
}

También tendrá un controlador

public class VideoController : Controller
{
    public object Edit(int id)
    {
        Video myVideo = GetVideo(id);
        return View("Edit", myVideo);
    }
     ...
}

Y tendrá una vista en el directorio Vistas, por ejemplo, la página que contiene

public class Edit : View<Video>
{
    ...
}

Entonces puede llamar a esto si tuviera una URL que fuera

http: // localhost / Video / Edit / 11

Todo esto se hizo desde la memoria, por lo que puede haber algunos errores, pero el mensaje final es que debe especificar la herencia en el modelo. El modelo es solo una clase. En su caso, desea heredar de Archive. Una vez que haya hecho eso, el modelo se distribuirá normalmente.

Answer 4

Me parece que un punto sólido a favor de MVC es que es posible que no necesite personalizar el modelo (o el controlador, del que desea solo uno) si todo lo que el usuario necesita es una vista diferente. Aparecerían varios modelos solo si la arquitectura de almacenamiento (persistencia) dictaminara la necesidad de ello. Algunas características, como los objetos de acceso a datos (DAO), podrían aparecer como otro nivel, entre el controlador y el modelo, en caso de que necesite varios modelos.

Eche un vistazo al proyecto Apache Struts para ver ejemplos. Como se indica en Struts for Newbies , " Para usar Struts bien, es importante tener una buena comprensión de los fundamentos. Comience por revisar el Introducción a las tecnologías clave , y estudie cualquier tema desconocido. & Quot;

Para otro recurso, consulte Aplicación de nivel web Diseño del marco (planos Sun J2EE)

Answer 5

El Principio de responsabilidad única (PDF) establece que:

  

NUNCA DEBE HABER MÁS DE UNA RAZÓN PARA QUE UNA CLASE CAMBIE.

Su clase Archive viola este principio al manejar múltiples tipos diferentes de archivos. Por ejemplo, si necesita actualizar el archivo de video, también está modificando la clase que maneja los libros y archivos de audio.

La forma adecuada de manejar esto es crear clases separadas para cada tipo diferente de archivo. Estos tipos deben implementar una interfaz común (o heredar una clase base común) para que puedan ser tratados de manera intercambiable (polimórfica) por un código que solo se preocupe por los Archivos, no por los tipos de archivos específicos.

Una vez que tenga esa jerarquía de clases en su lugar, solo necesita un único controlador y vista para cada clase de modelo.

Para puntos de bonificación, el Principio de Responsabilidad Única puede incluso justificar el uso de un método de fábrica o una fábrica abstracta para crear su modelo, vista y objetos de controlador (en lugar de renovarlos en línea). Después de todo, crear un objeto y usar ese objeto son diferentes responsabilidades, que pueden necesitar ser cambiadas por diferentes razones.