Helpers ASP MVC HTML - Buono o cattivo?

Question

Capisco la ragione per avere gli helper HTML in ASP.NET MVC ed estendere questo per fornire il proprio, ma mi chiedo se usare helper HTML sia una buona idea.

Ho pensato che uno dei vantaggi di ASP.NET MVC è il controllo dell'HTML. Se inizi a nasconderlo nelle funzioni di supporto che generano HTML non inizi a perdere visibilità? Immagino che questo non sia un problema quando si generano controlli semplici come un pulsante, ma ho visto l'uso di helper html per creare griglie e output HTML più complessi.

Ora capisco anche che la ragione per farlo è mantenere le cose ASCIUTTE, evitando duplicazioni. Ma non c'è il pericolo di avere qualcosa di simile al codice, qui dietro? Inoltre, cosa succede se lavori in collaborazione con i designer? Generalmente il designer creava il markup e applicava lo styling. Se inizi a iniettare la tua vista con gli helper che generano il markup, non rende difficile tale collaborazione?

Answer 1

"Il controllo sull'HTML" è microsoft marketing-speak ed è il modo in cui scelgono di marcare la piattaforma. Il punto di ASP.net MVC è che è una soluzione più semplice e adatta per le applicazioni web, quindi l'intero modello di Webform basato sugli eventi, e qualcosa che praticamente tutti gli utenti al di fuori dello spazio Microsoft hanno spostato fino a anni fa. Microsoft non può dirlo, però, perché ha un enorme investimento in webform ed è una parte fondamentale della sua storia aziendale.

Detto questo, se hai una logica di business nei tuoi aiutanti li stai usando male. È fondamentalmente il codice dietro solo per la logica di presentazione duplicata su più pagine e l'obiettivo è di mantenere i tag scriptlet nella marcatura il più semplice possibile.

Fintanto che si utilizzano gli helper nel modo in cui dovrebbero essere utilizzati, dovrebbe essere piuttosto semplice per i progettisti imparare a utilizzare. Basta ricordare che l'obiettivo è di mantenere le cose semplici, se finiscono per rendere le cose più complesse, significa che non vengono utilizzate correttamente.

Answer 2

Ottimo commento, Matt. C'è ancora la domanda se in una "pura" implementazione MVC, gli helper HTML sono una buona idea. Penso che sia la parola magica, "pura". Ogni volta che rallento per pensare al modo "corretto" di fare le cose, sto davvero cercando di capire se un approccio particolare si adatta alla visione del purista. Quindi, un purista dovrebbe usare gli helper HTML?

Ho circa 8/10 puristi e non li userei. Ho visto questo argomento trascendere le tecnologie e sollevato il problema con MVC in PHP e il framework Zend. Semplicemente non mi sembra giusto e per me, questa è la misura migliore che si possa trovare.

Answer 3

Non c'è decisamente niente di sbagliato con gli aiutanti. Sono usati per mantenere le tue opinioni pulite e dichiarative. C'è un detto che dice qualcosa come "se c'è un'affermazione" se "nella tua visione, stai sbagliando". Sono utilizzati in molti importanti framework MVC come Ruby On Rails e Cake PHP. Controlla this post. "Purista" o no, gli aiutanti sono una buona cosa e non devono essere confusi con le cattive pratiche o le astrazioni che perdono.

Answer 4

Penso che un punto importante che gli altri non hanno menzionato è la portabilità delle vostre opinioni.

È possibile spostare HTML, JavaScript e CSS su un'applicazione su un'altra piattaforma immediatamente. Non devi convertire tutti i brutti HTMLHiders .. scusa, HTMLHelpers .. al vero HTML.

Mentre ho il massimo riguardo per il framework .NET che riduce il mio tempo di sviluppo e semplifica il mio lavoro, sento fortemente che le visualizzazioni dovrebbero essere non proprietarie.

È comunque possibile ottenere quasi tutti i vantaggi dal framework nel modello e nel controller. Iniettare le dipendenze sul framework nel proprio livello di presentazione non vale assolutamente il compromesso, IMO.