Qual è la differenza tra DAL, DTO e DAO in uno stile di architettura a 3 livelli incluso con MVC

Question

Recentemente stavo imparando su ORM (Object Relational Mapping) e lo stile di architettura a 3 livelli (presentazione, business e persistenza dati). Se ho capito bene, posso separare il livello di persistenza dei dati in livello DTO e DAO.

Mi piacerebbe capire come le seguenti parti lavorano insieme in un livello di persistenza dei dati.

• DAL (Data Access Layer)
• DTO (Data Transfer Object)
• DAO (Data Access Object)

In una cima che ho imparato che

Nelle applicazioni di grandi dimensioni MVC è il livello di presentazione solo di un'architettura di livello N.

mi sono davvero confuso, come può essere ancora possibile per esempio in un architettura in stile 3 livelli in cui l'MVC è solo un livello di presentazione e il DTO, DAO, DAL è solo una parte dei dati di persistenza tier . Sono totalmente perso.

Sarei felice se qualcuno mi dica la verità su come funziona insieme.

Si prega di non chiudere questa domanda perché le molte espressioni diverse, l'ho visto ovunque queste cose sono legate l'una all'altra fondamentalmente in applicazioni grandi e non riesco a immaginare come funziona.

Apprezzo qualsiasi risposta!

Answer 1

Iniziamo con scopo di ciascuna: -

DTO

di trasferimento dati oggetti. Questi sono generalmente utilizzati per trasferire i dati da controller a client (JS). Termine viene utilizzato anche per POCO/POJO di pochi che in realtà detengono i dati recuperati dal Database.

DAO

Data Access Object è uno dei modelli di progettazione utilizzati per implementare DAL. Questo costruisce ed esegue query sul database e mappa il risultato in POCO/POJO usando vari altri pattern, tra cui "Query Object", "Data Mapper", ecc. Il layer DAO potrebbe essere ulteriormente esteso utilizzando il pattern "Repository".

DAL

strato di accesso ai dati astrae le attività di database utilizzando DAO/Repository/POCO ecc ORM aiutano a costruire la vostra DAL ma potrebbe essere attuato senza l'utilizzo di loro anche.

MVC

Model View Control è un modello che viene utilizzato per separare vista (presentazione) dalla logica di business. Per MVC, non importa se DAL è implementato o meno.Se DAL non è implementato, la logica del database va semplicemente nel tuo modello che non è un buon approccio.

Nelle applicazioni di grandi dimensioni MVC è il livello di presentazione solo di un'architettura N-tier .

I modelli consumano la maggior parte della logica aziendale come indicato sopra. Nell'applicazione N-tier, se la logica aziendale è completamente separata ai fini della riutilizzabilità tra applicazioni/piattaforme, i modelli in MVC sono chiamati modelli anemici. Se la BI non deve essere riutilizzata a quella scala nell'applicazione, è possibile utilizzare Model per tenerla. Nessuna confusione, giusto?

Sarei felice se qualcuno mi dica la verità su come funziona insieme .

Tutti gli schemi MV * definiscono solo l'idea/concetto; non definiscono l'implementazione. I pattern MV * si concentrano principalmente sulla separazione della vista dalla BI. Concentrati su questo.

Consultare la risposta this per dettagli sui diversi oggetti contenenti dati.