MVC + 3 livelli; dove entrano in gioco i ViewModels?

Question

MVC + 3 livelli; dove entrano in gioco i ViewModels?

#1 da (18 voti)

11

Sto progettando un'applicazione a 3 livelli utilizzando ASP.NET MVC 4. Ho usato le seguenti risorse come riferimento.

Ho il seguente design fino ad ora.

Presentation Layer (PL) (progetto MVC principale, dove M di MVC è stato spostato su Data Access Layer):

MyProjectName.Main
    Views/
    Controllers/
    ...

Business Logic Layer (BLL) :

MyProjectName.BLL
    ViewModels/
    ProjectServices/
    ...

Data Access Layer (DAL) :

MyProjectName.DAL
    Models/
    Repositories.EF/
    Repositories.Dapper/
    ...

Ora, i riferimenti PL BLL e BLL riferimenti DAL. In questo modo il livello inferiore non dipende da quello sopra di esso.

In questo design PL invoca un servizio della BLL. PL può passare un modello di vista a BLL e BLL può passare a un modello di vista su PL.

Inoltre, BLL richiama il livello DAL e il livello DAL può restituire un modello a BLL. A sua volta, BLL può creare un modello di visualizzazione e restituirlo a PL.

Fino ad ora questo schema funzionava per me. Tuttavia, mi sono imbattuto in un problema in cui alcuni dei miei ViewModel richiedono join su diverse entità. Nel semplice approccio MVC, nel controller ho usato una query LINQ per fare join s e poi select new MyViewModel(){ ... } . Ma ora, nel DAL, non ho accesso a dove sono definiti ViewModels (nella BLL).

Questo significa che non posso fare join in DAL e restituirlo a BLL. Sembra che devo fare query separate in DAL (invece di join in una query) e BLL dovrebbe quindi utilizzare il risultato di queste per creare un ViewModel. Questo è molto sconveniente, ma non penso che dovrei esporre DAL a ViewModels.

Qualche idea su come posso risolvere questo dilemma? Grazie.

c# design-patterns asp.net-mvc

posta erdinger 08.11.2013 - 04:58

fonte

1 risposta

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

Quando utilizzare i generici nella progettazione dell'interfaccia Che cos'è la delega e perché è importante nella programmazione iOS?

score 18 · Accepted Answer

main MVC project, where M of MVC was moved to Data Access Layer

Idee sbagliate comuni. Il M di MVC non ha nulla a che fare con i dati, nonostante i molti esempi e tutorial che lo rivendicano.

M è il tuo ViewModel e dovrebbe risiedere nel tuo progetto MVC. I ViewModels che hai nel tuo BLL devono essere chiamati DataContracts o BusinessModels.

Nel tuo controller hai qualcosa di simile a questo:

Get(id):
    dataContract = _service.Get(id);
    viewModel = Map(dataContract);
    return viewModel

Nel tuo servizio, qualcosa del genere:

Get(id):
    dataModel = _dataAccess.Get(id);
    dataContract = Map(dataModel);
    return dataContract;

E nel DataAccess, esegui i giusti join in base all'oggetto richiesto. Ovviamente, sei libero di aggiungere metodi personalizzati a DataAccess quando richiesto, in modo che il tuo servizio possa chiamare tali metodi:

GetWithBars():
    dataModels = _repository.Query("select from foos join bars");
    return dataModels;