EF o Sql

venerdì 04 ottobre 2013 - 17.26
Tag Elenco Tags  C#  |  .NET 4.0  |  Visual Studio 2010  |  SQL Server 2008 R2

svipla Profilo | Senior Member

Ciao a tutti
devo realizzare un piccolo simile a booking per la gestione delle prenotazioni di alcuni hotel.
Devo decidere se utilizzare EF o il classico sql.
Ho utilizzato una sola volta EF, qualche mese fa, e con la tecnica Database First. Il problema più grande con EF, oltre al fatto che ad ogni modifica della struttura del database dovevo ricreare tutto il modello e perdevo i dati inseriti, era che non sapevo come realizzare interrogazioni complesse che coinvolgevano più tabelle.

Ho letto della tecnica Code Fist, ma anche quì rimane il problema, come creare interrogazioni complesse. Ho dato un'occhiata veloce a CF e non mi è chiaro come creare le classi che poi andranno a creare il db.

Dato che conosco poco e niente di EF, conviene utilizzarlo in un progetto bello grosso? E quale tecnica utilizzare?

Quali sono i vantaggi nell'utilizzare EF? E' possibile utilizzare il Code First con il framework 4.0?

Grazie mille

0v3rCl0ck Profilo | Guru


>Il problema più grande con EF, oltre al fatto
>che ad ogni modifica della struttura del database dovevo ricreare
>tutto il modello e perdevo i dati inseriti,

Ti consiglio di utilizzare EF 5, che gira anche su vs2010 in target framework 4 (quando aggiungi il riferimento a EF 5, vedrai che l'assembly ha versione 4.4, questo perchè la versione per il framework 4 è diversa da quella del 4.5, ma il prodotto è lo stesso EF 5).

Con EF 5, ma anche dal EF 4.3, hai la possibilità di sfruttare le migrazioni, da quelle manuale a quelle automatiche.

Ti lascio i link di qualche tutorial scritto per l'EF 4.3 (se avessi problemi con EF 5 o dovessi utilizzare per forza EF 4.3):

Migrazione Manuale: http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
Migrazione Automatica: http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx

link per l'ultima versione:

http://msdn.microsoft.com/en-us/data/jj591621(v=msdn.10).aspx
http://www.dotnetcurry.com/ShowArticle.aspx?ID=889

>era che non sapevo
>come realizzare interrogazioni complesse che coinvolgevano più
>tabelle.

se intendi le join ti allego il link msdn dove spiega come fare una join sfruttando linq-to-entity sulle entità dell'entity framework:

http://msdn.microsoft.com/en-us/library/bb896266.aspx

ovviamente queste query le puoi fare una volta che hai in mano un contesto EF, generato ad esempio sfruttando la tecnica code-first.

>
>Ho letto della tecnica Code Fist, ma anche quì rimane il problema,
>come creare interrogazioni complesse. Ho dato un'occhiata veloce
>a CF e non mi è chiaro come creare le classi che poi andranno
>a creare il db.

video che introduce l'utilizzo della tecnica del code first:

http://msdn.microsoft.com/en-us/data/jj193542

poi potresti provare a seguire questo esempio completo di un sito asp.net mvc scritto in EF code first e con POCO class:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application

>
>Dato che conosco poco e niente di EF, conviene utilizzarlo in
>un progetto bello grosso? E quale tecnica utilizzare?

il "conviene utilizzarlo in un progetto grosso", è difficile potertelo dire su due piedi, andrebbero analizzati tutti i fattori di interesse del tuo sistema, mole di dati salvati, frequenza di accesso ai dati, come sarà l'infrastruttura (cache / non cache), numero di client che accedono contemporaneamente al sistema, e sopratutto dove vengono poi fisicamente salvati i dati, su Sql Compact, MySQL, Oracle, SQLite, Sql Server, e se Sql Server che versione, express, standard o enterprise? come vedi ci sono tante cose che bisogna pensare prima di scegliere una tecnologia o scartarla, quello che ti posso dire è che ad oggi entity framework è un prodotto maturo e completo, fortemente seguito e supportato, di conseguenza una scelta più che valida se soddisfa le tue esigenze; ad ogni modo devi distinguere bene la scelta tra database engine (sql compact, sql server, mysql, ....) e data access framework (ado.net, ado.net entity framework, linq to sql, nhibernate, ibatis ...).

Riguardo alla tecnica da utilizzare, se database-first o code-first, preferirei il Code-First per la creazione di un progetto da zero, perchè ti darebbe la possibilità di avere tutto il controllo del prodotto complementa da codice, ma dall'altro punto di vista non utilizzerei entity framework su un sql server standard o enterprise, dove se ho licenze del genere, è del tutto probabile che avrei un sistema a consumo intesivo di risorse e troveri EF una modalità di accesso riduttivo sia in database-first che code-first, ma per il semplice fatto che non andresti ad utilizzare le stored procedure che sono un punto fisso per raggiungere la massima scalabilità da un sistema sql server.

>
>Quali sono i vantaggi nell'utilizzare EF?

uno dei vantaggi più evidenti, ma a volte il meno importante (dipende dal tipo di progetto), è di avere il supporto per l'accesso a database diversi, ma vale la pena dire che i provider supportati da Microsoft sono per i suoi database (Sql Compact http://msdn.microsoft.com/en-us/library/cc835494.aspx e Sql Server http://msdn.microsoft.com/en-us/library/bb896309.aspx) gli altri sono di terze parti (http://msdn.microsoft.com/en-us/data/dd363565.aspx).

altri vantaggi possono essere:
- la velocità di sviluppo del modello a db, e fisicamente poi delle tabelle vere e proprie con relative relazioni, scrivi il modello a codice, e viene creata la stessa struttura a db.
- il modello dei dominio dati è scritto solo in un punto (a codice) e riportato automaticamente a database, o viceversa
- sistema di query direttamente da codice con tutte le potenzialità di linq con linq-to-entities


>E' possibile utilizzare
>il Code First con il framework 4.0?

si certo, guarda i link sopra.

>
>Grazie mille

Spero di averti spianato un po' la strada,
Ciao!
-------------------------------------------------------
Michael Denny
Lead Software Developer & Solutions Architect
http://blogs.dotnethell.it/Regulator/

svipla Profilo | Senior Member

Grazie mille per la risposta
Il database che utilizzo è sql server. Il portale che sto pre realizzare gestirà la prenotazione online di alcuni hotel. Quindi penso che ci sarà un bel pò di traffico.
Ancora grazie

0v3rCl0ck Profilo | Guru

Non escluderei comunque a priori l'entity framework, potrebbe anche essere utilizzato in una realtà enterprise (http://pluralsight.com/training/Courses/TableOfContents/efarchitecture), l'importante è che la tua applicazione sia ben divisa in layer, in modo da separare il layer di accesso ai dati da tutto il resto, in questo modo potresti partire con entity framework, e nell'evoluzione dello sviluppo vedere se prendere altre strade rifattorizzando la parte di accesso ai dati, ma attenzione perchè non è tutto così semplice come dirlo, un refactor è pur sempre un refactor, io sono per un evoluzione costante dell'applicazione, dove non mi obbligo a scegliere per forza solo una opzione, a volte le migliori soluzioni sono quelle dove coesistono più tecnologie, ognuna scelta a pennello per l'esigenza del componente che sto disegnando. Ed è proprio la questione dei componenti la parte più importante dell'applicazione, se ti sforzi a pensare, oltre che al multi-layer (presentation, business e data layer), anche al multi-tier/N-tier (client, web, multi business logic, database tier: http://blogs.msdn.com/b/jmeier/archive/2008/09/06/layers-and-tiers.aspx), puoi pensare di suddividere la tua applicazione in componenti/servizi (SOA), dove ogni componente è un vero prodotto a tutti gli effetti, e potrebbe essere installato per i fatti suoi, e comunica con tutti gli altri prodotti, per un disegno più grande, che è il macro prodotto consegnato ai clienti, il tutto orchestrato da un ulteriore componente che si occupa solo di gestire i flussi e conosce tutti i componenti presenti nel sistema; ogni componente avrebbe il suo database, e in questo modo la scelta della tecnologia sarebbe più mirata e calzerebbe a pennello sulle necessità che il singolo micro-prodotto ha, di conseguenza più facile scegliere anche i framework da utilizzare, ecc... perchè del resto un cambiamento di rotta, e in generale ogni refactor diventerebbe meno critico, in quanto limitato ad una sola area ben isolata del macro-prodotto, che sarebbe ben testabile, e non investirebbe come un treno ogni sua parte:

http://mikehadlow.blogspot.it/2011/09/some-thoughts-on-service-oriented.html
http://mikehadlow.blogspot.co.uk/2011/09/some-thoughts-on-service-oriented_27.html

http://www.hanselman.com/blog/AReminderOnThreeMultiTierLayerArchitectureDesignBroughtToYouByMyLateNightFrustrations.aspx





-------------------------------------------------------
Michael Denny
Lead Software Developer & Solutions Architect
http://blogs.dotnethell.it/Regulator/

svipla Profilo | Senior Member

Grazie mille per l'aiuto
Un'ultima cortesia: dove posso trovare un piccolo esempio di utilizzo di Code-First? In giro trovo solo piccoli pezzi di codice, ma io vorrei vedere un esempio completo per capire come organizzare le classi, se devo definire le funzioni nelle classi che uso per creare il db o se devo creare altre classi dove definisco gli stessi attributi.
Dove posso trovare un esempio di progetto realizzato a componenti (SOA)? Ho sempre voluto realizzare un'applicazione in questo modo.
Grazie mille

0v3rCl0ck Profilo | Guru

>Grazie mille per l'aiuto
>Un'ultima cortesia: dove posso trovare un piccolo esempio di
>utilizzo di Code-First? In giro trovo solo piccoli pezzi di codice,
>ma io vorrei vedere un esempio completo per capire come organizzare
>le classi, se devo definire le funzioni nelle classi che uso
>per creare il db o se devo creare altre classi dove definisco
>gli stessi attributi.

l'esempio su www.asp.net lo trovo molto completo e semplice:

http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application

ad un certo punto c'è la sezione dove inizia a creare il modello, che sarà poi la base che viene utilizzata da una classe speciale DbContext, che poi è quella che inizializza e crea l'effettivo db dato un modello a classi; ad ogni modo ti consiglio proprio di seguire tutta quella guida dall'inizio alla fine, e secondo me ti aiuta proprio bene a capire come funziona:

codice preso direttamente dal link:

classe per il modello che definisce uno studente

using System; using System.Collections.Generic; namespace ContosoUniversity.Models { public class Student { public int StudentID { get; set; } public string LastName { get; set; } public string FirstMidName { get; set; } public DateTime EnrollmentDate { get; set; } public virtual ICollection<Enrollment> Enrollments { get; set; } } }

classe per la definizione, l'inizializzazione e la creazione del database (DbContext)

using ContosoUniversity.Models; using System.Data.Entity; using System.Data.Entity.ModelConfiguration.Conventions; namespace ContosoUniversity.DAL { public class SchoolContext : DbContext { public DbSet<Student> Students { get; set; } public DbSet<Enrollment> Enrollments { get; set; } public DbSet<Course> Courses { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Conventions.Remove<PluralizingTableNameConvention>(); } } }

>Dove posso trovare un esempio di progetto realizzato a componenti
>(SOA)? Ho sempre voluto realizzare un'applicazione in questo
>modo.

è difficile trovare esempi completi, ma sopratutto un solo esempio, perchè ogni realtà SOA potrebbe avere sviluppi diversi una dall'altra, e garantire tutti i principi fondamentali:

http://www.soainstitute.org/resources/articles/four-tenets-service-orientation

se dovessi riassumere il termine SOA, la descriverei come un termine generico per definire un architettura loosely-coupled (disaccoppiata) che sia in grado di soddisfare le esigenze di business dell'azienda, quindi capisci bene che l'implementazione può variare molto, potrebbe ad esempio essere implementata con un serie di servizi WCF connessi tra loro (anche se non basta avere dei servizi per definirsi SOA, ma i componenti non devono condividere logiche di business, ma essere orchestrate da un altro attore), ma in alcuni casi, specialmente nell'enterprise, si preferisce un sistema di messaggistica a code gestite real-time, affidabile, scalabile e ad alta disponibilità, (msmq, rabbitmq, zeromq, ...) che possa ancora meglio disaccoppiare i componenti, garantendo alte prestazioni, nonostante l'aggiunta di un certo overhead computazionale.

al momento un progetto completo SOA potrebbe essere quello distribuito della Microsoft, che è attuale e completo in ogni sua parte:

http://msdn.microsoft.com/en-us/vstudio/bb499684.aspx

i link di mike hadlow, che ti ho passato nel post precedente, spiegano come ha creato un applicazione enterprise in visione SOA sapendo di dovere scalare per decine di grossi clienti un flusso di richieste importante, e con logiche di business personalizzate per ogni cliente, ma di cui voleva potere anche estrarre le logiche base ed avere a tutti gli effetti un core product, in modo che le personalizzazioni per lo specifico cliente sia codice scritto una sola volta per il cliente stesso, ma che non sia codice dupplicato, il codice in comune tra più clienti, diventa parte del prodotto principale (core product), ed è isolato nei core components attraverso servizi che comunicano sfruttando un service bus implementato con RabbitMQ (come sistema di messaggistica) + EasyNetQ (come framework sopra alle API base di rabbitMq su protocollo AMQP) scambiandosi messaggi via rete in HTTP:

http://mikehadlow.blogspot.it/2011/09/some-thoughts-on-service-oriented.html
http://mikehadlow.blogspot.co.uk/2011/09/some-thoughts-on-service-oriented_27.html


-------------------------------------------------------
Michael Denny
Lead Software Developer & Solutions Architect
http://blogs.dotnethell.it/Regulator/

svipla Profilo | Senior Member

Grazie mille Prof
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5