Com'è comune / accettabile che uno sviluppatore .NET si astenga dai WebForm di regola? [chiuso]

0

Lavoro in un negozio prevalentemente .NET.

Un collaboratore ha un maggiore background in MVC open-source (si pensi a RoR e Spring MVC). Sembra davvero apprezzare .NET MVC, ma si rifiuta praticamente di lavorare su Web Form e ha difficoltà a cambiare marcia / lavorare nelle app Web Form. E sento cose simili da altri.

Anche io preferisco di gran lunga .NET MVC, ma non sono al di sopra del lavoro Web Form. Non ho mai incontrato questo significativo strumento di divisione all'interno di una comunità, come Java.

Quanto è accettabile / comune questo tra gli sviluppatori .NET? C'è una consapevolezza di questo genere di cose nel settore / comunità .NET, ovvero un gruppo di sviluppatori che sono gung-ho su MVC ma aborrono WebForms? Qualcuno può fare carriera in .NET solo facendo MVC? Come indicheresti ai datori di lavoro che eri una tale persona?

    
posta mmcrae 22.06.2016 - 02:36
fonte

1 risposta

10

La mia osservazione è che WebForms è in declino. C'è una buona ragione per quello. Avendo ampiamente utilizzato WebForm in passato, è difficile fare qualcosa fuori dagli schemi. Oltre ai controlli di apprendimento dell'aspx e al loro corretto utilizzo, ci sono molte minuzie tecniche per apprendere il ciclo di vita della pagina quando si va oltre le basi. E alla fine, stai scrivendo in un linguaggio proprietario basato su XML che si traduce (spesso male) in HTML + JS che devi effettivamente supportare nei browser di destinazione. Spesso l'implementazione del rendering del controllo passa attraverso il tuo problema e devi farlo funzionare con gli hack JS / CSS sull'output renderizzato. Le dichiarazioni sono piuttosto prolisse e a volte non si traducono in ciò che immaginate di fare in HTML. Quando hai bisogno di applicare classi per lo styling, significa che devi anche conoscere intimamente come il controllo rende l'HTML. I controlli delle scorte utilizzano molti standard HTML antiquati come il rendering basato su tabelle. Quindi perché esistono diversi fornitori di controlli di terze parti per WebForms.

(Modifica: non sono nemmeno entrato in View / Control State qui. Devo averlo bloccato. Ecco un articolo di esempio che spiega le interazioni tra il ciclo di vita delle pagine e lo stato di visualizzazione (25 pagine stampate).)

MVC e le strutture client-side successive come Angular amano esporvi direttamente all'HTML / JS perché è ciò che effettivamente avete bisogno di sapere e avere comunque il controllo. Nota esistono fornitori di controllo MVC di terze parti che rendono alcuni HTML / JS per te.

I miei ex datori di lavoro hanno utilizzato progetti WebForms (alcuni ampiamente). Ne ho creati diversi Io mantengo diversi in produzione oggi della mia o di altre creazioni. Penso che chiunque conosca lavorando su progetti WebForms ora li considera "legacy" e li tocca solo quando richiesto. La nuova funzionalità viene migrata a qualcos'altro. Abbiamo pagine angolari all'interno della maggior parte dei nostri progetti WebForm in cui erano necessarie nuove funzionalità.

Specificamente del tuo collega di lavoro. Se WebForms è qualcosa che il tuo team supporta, allora va contro la maggior parte delle pratiche agili per essere specializzato solo su MVC. "Chiunque nella squadra dovrebbe essere in grado di svolgere qualsiasi compito". Questo è l'ideale Sono stato in team dove era gradito che tutte le parti (ad eccezione del Product Owner) fossero specializzate. Tuttavia, questo può diventare un ostacolo per ottenere le storie con la priorità più alta se la disponibilità della persona specializzata è bassa a causa di vacanza o malattia. Se è un obiettivo della squadra avere tutti allenati in modo trasversale, allora tutti dovrebbero continuare ad allenarsi come se le opportunità si presentassero.

Sono sicuro che qualcuno potrebbe fare una carriera facendo solo MVC in .NET. È abbastanza facile indicare la tua preferenza ai datori di lavoro su un curriculum e nelle interviste. Tuttavia, non mi limiterei a questo. MVC su .NET è una tecnologia (e una meno utilizzata nel grande schema) e i tecnici vanno e vengono. Non uso WebForms o MVC per i nuovi front-end Web e non ho perso nessuno dei due. MVC a volte si intrufola nel lato API delle cose perché si è mescolato con le API Web su alcuni modelli di progetto.

    
risposta data 22.06.2016 - 03:46
fonte

Leggi altre domande sui tag