Progettazione / eredità del modello MVC

Question

Perdona il vago titolo, non ero sicuro di come descriverlo.

Se si dispone di un modello generico " Archivio " ;, come si visualizzano visualizzazioni / moduli diversi in base al 'tipo' selezionato dall'utente?

Ad esempio, l'utente crea un nuovo " Archivio " ;, quindi ottiene la scelta di video, libro, audio ecc. Da qui ottengono forme diverse in base al tipo di archivio.

O sarebbe meglio dividerli in diversi modelli: video, libro, audio?

Oppure i modelli possono ereditare (come Video estende Archive). Immagino che questo sia OOP / classi di base, ma non ho idea di come applicarlo qui.

Sono benvenuti esempi da qualsiasi framework MVC!

Answer 1

Sembra che tu non voglia avere il tipo ereditato da Archive. " Favorisce sempre l'incapsulamento / il contenimento rispetto all'ereditarietà " ;.

Perché non creare una classe chiamata Archive e dargli una proprietà type. Il tipo può utilizzare l'ereditarietà per specializzarsi per audio, video, ecc.

Sembrerebbe che tu ti specializzi Archive in base ad altri criteri. " FileSystemArchivce " ;, " XMLArchive " ;, " SQLArchive " e il tipo non cambierebbe. Ma l'agilista in me dice che all'inizio potrebbe non essere necessario, e puoi sempre riformattare il design in seguito ...

In termini di controller, probabilmente otterrai il massimo vantaggio dal dollaro incapsulando le differenze di presentazione per ciascun tipo nella vista. Quindi solo la vista cambia in base al tipo. Probabilmente la semantica e le regole per ognuna sono le stesse e non avresti bisogno di avere controller separati per ogni tipo. Le viste saranno diverse per ciascun tipo in quanto avranno attributi diversi.

Answer 2

Per mostrare effettivamente una vista diversa dovrebbe essere facile in qualsiasi framework MVC. Ad esempio, in Microsoft ASP.NET MVC non si restituirebbe semplicemente una vista da un controller come il seguente:

return View();

ma in realtà indicherebbe il nome della vista come parametro:

return View("VideoArchive");

che mostrerebbe quindi la vista da Views / Archive / VideoArchive.aspx

Answer 3

I tuoi modelli Video, Book e Audio possono ereditare da Archive.

E ogni modello avrà un controller.

http: // yourserver / Books / Edit / 11

Dovrai convincere l'utente a scegliere il tipo di archivio desiderato prima di creare il modello corrispondente.

MODIFICA (in risposta al commento)

In ASP.NET MVC il tuo modello sarà una classe.

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

Avrai anche un controller

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

E avrai una vista nella directory Views, ad esempio, la pagina che contiene

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

Quindi puoi chiamarlo se avevi un URL che era

http: // localhost / Video / Edit / 11

Tutto questo è stato fatto dalla memoria, quindi potrebbero esserci degli errori, ma il messaggio da portare a casa è che si specifica l'eredità nel modello. Il modello è solo una classe. Nel tuo caso vuoi ereditare da Archive. Una volta fatto, il modello viene passato normalmente.

Answer 4

Mi sembra che un punto a favore di MVC sia che potrebbe non essere necessario personalizzare il modello (o il controller - di cui si desidera solo uno) se tutto ciò di cui l'utente ha bisogno è una visione diversa. Più modelli apparirebbero solo se l'architettura di archiviazione (persistenza) ne imponesse la necessità. Alcune funzionalità come gli oggetti di accesso ai dati (DAO) potrebbero apparire come un altro livello, tra il controller e il modello, nel caso in cui siano necessari più modelli.

Dai un'occhiata al progetto Apache Struts per esempi. Come indicato in Struts for Newbies , " Per usare bene Struts, è importante avere una buona conoscenza dei fondamenti. Inizia esaminando il Primer sulle tecnologie chiave e studiando eventuali argomenti non familiari. & Quot;

Per un'altra risorsa, vedi Applicazione di livello Web Design del framework (modelli Sun J2EE)

Answer 5

Il Principio di responsabilità individuale (PDF) afferma che:

  

NON DOVREBBE MAI ESSERE PIÙ DI UN MOTIVO PER CAMBIARE UNA CLASSE.

La tua classe Archive viola questo principio gestendo diversi tipi di archivi. Ad esempio, se è necessario aggiornare l'archivio video, si sta anche modificando la classe che gestisce gli archivi di libri e audio.

Il modo appropriato di gestirlo è creare classi separate per ogni diverso tipo di archivio. Questi tipi dovrebbero implementare un'interfaccia comune (o ereditare una classe base comune) in modo che possano essere trattati in modo intercambiabile (polimorficamente) con il codice che si occupa solo degli archivi, non di tipi di archivio specifici.

Dopo aver creato quella gerarchia di classi, è sufficiente un singolo controller e visualizzare per ogni classe di modello.

Per i punti bonus, il singolo principio di responsabilità può persino giustificare l'uso di un metodo factory o factory astratto per la creazione di oggetti modello, vista e controller (anziché sostituirli in linea). Dopotutto, la creazione di un oggetto e l'utilizzo di tale oggetto sono responsabilità diverse, che potrebbero dover essere modificate per motivi diversi.