Il codice automatizzato ASP.NET MVC è abbastanza buono da essere utilizzato nelle applicazioni live reali [chiuso]

3

Ho cercato di sporcarmi le mani con ASP.NET MVC che sembra abbastanza buono (non sono sicuro, ma alcuni utenti dicono che persino StackOverflow e altri siti Web di StackExchange ne hanno fatto uso). Il tutorial che seguo è asp.net , denominato MVC Music Store . È un tutorial piuttosto veloce e anche buono. La domanda che mi dà fastidio mentre passo attraverso i vari tutorial disponibili su questo sito incluso MVC Music Store è il codice automatizzato utilizzato per svilupparli.

Ad esempio, questo tutorial fa uso di Entity Framework 4, che supporta un paradigma di sviluppo chiamato code-first. Aggiungete una classe Entity che eredita dal contesto del database Entity Framework, aggiungete due righe di codice e gestirà le nostre operazioni di creazione, lettura, aggiornamento ed eliminazione per noi.

public class MusicStoreEntities : DbContext
{
    public DbSet<Album> Albums { get; set; }
    public DbSet<Genre> Genres { get; set; }
}

Allo stesso modo, quando ho usato la funzione Scaffolding mentre aggiungevo un controller, come segue:

Fa un sacco di lavoro da solo:

  • Crea il nuovo StoreManagerController con una variabile Entity Framework locale
  • Aggiunge una cartella StoreManager alla cartella Viste del progetto
  • Aggiunge la vista Create.cshtml, Delete.cshtml, Details.cshtml, Edit.cshtml e Index.cshtml, strongmente digitati nella classe Album.

Come puoi vedere, la vita dello sviluppatore ha reso molto più facile con questa automazione, ma la domanda rimane: se questo codice automatico è abbastanza buono per lo sviluppo della produzione? Qualcuno usa (COSÌ) li usa. C'è qualche svantaggio associato a questi codici o uno dovrebbe essere incoraggiato a usarli?

    
posta Pankaj Upadhyay 20.09.2011 - 15:01
fonte

5 risposte

2

C'è una ragione per cui si chiama Scaffolding. È solo lì per ridurre il codice di codice.

Ecco cosa dice Webster riguardo alla versione della vita reale:

Scaffolding: 1. A temporary structure on the outside of a building, made of wooden planks and metal poles, used by workers while building, repairing, or cleaning the building.

Si chiama scaffolding perché non è l'applicazione reale . È solo una struttura che ti aiuta a minimizzare il codice dello standard. Ecco come utilizzare correttamente lo scaffold MVC:

  1. La mia app si troverà vicino allo scaffolding - Quindi genera lo scaffolding e modifica il codice come meglio credi.
  2. La mia app non è affatto vicina a ciò che fornisce lo scaffold e la maggior parte dei controller sono molto diversi . A volte è così fuori dai soliti percorsi di un'app CRUD che devi prendere in mano la situazione. Basta creare un nuovo controller e iniziare la codifica. Nessun danno fatto lì.
  3. La mia app non è affatto vicina all'impalcatura, ma ogni vista e controller è molto ripetibile. - I modelli di scaffold MVC sono molto personalizzabili, così tanto che puoi crea il tuo ! MVC utilizza i modelli T4 che sono completamente personalizzabili, quindi se la tua azienda ha degli standard di codifica particolari a cui ti attendi, o vuoi includere qualche codice di codice aggiuntivo all'interno del modello, puoi includerli e far generare a MVC quelli all'interno dei controller / viste. / li>
risposta data 20.09.2011 - 16:45
fonte
6

Se vuoi lavorare con Scaffolding MVC di ASP.NET, dovresti prendere in considerazione questi elementi:

  1. I tag HTML sono definiti nello scaffolding
  2. Gli attributi id e class sono già definiti
  3. L'annidamento dei tag HTML (come mettere un tag <p> all'interno di un tag <div> ) è già definito
  4. Gli helper HTML sono usati di default

Per questi motivi, ogni volta che ho utilizzato ASP.NET MVC Scaffolding in applicazioni reali, mi sono ritrovato quasi a cambiare tutto e sostituirlo con codice personalizzato (inclusi livelli di nidificazione, tag HTML, id e class attributi per scopi di progettazione e JavaScript), usando i miei aiutanti, ecc.

In altre parole, ero un fondo di scaffolding (o generazione di codice in generale), ma in esempi del mondo reale, li ho trovati più tempo e dispendio di energia rispetto alla scrittura da zero.

Si potrebbe obiettare che è possibile creare il proprio ponteggio personalizzato. Sì, è corretto, ed era quello che volevamo fare come strumento alternativo. Anche Pluralsight ha un buon video su questo argomento . Ma sfortunatamente, ci siamo trovati ad implementare impalcature personalizzate invece di concentrarci sull'attività principale. Questo ovviamente non era auspicabile per il nostro team, e poiché ogni e quasi ogni pagina della nostra applicazione aveva un tipo di architettura diversa, gli sviluppatori hanno accettato di creare la struttura manualmente.

Quindi, la mia risposta, basata sulla produttività del nostro team e sui motivi sopra citati, è la seguente:

No, non è abbastanza buono per le applicazioni del mondo reale, e in realtà ti rallenta.

    
risposta data 20.09.2011 - 16:11
fonte
2

Il codice generato è un punto di partenza: è progettato per farti funzionare il più rapidamente possibile.

Tuttavia, poiché viene generato, non può tenere conto di tutte le possibili considerazioni. È solo un'impalcatura.

L'idea è di usarla e crearla per soddisfare le tue particolari esigenze, aggiungendo sicurezza, scalabilità, registrazione e qualsiasi altra cosa tu abbia bisogno.

SO non usa EF - le sue esigenze di performance non sono state soddisfatte da esso. Hanno scritto (e hanno aperto) una light orm - Dapper , ma molte organizzazioni usano EF.

    
risposta data 20.09.2011 - 15:05
fonte
0

Ho trovato le pagine impalcate più che adeguate per il lato amministrativo interno, per arrivare al mercato più velocemente. Potrebbe non soddisfare tutti i bisogni degli utenti, ma è sufficiente per concentrarmi sul lato pubblico. Una volta fatto, posso tornare e rendere le pagine di amministrazione più carine / più funzionali.

    
risposta data 20.09.2011 - 17:19
fonte
0

La risposta rapida è, sì, il codice è abbastanza buono, ma è probabile che non lo userai. Il codice è buono o addirittura migliore, ad esempio il modo in cui qualsiasi altro framework MVC come RoR o Django gestisce la generazione del codice.

La lunga risposta è che in qualsiasi applicazione aziendale reale, probabilmente vorrai lasciare MVC3.NET per quello che è buono, il livello di presentazione. Ti consigliamo di mantenere l'accesso ai dati EF e la tua logica aziendale su una libreria separata e di fare semplicemente riferimento al tuo progetto MVC.

Questo andrà in linea con la separazione delle preoccupazioni e il modello MVC reale al fine di mantenere il codice del livello di presentazione agnostico e il codice aziendale riutilizzabile.

EDIT: Il perché, per me, è quello che ho menzionato prima, lavorando con il "vero" pattern MVC e la separazione delle preoccupazioni ... Il codice generato dal framework MVC3 è strettamente accoppiato con il livello di presentazione. Se in seguito si desidera modificare la presentazione o aggiungere un'interfaccia desktop, non è possibile riutilizzare la stessa logica aziendale. Si tratta di codice liberamente accoppiato.

    
risposta data 20.09.2011 - 17:04
fonte

Leggi altre domande sui tag