Conception de modèle MVC / héritage

Question

Pardonnez le titre vague, je ne savais pas comment le décrire.

Si vous disposez d'un modèle générique "Archive", comment affichez-vous différents affichages / formulaires en fonction du "type" sélectionné par l'utilisateur?

Par exemple, l'utilisateur crée une nouvelle "archive", puis obtient le choix de la vidéo, du livre, de l'audio, etc. De là, il obtient différents formulaires en fonction du type d'archive.

Ou serait-il préférable de les scinder en différents modèles - Vidéo, Livre, Audio?

Ou bien les modèles peuvent-ils hériter (comme Vidéo Archive étend)? Je suppose que ceci est une base de la programmation orientée objet / des cours, mais je ne sais pas comment appliquer cela ici.

Les exemples de tout framework MVC sont les bienvenus!

Answer 1

On dirait que vous ne voudriez pas que le type hérite de Archive. "Privilégiez toujours l'encapsulation / le confinement à l'héritage".

Pourquoi ne pas créer une classe appelée Archive et lui donner une propriété de type. Le type peut utiliser l'héritage pour se spécialiser dans les domaines Audio, Vidéo, etc.

Il semblerait que vous souhaitiez spécialiser Archive selon d’autres critères. "FileSystemArchivce", "XMLArchive", "SQLArchive" et le type ne changerait pas. Mais l'agiliste en moi dit que cela peut ne pas être nécessaire au début, et que vous pouvez toujours refacturer la conception plus tard ...

En termes de contrôleur, vous obtenez probablement le meilleur rapport qualité-prix en encapsulant les différences de présentation pour chaque type dans la vue. Ainsi, seule la vue change en fonction du type. Il est probable que la sémantique et les règles de chacune soient les mêmes et qu'il ne soit pas nécessaire de disposer de contrôleurs distincts pour chaque type. Les vues seront différentes pour chaque type car elles auront des attributs différents.

Answer 2

Afficher un point de vue différent devrait être facile dans tout framework MVC. Par exemple, dans Microsoft ASP.NET MVC, vous ne feriez pas que renvoyer une vue depuis un contrôleur, comme suit:

return View();

mais indiquerait le nom de la vue en tant que paramètre:

return View("VideoArchive");

qui afficherait ensuite la vue à partir de Views / Archive / VideoArchive.aspx

Answer 3

Vos modèles Vidéo, Livre et Audio peuvent hériter d'Archive.

Et chaque modèle aura un contrôleur.

http: // votreserveur / Livres / Éditer / 11

Vous devrez demander à votre utilisateur de choisir le type d'archive qu'il souhaite avant de créer le modèle correspondant.

EDIT (en réponse au commentaire)

Dans ASP.NET MVC, votre modèle sera une classe.

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

Vous aurez également un contrôleur

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

Et vous aurez une vue dans le répertoire Views par exemple, la page qui contient

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

Vous pouvez donc appeler ceci si vous aviez une URL qui était

http: // localhost / Video / Edit / 11

Tout cela a été fait de mémoire, il peut donc y avoir des erreurs, mais le message à retenir est que vous spécifiez l'héritage dans le modèle. Le modèle est juste une classe. Dans votre cas, vous souhaitez hériter d'Archive. Une fois que vous avez terminé, le modèle passe normalement.

Answer 4

Il me semble qu’un point fort en faveur de MVC est qu’il n’est peut-être pas nécessaire de personnaliser le modèle (ou le contrôleur - dont vous n’en voulez qu’un) si tous les utilisateurs ont besoin d’une vue différente. Plusieurs modèles n'apparaîtront que si l'architecture de stockage (persistance) en dictait le besoin. Certaines fonctionnalités telles que les objets d'accès aux données (DAO) apparaîtront potentiellement comme un autre niveau, entre le contrôleur et le modèle, si vous avez besoin de plusieurs modèles.

Consultez le projet Apache Struts pour obtenir des exemples. Comme indiqué dans Struts for Newbies , "Pour bien utiliser Struts, il est important de bien comprendre les principes fondamentaux. Commencez par consulter le introduction aux technologies clés et en étudiant les sujets non familiers. & Quot;

Pour une autre ressource, voir Application Web. Conception de la structure (plans Sun J2EE)

Answer 5

Le principe de responsabilité unique (PDF) indique que:

  

IL NE FAUT JAMAIS ÊTRE PLUS D'UNE RAISON POUR UNE CLASSE DE CHANGER.

Votre classe Archive enfreint ce principe en traitant plusieurs types d'archives différents. Par exemple, si vous devez mettre à jour l'archive vidéo, vous modifiez également la classe qui gère les archives de livres et audio.

La manière appropriée de gérer cela consiste à créer des classes séparées pour chaque type d'archive. Ces types doivent implémenter une interface commune (ou hériter d'une classe de base commune) afin de pouvoir être traités de manière interchangeable (polymorphiquement) par un code qui ne concerne que les archives, pas des types d'archives spécifiques.

Une fois que vous avez mis en place cette hiérarchie de classes, vous n’avez besoin que d’un seul contrôleur et d’une seule vue pour chaque classe de modèle.

Pour les points bonus, le principe de responsabilité unique peut même justifier l’utilisation d’une méthode fabrique ou d’une fabrique abstraite pour créer vos objets de modèle, de vue et de contrôleur (plutôt que de les ajouter en ligne). Après tout, créer un objet et utiliser cet objet relèvent de différentes responsabilités, qu’il faudra peut-être modifier pour différentes raisons.