Si tratta di un'architettura del sito valida?

Question

Si tratta di un'architettura del sito valida?

#1 da (3 voti)

1

Abbiamo un sito legacy che è stato scritto da tempo con MVC. È un MVC valido per la maggior parte tranne che per il livello di accesso ai dati. Il sito ha modelli, viste e controllori. Tuttavia, anziché utilizzare Entity Framework, utilizzano servizi Web che utilizzano ADO per eseguire stored procedure.

Ad esempio: diciamo che abbiamo una pagina per mostrare tutti gli utenti. Avremmo una visualizzazione users.cshtml , una classe UsersController.cs e una classe UserViewModel.cs .

Il metodo GetUsers() nel controller Utenti chiamerebbe un metodo di servizio Web chiamato WebService.GetUsers() . Questo servizio web chiamerebbe quindi una stored procedure chiamata dbo.GetUsers che conterrebbe qualcosa come select * from Users where Active = true .

Non ho mai visto questo tipo di approccio prima e mi chiedevo se fosse qualcosa che è stato inventato da chi ha realizzato questo sito, o se si tratta di uno stile architettonico del passato?

Vorrei anche sapere se questa è una buona architettura da usare.

c# architecture asp.net-mvc mvc

posta Bruno 13.11.2018 - 15:04

fonte

1 risposta

Leggi altre domande sui tag c# architecture asp.net-mvc mvc

Posso cambiare il proprietario della licenza di apache con il nome della nostra azienda? Python - Modo corretto per chiamare una funzione all'interno di una classe basata su un determinato argomento passato

score 3 · Accepted Answer

Certo, questo è perfettamente valido. Tutto dipende dal caso d'uso specifico.

Se ci sono più applicazioni che utilizzano il servizio web, allora ha senso dividere il livello di accesso ai dati in qualcosa che può raggiungere più applicazioni anziché implementarlo direttamente nel sito MVC. Per quanto riguarda la differenza tra l'utilizzo di EF e le stored procedure, questa è una preferenza. Il loro personale molto bene potrebbe aver avuto più esperienza nelle procedure SQL / memorizzate rispetto al framework delle entità, nel qual caso potrebbe avere senso utilizzare le stored procedure.

Personalmente, preferisco anche il framework di entità ma, architettonicamente, fa poca differenza quale strumento specifico usi per interrogare il tuo db SQL. Come nota a margine, ciò non significa che l'app non sia "MVC valido" solo perché non utilizza il framework di entità.

Se si tratta di una sola app che interroga il db per i dati, avrei preferito mantenere le cose semplici e implementare il livello dati nella stessa soluzione dell'attuale codice MVC, in quanto scelgo di mantenere le cose semplici quando posso. Se c'è la possibilità che in futuro ci siano app mobili, ecc. Che necessitano di estrarre i dati dal db, allora implementerei un servizio web che estrae i dati dal db attraverso l'entity framework ma, ancora una volta, lo strumento che stai usando per interrogare il db sta andando a variare molto da azienda a azienda - ci sono un sacco di ORM come framework di entità e ho visto un bel po 'di aziende che scrivono query SQL parametrizzate non elaborate nel loro livello di accesso ai dati.

Spero che questo aiuti.