Perché l'architettura MVC di .Net è così complicata rispetto a Rails?

Question

Nota: questo è lontano da un post su x è meglio di x. Piacere non andare lì.

Sono un ragazzo .Net e lo sono sempre stato, ho usato il framework MVC sin dalla prima versione 2 di Betas e da allora ogni versione. Negli ultimi mesi ho lavorato con Rails e ho una domanda sull'architettura che sembra differire enormemente tra le 2 piattaforme. (Basato sulla comunità e domande su siti come SO)

In .Net MVC siamo incoraggiati a separare le preoccupazioni, creare progetti separati per gestire Accesso ai dati, Business Logic e Vista, ci viene anche detto che dobbiamo convertire i nostri oggetti Data a ViewModels prima che colpiscano la vista ecc.

In Rails, le cose sembrano molto più semplici, abbiamo un oggetto che contiene Validation, DataAccess (tramite record attivo) e altre proprietà logiche e lo spediamo semplicemente alla View e visualizzalo.

Quindi, perché in un framework è accettabile questa metodologia e nell'altro è ritenuto sbagliato e tutti finiscono per scrivere più codice e creare più file.

Nota: Non sono un esperto Rails e davvero non sto cercando di confrontare, che è meglio di x, sto guardando l'architettura ad alto livello dei 2 quadri e di lavoro fuori quello che è accettabile in uno ma non l'altro .

Answer 1

Dipende dal tipo di applicazione che si sta sviluppando e da quanto si prevede che cresca.

Per applicazioni banali non è necessario complicare le cose con diversi modelli di visualizzazione e di dominio (ma è possibile utilizzare modelli ed entità di visualizzazione separati: http://blog.gauffin.org/2011/07/three-reasons-to-why-you-should-use-view-models/).

Per le applicazioni CRUD non è necessario avvolgere l'accesso ai dati in un'astrazione come il modello di repository.

Ma se ti aspetti di codificare qualcosa di diverso dalle applicazioni banali o CRUD, ti incoraggio a farlo. Modelli e principi ti aiutano nel giorno in cui vuoi iniziare a mantenere la tua applicazione. È possibile ottenere classi più piccole e ben definite e la logica di business viene creata in un unico posto anziché su tutta l'applicazione.

ho scritto un piccolo blog sul perché io uso astrazioni: http://blog.gauffin.org/2013/01/data-layer-the-right-way/

E perché l'incapsulamento è importante: http://blog.gauffin.org/2012/06/protect-your-data/