DAL Future Proof

Question

Siamo all'inizio di un progetto di sviluppo molto lungo con diversi sottoprogetti. Fondamentalmente, ogni sottoprogetto richiederà diversi mesi per svilupparsi. Il codice stesso verrà suddiviso in diversi progetti C#, ma il database fisico sarà condiviso da tutti i progetti.

Il problema è la manutenibilità. Se aggiungiamo una colonna a una tabella o dividiamo una tabella in due tabelle più piccole, dovremo tornare indietro e modificare il nostro C# DAL per supportare queste modifiche. Questo non è accettabile, poiché adatteremo costantemente il DB alle esigenze dell'azienda nel suo insieme e non solo alle esigenze di un singolo programma. Cambiare costantemente il vecchio codice sarebbe un compito infinito.

Le nostre persone di DB hanno suggerito una vista diversa. Facciamo tutto il nostro CRUD attraverso stored procedure e usiamo Linq su più tabelle per eseguire le nostre istruzioni SELECT. Quindi, se ristrutturiamo il DB tra diversi anni, possiamo semplicemente fornire gli stessi proc e viste memorizzati e non dover modificare il nostro vecchio codice.

La domanda che abbiamo è che cosa deve essere utilizzato ORM per qualcosa di simile? EF sembra un po 'eccessivo (forse non lo è). Qualcosa come SubSonic con il suo template T4 permetterebbe un DAL più semplice (e forse più veloce)?

O forse qualcuno ha un'idea su come rendere questo intero processo meno doloroso? Preferiamo non aggiungere un altro livello alla nostra applicazione, ma nemmeno vogliamo tornare indietro e modificare il codice ogni volta che eseguiamo una modifica del database.

Modifica 1: Così, quando ho detto "Non voglio aggiungere più livelli". Questo è principalmente perché abbiamo già diversi livelli. Abbiamo viste Silverlight, view-models, oggetti BLL (tramite CSLA), quindi abbiamo il DAL e infine le tabelle SQL themseleves.

Answer 1

C# DAL... not just the needs of a single program.L'intero punto di un C# DAL come assembly separato è che può essere riutilizzato su qualsiasi tipo di applicazione .NET. Il problema principale che si verificherà è che se il database cambia, quindi il DAL deve cambiare (una volta), quindi tutte le applicazioni che dipendono dal DAL devono essere ridistribuite con il nuovo DAL. Hai anche il problema che il DAL non può essere utilizzato da applicazioni non.NET.

Ok, quindi come si può centralizzare il DAL in modo che non sia necessario ridistribuirlo per ogni applicazione? Pensa a SOA. È possibile creare un servizio WCF per contenere il DAL (e probabilmente BLL). Tutte le applicazioni (se si utilizzano i servizi Web, anche quelli che non sono .NET) possono utilizzare questo servizio. Quando il database cambia, si aggiorna il servizio WCF e si esegue il deployment una volta. Assicurati solo di non apportare modifiche di rottura! Creare un MyMethod2 se è necessario aggiungere/modificare funzionalità.

Nota: Quando si sente a più livelli, di solito riferisce a tre livelli, dove ogni livello è un software separato e di solito su server separati: presentazione (UI), applicazione (il vostro BLL/DAL), dati (il tuo database SQL ). C'è merito per questa architettura.

We'd rather not add another layer to our application. Ok, quindi a tre livelli potrebbe non essere l'approccio migliore nel tuo caso.

neither do we want to go back and modify code everytime we make a db change Quindi ciò che le persone del DBA hanno suggerito è l'unico modo.

Tuttavia, si consideri questo: sta cambiando una stored procedure allo stesso modo della modifica del codice? Fondamentalmente è la stessa cosa. Le stored procedure SQL spesso non sono controllate dalla versione o testate, ma dovrebbero esserlo. SQL non ha la ricchezza di un linguaggio come .NET. WCF può essere facilmente ridimensionato in una web farm. Una volta preso in considerazione questi e altri motivi, potrebbe valere la pena adottare l'approccio three-tier/SOA.

Dipende davvero dalle dimensioni del progetto, dalle competenze del personale, dalla crescita futura, ecc. E questo è qualcosa che solo tu puoi determinare.

Answer 2

ho iniziato ad usare BLToolkit sulla base di informazioni prestazioni http://ormeter.net/

È possibile definire il proprio modello nei file di classe semplice, aggiungere alcuni metodi con attributi applicati e presto si dispone di un DAL. Dividere una tabella in due ed è possibile mantenere il file di classe originale durante la creazione di quelli nuovi per supportare le tabelle divise. Basta fare in modo si crea un progetto di test che colpisce ogni metodo per assicurarsi che tutto il lavoro con ogni release

Classe

public class DirectoryListing 
    { 
     [PrimaryKey, Identity] 
     public Int64 Id { get; set; } 
     public Int64? OldId { get; set; } 
     public Int32 CategoryId { get; set; } 
     [Nullable] 
     public String CompanyName { get; set; } 
} 

Generale selezionare o valori di tabella funzioni:

[SqlQuery("SELECT * FROM Ajax_CategorySearch(@SearchString, @ResultCount)")] 
[Cache(MaxCacheTime = 10, IsWeak = false)] 
public abstract List<String> AjaxCategorySearch(String @SearchString, Int32 @ResultCount = 10); 

O, per usare un processo memorizzato:

[ActionName("SelectById")] 
public abstract Model.DirectoryListing SelectById(Int64 @Id); 

Ciò chiamerà la directory SPListing_SelectBy Id

Oh, e fare le cose in un modo più classico è troppo facile

using (BIFDbManager db = new BIFDbManager()) 
    { 
     var output = db.SetCommand(
      "SQL GOES HERE", 
      db.Parameter("@Id", 1)) 
      .ExecuteList<DAL.Model.DirectoryListing>(); 

     totalrecords = output.Count(); 

     return output; 
    } 

L'ultimo pezzo del puzzle è il responsabile db, che consente anche il supporto LINQ.

public class BIFDbManager : DbManager 
{ 
    public BIFDbManager() : base("Connection string name") { } 

    public Table<DirectoryListing> DirectoryListings { get { return GetTable<DirectoryListing>(); } } 
} 

Answer 3

Quanto tempo si può lavorare senza il database? Se è un problema, presentalo in ritardo. E sì, probabilmente significa che aggiungi un livello.