Strati .NET e database

Question

Quando ho lavorato per la prima volta alla programmazione, stavamo cercando di spostarci da DataReaders e la tradizionale API ADO.NET verso Object Relational Mapping (ORM).

Per fare ciò, abbiamo generato un DataContext del nostro DB tramite sqlmetal. C'era allora un sottile strato di dati che rendeva il DataContextprivate e qualsiasi codice che necessitava di accedere al database avrebbe dovuto usare un metodo public in questo sottile strato di dati. Questi metodi erano fondamentalmente procedure memorizzate; avrebbero eseguito query sul database tramite LINQ a SQL.

È un approccio comune oggi? Voglio dire, tutti quelli che utilizzano il framework .NET 3.5 eseguono davvero sqlmetal nel loro processo di compilazione o cosa? Sembrava quasi un hack in quel momento.

Fondamentalmente, mi piacerebbe sapere se LINQ su SQL e sqlmetal è cosa aspettarsi se vado a scrivere un DAL oggi in un negozio .NET 3.5 che non utilizza una terza parte, open- fonte ORM.

Answer 1

Il tuo approccio è buono. Attualmente utilizzo i servizi di Astroria (ADO.NET Data Services). C'è stata una bella introduzione su MSDN Magazine.

Mi piace anche il nuovo PLINQO (richiede però CodeSmith Tools). Questo è molto lucido a mio parere.

Quando si dispone di un DAL (livello di servizio), utilizzo semplicemente questo servizio dall'applicazione client (Silverlight o ASP.NET MVC).

Answer 2

Penso che dipenda dal tuo utilizzo ma direi con un livello di dati così sottile come hai spiegato che sarebbe il tuo DAL. La maggior parte dei progetti costruirà un altro livello sopra quello principalmente per modificare/creare la logica e forse qualche logica di cucitura per ottenere.

Per la maggior parte dei miei progetti l'ho progettato in questo modo.

Repository detiene l'istanza di DataContext ed espone alcuni add base/eliminare metodi
ProductRepository: Repository espone domande di carattere generale (IQueryable)
StoreService utilizza un'istanza di repository diversi, come ProductRepository, SalesRepository e gestisce tutta la logica per la creazione di qualcosa di simile un prodotto.

Quindi qualcosa di simile ...

StoreService.CreateProduct(/* properites */) 

Ciò restituirebbe una sorta di classe di risultato.

Answer 3

È ancora consigliabile utilizzare una sorta di livello di accesso ai dati. Se questo è il miglior risultato raggiunto con un ORM è un problema molto dibattuto. C'è una fazione che generalmente sostiene che gli ORM sono la strada da percorrere. Un'altra fazione sostiene che le stored procedure e il database centrico sono la via migliore.

Inoltre, questo potrebbe non essere esattamente il manifesto che volevi dire, ma è simile (e anche quella nel mio cubicolo)

http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf

Answer 4

Questo molto sito utilizza LINQ to SQL, in modo da prendere che, come si volere.

Ufficialmente, Microsoft supporta Entity Framework su LINQ to SQL in termini di nuovo sviluppo. Tuttavia, c'è un gruppo vocale di persone che pensano che sia EF is the wrong way to go. LINQ to SQL sarà ancora in giro per qualche tempo, ed è un ORM molto dignitoso, anche se un po 'limitante in termini di quale backend DB puoi usare.

Consiglierei LINQ come un ottimo punto di partenza per il tuo ORM. Se hai bisogno di più, guarda in EF e/o NHibernate.

Answer 5

"È un approccio comune oggi? Voglio dire, tutti coloro che utilizzano il framework .NET 3.5 eseguono davvero sqlmetal nel loro processo di compilazione o cosa?"

Le persone che conosco che utilizzano 3.5 Framework (e questo è quasi tutti) - la stragrande maggioranza - utilizzano ancora NHibernate. La versione 2.0 è un OR/M molto carino. Ho iniziato a usarlo su un progetto recente e ha ridotto significativamente il mio codice di accesso ai dati, al punto che in realtà non voglio usare altro in futuro. E l'API Fluent NHibernate sta facendo progressi per le persone a cui non piace la mappatura XML.

Answer 6

Il livello dati migliore è quello semplice e semplice e consente di completare il lavoro senza alcun suono. Ho usato le tecnologie che hai menzionato e scritto su di esse qui: The Only Pattern for Data Access is - There Are No Patterns for Data Access