Che tipo di astrazione / SoC dovrei usare qui?

2

Sto iniziando un nuovo progetto, e voglio seguire lo schema della separazione delle preoccupazioni, e ho letto sull'argomento, e ora sono in dubbio su come dovrei fare questo.

Ecco come pensavo di doverlo fare:

  • Application / Presentation Layer utilizza il Business Layer. Funziona con l'entità interfacce .
  • Il Business Layer utilizza lo strato di accesso ai dati (archivi, modelli / entità). Funziona con l'entità interfacce .
  • Il livello di accesso ai dati funziona con il database e utilizza una soluzione OR / M - la soluzione stessa potrebbe cambiare. Funziona con le implementazioni di entità, ma restituisce interfacce al livello aziendale.

Il livello aziendale otterrebbe un'implementazione di repository specifica iniettata. Il repository restituirebbe entità sotto forma di interfacce, quindi il livello aziendale non si preoccuperebbe di quale tipo di OR / M usiamo. Se decidessimo di passare dall'uso di LLBLGen a NHibernate, faremmo quanto segue:

  1. Codifica un nuovo set di classi di entità da utilizzare con NHibernate, perché le entità che abbiamo sono state generate da LLBLGen.
  2. Crea una nuova implementazione del repository che ha funzionato con le nuove entità + framework.
  3. Sposta l'implementazione del repository immessa nel livello aziendale con quello nuovo - il repository funziona con le interfacce, quindi il livello aziendale potrebbe rimanere invariato.

Il punto di interesse principale (pain) qui, oltre a dover modificare le entità generate per implementare le nostre interfacce modello, è che dobbiamo creare entità completamente nuove solo perché stiamo cambiando i quadri. Lo stesso sarebbe necessario se si sostituisse l'origine dati a qualcosa che l'OR / M non supportava.

Questo è il modo in cui l'ho fatto (perché hey, generare automaticamente le tue entità è come ottieni tutte le donne, giusto?) , ma poi mi sono imbattuto in questo articolo eccellente!

Ecco come penso che dovrei parlarne ora

  • Le entità sono memorizzate in uno spazio dei nomi / progetto separato - MyProject.Model
  • Application / Presentation Layer usa le entità in MyProject.Model per mostrare le cose. Utilizza Business Layer per recuperarli / salvarli.
  • Business Layer utilizza anche entità in MyProject.Model . Utilizza un repository da Data Access Layer che viene iniettato, a seconda di quale OR / M stiamo usando
  • Data Access Layer utilizza i framework OR / M con code-first , quindi possiamo lavorare con MyProject.Model indipendentemente da quale OR / M, o anche Data Source che stiamo utilizzando.

Pro e contro per la soluzione 1:

  • Pro: puoi utilizzare Database-First per generare automaticamente entità. Risparmio di tempo!
  • Pro: funziona con le interfacce per le entità
  • Con: Funziona con le interfacce per le entità (potrebbe trattarsi di troppa astrazione?)
  • Con: utilizzare un set di entità completamente nuovo per implementare un nuovo OR / M o origine dati. Devono essere modificati per conformarsi alle mie interfacce, è probabile che non possano a causa di come gestiscono le relazioni.

Pro e contro per la soluzione 2:

  • Pro: scrivi entità / modelli una sola volta, utilizza per qualsiasi implementazione DAL
  • Pro: non è necessario utilizzare le interfacce per le entità
  • Con / Pro: bloccato con codice prima per ogni OR / M. D'altra parte, ti dà la massima flessibilità su come vuoi che guardino.
  • Contro: alcuni framework (ad es. EF) sono semplicemente più facili da utilizzare quando si utilizza DB First.

Ho avuto più pro e contro, ma li ho persi di nuovo ..

Conclusione: quale soluzione sceglieresti e perché? O hai una soluzione ancora migliore?

Per favore non chiudere come "non una domanda", perché ho davvero bisogno di una risposta. Grazie.

    
posta Jeff 27.02.2013 - 18:24
fonte

1 risposta

2

L'opzione 2 è sicuramente migliore a mio avviso.

Il progetto dei modelli contiene tutte le entità e queste sono rappresentazioni pulite dei tuoi dati nell'applicazione.

Nel progetto del livello dati (che ha un riferimento al progetto dei tuoi modelli), dovrai implementare i repository astratti alle interfacce, che restituiscono le istanze delle tue entità. Il livello aziendale prende quindi una dipendenza da queste interfacce e quindi non ha alcun interesse nell'implementazione del repository o dell'ORM o del DB e non subisce alcun impatto se queste cambiano.

Avrai quindi una sorta di mappatura da fare, o quello che stai chiamando "Code First". Ovvero, la mappatura tra le entità pulite e le tabelle del database. Questo materiale di mappatura potrebbe anche vivere nel progetto del livello dati e essere scambiato per provider ORM / db.

Fare "Db First" o usare code gen per rendere le tue entità è un trucco accurato, ma nella mia esperienza di creare correttamente un DB, i modelli di applicazione correttamente e il mapping uno con l'altro correttamente, è molto più robusto, meno problematico, e non ci vuole molto più tempo.

Se la portabilità tra le origini dati e la pulizia delle entità delle applicazioni (ovvero, non ereditano da cose e non hanno un conteggio di attributi pazzeschi) sono cose che apprezzi - e ti piacciono la velocità e la facilità d'uso massicce pure - dai uno sguardo a Dapper . L'ho usato con successo contro SQL Server e Oracle per molto tempo e non posso consigliarlo abbastanza bene.

    
risposta data 27.02.2013 - 21:30
fonte