Dapper in relazione al design di livello n (BLL/DAL)

Question

Ho una domanda logica di base su Dapper.

Nel tentativo di fare le migliori pratiche di progettazione, sfocata la linea tra Dal e BLL? Molte raccomandazioni sono che il DAL non dovrebbe sapere nulla del BLL e che il DAL dovrebbe restituire un po 'di dati che il BLL dovrebbe convertire in un oggetto utile.

Vorrei ottenere l'opinione di alcuni esperti qui su dove si inserisce Dapper.

È un grande progetto e funziona molto bene, ma sembra strettamente accoppiato con il BLL. Non sono personalmente contrario all'approccio, ma mi chiedo se 1) c'era un modo migliore per incollare Dapper e BLL, o 2) se non è un vero problema poiché non intendiamo andare via da MS SQL.

Grazie.

EDIT: in risposta al commento di Marc:

Dapper è un ottimo prodotto e questo non è uno schiaffo in alcun modo ... cosa intendo per unito al BLL è che quando si esegue una query, restituirà comunemente una raccolta di un tipo specifico.

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

In questo caso la query restituirà una collezione di cane.

Se Dapper fosse distribuito nel livello Dal, dovrebbe avere un riferimento al livello BLL per conoscere i tipi di oggetti che tornerà.

Molte raccomandazioni sono che il DAL non dovrebbe mai sapere nulla sul BLL. Sto solo cercando di dimensionare le migliori pratiche per distribuire Dapper e mantenere una buona struttura di design a N.

So che è un po 'soggettivo, ma se è abbastanza buono da alimentare lo stack overflow, allora tutti dovete aver capito il modo migliore per distribuirlo in un ambiente ben progettato.

EDIT: notato che il thetype di "cane" non era mostrato nell'esempio della query a causa dei simboli HTML.

Modifica di nuovo in risposta ai commenti di Hogan: il cuore della mia domanda è più correlato all'idea che la linea di codice sopra sarebbe nel Dal. Per motivi di chiarezza, possiamo supporre che abbiamo una soluzione con DAL e BLL come progetti di classe separati. Ora, quando questa riga di codice va nel progetto DAL, il DAL dovrà fare riferimento al BLL per ottenere l'oggetto "cane". Questa dipendenza incrociata va bene? O solo il modo in cui il Dapper viene più comunemente usato? O è una cattiva pratica e non è il modo migliore per usare Dapper? So che molti "puristi" direbbero che il Dal non dovrebbe sapere nulla del BLL ... fare affidamento sull'oggetto "cane" nella linea sopra violenterebbe tale principio. Tuttavia, la linea sopra sembra essere l'uso di esempio più comune di Dapper.

Answer 1

Pensa a Dapper come a Rack Per i database, leggi: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper non ti costringe a utilizzare repository o qualsiasi modello particolare.

Non ti dirà dove mettere la tua logica aziendale. Se vuoi confondere la tua logica aziendale con il codice di accesso ai dati, così sia. Se non lo fai, non farlo. Dapper è agnostico. È una semplice tecnologia di accesso ai dati.

Answer 2

Penso che la tua domanda sia ignorare il contesto. Dal e BLL riguardano spesso il contesto. Non si tratta di una singola riga di codice (come suggerisce la tua domanda) ma sulla classe, lo spazio dei nomi e persino il percorso in un progetto al file di origine con il codice di riga. Molte volte questi problemi sono ignorati dai programmatori che vogliono scrivere un buon Dal e BLL e pensano che se usano lo strumento giusto il problema viene immediatamente risolto.

Lascia che ti dia alcuni esempi in base alla riga di codice che hai fornito sopra per chiarire il mio punto.

Se stavo leggendo il codice sorgente per un progetto e trovassi quella riga di codice in un file *.aspx.cs, sarei un po 'angosciato. Il progetto non è di livello n o modulare.

Al contrario, se stavo leggendo la fonte e trovassi quella riga di codice in un file chiamato dog.cs nella sotto-directory DAL di un progetto, sarebbe chiaro che questo codice è destinato ad agire come accesso ai dati per gli oggetti per cani nella soluzione.

Una conclusione simile può essere tratte se si trovava in una chiamata di directory BLL.

Non perderti capire il mio punto - Non sto suggerendo che devi avere un nome di directory Dal e BLL nella tua soluzione - sto solo dicendo che ciò che definisce questi elementi è esterno a una sezione di codice che esegue l'accesso ai dati . Tale linea di codice potrebbe contribuire a un sistema di livello N ben progettato o ne detrarre.

Answer 3

Usiamo Dapper nei nostri livelli di repository/dati come un modo semplice e semplice per mappare i nostri dati sui nostri oggetti senza scrivere codice extra per eseguire la mappatura. Dipende da te se si desidera utilizzare DTOS per trasferire i dati tra i livelli o mappa direttamente alle tue entità (BOS) che possono trovarsi in un livello comune separato.

Tutto dipende dal livello di astrazione che si desidera implementare. Se usi Entity Framework e fai le tue query LINQ direttamente nel livello aziendale, stai accoppiando strettamente la tua logica a EF e le tue entità vengono utilizzate anche nel livello di dati e business.