Caricamento pigro, astrazione DAL e BLL

1

Mi sto ponendo una domanda per codificare la strada giusta su un nuovo progetto nuovo.

Ho un database progettato e ho mappato le tabelle a classi POCO equivalenti utilizzando Entity Framework 6 Code First.

Poi, ho pensato "aspetta, se un giorno voglio passare da un EF a un altro Framework per qualsiasi motivo, o anche dire andiamo per la codifica diretta a causa di motivi di prestazioni, NON devo usare EF direttamente nella BLL. , EF NON è un DAL.

Ho iniziato a implementare un DAL che incapsula le chiamate EF. Quindi, ho implementato un BLL che consegue il DAL. Per alcune tabelle questo è come una mappatura diretta perché queste sono "tabelle dei parametri" (paesi, valute e così via). Ma per gli altri c'è una buona parte della logica di business, che va bene.

MA

Quindi si tratta di caricamento lento, allegando entità ecc.

Parliamo solo di Lazy Loading.

1) Uso del caricamento lento: quando sono così lontano nella BLL, non so più nulla degli interni DAL sottostanti. Consumo solo i miei oggetti e penso "hey, ogni proprietà arriverà proprio quando ne ho bisogno". Ma OMG! Sono fuori dal DAL, il Datacontext non c'è più, quindi niente può caricare più. Devo mantenere il contesto dei dati EF aperto per tutta la vita dell'applicazione? Ho letto che non è una buona pratica, ancora di più quando si tratta di un sito web di eBusiness che si mantiene vivo per sempre ...

2) Non utilizzare il caricamento pigro ma il carico impaziente. Bene, carico tutte le proprietà del mio oggetto, quindi ogni dato è disponibile per il mio BLL che consuma. Ahem, ho davvero bisogno, quando carico un cliente, di caricare tutti i suoi ordini, commenti, indirizzi, paesi e proprietà dei paesi, valute eccetera.etc.etc ... Questo sembra davvero eccessivo e non può vivere in un web applicazione ...

Ma il DAL NON dovrebbe sapere di cosa ha bisogno la BLL. Il DAL è qui per fornire l'accesso ai dati, quindi il BLL farà ciò di cui ha bisogno per caricare solo ciò di cui ha bisogno. Quindi dovrei fornire i metodi DAL per includere / non includere qualsiasi combinazione possibile di chiavi straniere? Sembra impossibile ... Devo aspettare che lo sviluppatore della BLL mi dica quali metodi ha bisogno per ciascuna delle sue esigenze? Sembra troppo accoppiato ... La BLL dovrebbe essere in grado di dire esattamente al DAL di cosa ha bisogno? Come farlo senza essere troppo accoppiati?

Sembra che Lazy Loading non sia applicabile in un'applicazione multistrato ...

    
posta Sierramike 03.04.2014 - 16:01
fonte

1 risposta

1

wait, if some day I want to switch from EF to another Framework for whatever reasons

No, non lo farai.

Ci sono due ragioni per cui quello che stai facendo è una cattiva idea. Primo. Cambiare l'ORM è estremamente raro e costruire tutte le tue astrazioni attorno a qualcosa del genere non è una buona idea. Le astrazioni dovrebbero innanzitutto essere costruite attorno a cose che cambiano spesso, quindi è possibile aggiungere quelle modifiche senza dover cambiare il codice. E nel livello di accesso ai dati, le cose che cambiano più spesso sono le entità, il modo in cui si interrogano tali entità e il modo in cui le persistono. Confronta questo con la possibilità estremamente sottile di sostituire completamente il tuo livello di accesso ai dati e passerai a cambiare molto codice per le cose che contano davvero e aggiungendo semplicemente il codice per cose che non contano. Che è opposto a come dovrebbe essere.

Il secondo è il fatto che gli ORM e l'accesso ai dati in generale sono complessi. A volte anche più complesso delle applicazioni che li usano. Inoltre, ci sono enormi differenze tra loro. Anche se potrebbero sembrare uguali, i dettagli li fanno comportare in modo diverso in molti casi d'angolo. Cercare di costruire astrazioni attorno a cose così complesse porterà inevitabilmente ad astrazioni non astratte e leaky. Quindi, anche se cambierai il quadro di persistenza, dovrai modificare molte cose nel livello aziendale o implementare il comportamento, quindi è lo stesso del framework precedente. Questo è in realtà ciò che stai incontrando. Stai cercando di astrarre qualcosa che è troppo complesso per essere correttamente estratto senza reimplementare il tutto.

Consiglio vivamente di ripensare il tuo design senza la mentalità "non puoi usare EF direttamente".

    
risposta data 03.04.2014 - 17:19
fonte

Leggi altre domande sui tag