L'utilizzo dello stack MEAN riduce la necessità di codice e strutture dati rispetto a ASP.net con SQL?

2

Scrivo applicazioni web da quasi 10 anni. Lo stack ASP.net è stato il mio pane e burro e anche se ha un sacco di cose belle su di esso, onestamente non ho mai scelto ASP.net. È solo una questione di ciò che i miei datori di lavoro e clienti volevano.

Recentemente, ho avuto l'opportunità di prototipare qualcosa che stavo lavorando sullo stack MEAN. Non sono mai riuscito a superare il prototipo prima di essere indirizzato a tornare su ASP.net.

Mi rendo conto che nel corso del mio prototipo nello stack MEAN, ci sono molti aspetti dello stack MEAN che ho trascurato e non ho familiarità con le best practice dello stack MEAN.

Tuttavia, mi è sembrato che scrivendo il codice nello stack MEAN, c'era molto meno codice da scrivere per una ragione particolare: tutto è Javascript e potrei usare le stesse strutture di dati Javascript dattilografate ovunque: sul browser , sul server web e nelle query del mio database.

Nello stack ASP.net, la logica è la seguente per alcune operazioni sui dati:

  1. L'utente fa qualcosa nel browser.

  2. Il Javascript invia una stringa JSON al server web.

  3. Il server web lo indirizza a un gestore e deserializza il JSON in una classe del modello.

  4. Il gestore effettua una chiamata a un oggetto business che mappa la classe del modello su una classe di entità, che a sua volta rappresenta una struttura di dati in SQL.

  5. L'oggetto business effettua una o più chiamate a SQL utilizzando la classe entity e ottiene un risultato che viene serializzato su un'altra classe di entità.

  6. La classe di entità viene mappata su un'altra classe di modello e passata di nuovo al gestore.

  7. Il gestore serializza la classe del modello in JSON, che restituisce la stringa JSON al browser.

Semplice come una torta, vero?

Nello stack MEAN, la logica è la seguente per la stessa operazione di dati.

  1. L'utente fa qualcosa nel browser.

  2. Il server web lo indirizza a un gestore che riceve l'oggetto JSON.

  3. Il gestore effettua una chiamata a un oggetto business, passando nel JSON.

  4. L'oggetto business effettua una o più chiamate a Mongo utilizzando il JSON e ottiene un risultato in JSON.

  5. Il risultato JSON di Mongo viene passato al gestore.

  6. Il gestore passa il risultato JSON al browser.

Oh wow! Era molto più semplice perché nel caso ASP.net avevo diversi tipi di strutture dati su ciascuno dei miei tre livelli e dovevo scrivere codice per tradurre i dati tra le diverse strutture dati, un processo che è sia noioso che errore -prone. Inoltre, ho dovuto scrivere con attenzione le definizioni delle strutture dati su tutti e tre i livelli e accertarmi che corrispondano, e anche quando le strutture dei dati sono "le stesse", sono ancora diverse. (per esempio, i dati DateTime sono completamente diversi sotto le copertine in SQL vs ASP.net)

Non sono un esperto di stack MEAN, quindi volevo sapere se e come questi vantaggi che ho osservato si svolgono nel mondo reale con applicazioni mature.

In breve, usare lo stack MEAN significa che posso scrivere meno codice perché non devo scrivere tre set separati di strutture dati e il codice che le mappa tra loro?

    
posta Rice Flour Cookies 13.04.2018 - 21:28
fonte

1 risposta

2

Non sono un esperto nello stack MEAN, ma ...

Tendo a pensare che ciò che descrivi per il tuo flusso di lavoro ASP.NET è tipico di qualsiasi sistema ben architettato, non qualcosa di simile a .NET.

Se si lavora nello stack JS (la maggior parte dell'esperienza è su Node, Express, Angular, Electron, ecc.), si potrebbe mettere insieme un'esperienza "semplificata" come si descrive, ma questa non è necessariamente una buona architettura a lungo termine. Tuttavia, uno vorrebbe un bel livello di separazione tra presentazione, dominio, accesso ai dati, ecc., Che intrinsecamente significa mappature tra livelli (a differenza degli oggetti condivisi tra tutti i livelli).

Tutto sommato, penso che questa bella separazione degli strati sia di buon auspicio per la manutenibilità a lungo termine, anche se avremmo potuto farlo nel modo più semplice (il modo semplice con cui descrivi di essere ... beh, più facile all'inizio, ma forse di più problematico quando si inizia a dover lanciare un'app mobile nel mix, quindi alcune utility lato server, un portale web pubblico separato accanto a un portale di amministrazione, ecc.)

Penso che per sistemi molto semplici, l'esperienza più snella che descrivi con lo stack MEAN potrebbe essere adatta, ma per applicazioni "serie", le cose dovrebbero essere più separate, il che tende a significare un po 'più di lavoro nel codice.

    
risposta data 13.04.2018 - 22:02
fonte

Leggi altre domande sui tag