blogs.ASPItalia.com

Cosa penso delle prossime novità del designer Entity Framework

Stefano Mostarda — Mon, 18 Oct 2010 08:01:00 GMT

Torno finalmente a bloggare dopo mesi di inattivit� dovuti ad un periodo a dir poco folle prima e dopo le ferie... prometto che d'ora in poi torner� ad essere pi� presente :).

Il Team di Entity Framework ha pubblicato questo post dove spiega i prossimi sviluppi per il designer. La magigor parte di queste caratteristiche riguarda la leggibilit� del modello soprattutto in presenza di molte entit�.

Lla versione del designer inclusa in VS2010 mi piace molto (ovviamente con tutte le limitazioni del caso) perch� � abbastanza estensibile (ne parliamo anche in un capitolo del nostro libro). Tuttavia, da quello che vedo, non c'� una cosa che mi sarebbe piaciuta moltissimo ovvero la possibilit� di rendere il designer completo almeno dal punto di vista della generazione. Quello che mi sarebbe piaciuto da matti (anche se a detta del team sonostato l'unico al mondo a chiederlo) � avere la possibilit� di fare 2 semplicissime cose:

Poter importare il database nell'EDM senza per� generare nulla nel model (e questo volendo possiamo farlo estendendo il designer)
Poter trascinare le entity dalla finestra della soluzione all'interno del designer.

Grazie a questi 2 semplici espedienti potrei, per esempio, prendere le mie classi esistenti e trascinarle nel modello, importare il database nell'EDM senza che questo abbia impatto sul modello ed infine fare il mapping. Una volta fatto questo per generare il codice uso o il template POCO (facendo generare solo il codice per il context) o uso un mio template per generare il codice per la Code-First experience. Questo per� � indifferente al designer che comunque rimane aperto ad ogni tipo di possibilit� offerta da Entity Framework.

Un'altra cosa che potrei fare � trascinare le classi nel designer e farmi generare lo script per il database al volo (ammesso che ci diano finalmente la possibilit� di scegliere quale strategia di persistenza utilizzare per l'ereditariet� in ogni singolo caso).

Insomma, con questi 2 trucchi sarei libero di prendere ogni strada. Per questo motivo, anche se da un lato la direzione presa per il designer mi sembra buona, ci sono altre cose che si possono migliorare. Vediamo se magari renderanno il designer ancora pi� estendibile cos� che possa farmi da solo queste cose :).

Stay tuned...

Tags: Entity Framework, ORM

Continua a leggere Cosa penso delle prossime novità del designer Entity Framework.

Entity Framework e l'estendibilità del designer

Stefano Mostarda — Wed, 03 Feb 2010 07:37:37 GMT

E' un p� che manco dal blog, ma spero che d'ora in poi riuscir� a fare post con pi� continuit� visto l'avvicnarsi della RTM di Visual Studio che per me in particolar modo significa la RTM di Entity Framework 4.0.

Durante la stesura del capitolo 11 del libro ho parlato di come customizzare Entity Framework per generare codice diverso da quello di default tramite i template T4, di come customizzare la generazione del database attraverso Workflow e di nuovo i template ed infine come customizzare il designer.

Quest'ultima parte � di particolare interesse. Io faccio un uso molto estensivo delle structured annotations nell'edm. Modificare l'edmx a mano non � certo un problema, ma se posso farlo da designer perch� no? Ecco, il team di Entity Framework ha sfruttato MEF per permettere l'estensione del designer proprio per venire incontro ad esigenze di questo tipo.

Faccio un esempio. Quando devo persistere una entity che ha come propriet� chiave un Int32, se il valore � zero la marco come nuova tramite AddObject, altrimenti come aggiornata tramite Attach + ChangeObjectState. (NHibernate ha una feature del genere gi� integrata). Posso fare una cosa del genere scriveno una if secca nel codice ma diciamoci la verit�. It Sucks. In alternativa, posso estendere l'EDM aggiungendo alla propriet� chiave il valore da utilizzare come discriminatore per decidere il tipo di operazione (0 per la add, il resto per la attach). Poi posso costruire un Extension Method che prende l'entit� da persistere, tramite i metadati verifica la propriet� chiave e verifica quale valore usare per la insert. In questo modo nel codice noi invochiamo l'extension method e poi se la vede lui per tutto il resto.

Tutto bello , ma modificare l'EDM non � semplice a primo acchitto soprattutto per uno sviluppatore alle prime armi. E allora, perch� non fare in modo che quando si seleziona nel designer la propriet� chiave di una entit� non si aggiunga una propriet� nella Properties Window che prenda il valore in base al quale fare la AddObject e che poi lo persista automaticamente nell'EDM?

Grazie all'estendibilit� del designer possiamo raggiungere il nostro scopo con una classe con circa 20 righe di codice. Basta una classe che implementi un'interfaccia che ha un solo metodo (che potrebbe essere di una riga) il quale ritorna un'istanza di un'altra classe che contiene la propriet� da aggiungere al designer. Il getter ed il setter di questa propriet� lavorano con l'EDM per recuperarne e modificarne i dati direttamente in XML quindi con LINQ to XML il tutto � estremamente banale.

Alla fine della giostra grazie alla customizzazione del designer abbiamo un notevole incremento della produttivit� mentre disegnamo il nostro modello, ed una semplificazione del codice per via dell'Extension Method che decide da solo come persistere una entit�. Quest'argomento � trattato nel mio libro su Entity Framework quindi direi che � un buon motivo per non lasciarselo sfuggire :).

Stay Tuned...

Tags: .NET Framework, .NET Framework 4.0, Entity Framework, ORM

Continua a leggere Entity Framework e l'estendibilità del designer.

Entity Framework 4.0 finalmente ha un buon designer

Stefano Mostarda — Fri, 30 Oct 2009 18:57:31 GMT

Il designer di Entity Framework 4.0 � "abbastanza" maturo. Tra le cose che non mi piacciono ci sono:

Impossibilit� di ereditare da una classe che non sia sul designer(molto comodo quando si ha un proprio assembly con una classe da cui vogliamo far ereditare tutte quelle del modello)
Impossibilit� di avere una classe base che sia mappata su 2 tabelle diverse (tabelle clienti e fornitori) (classe base Azienda e classi specializzate fornitori e clienti)
Impossibilit� ditrascinare una classe esistente e vederla disegnata (utile quando gi� abbiamo un modello perch� generato con un tool o perch� stiamo migrando un'applicazione esistente)
impossibilit� di modificare visualmente il SSDL.
Impossibilit� di vedere i Complex Type al pari delle entity e di vedere le complex properties espanse.
Impossibilit� di importare il database senza toccare il modello.

Queste cose sono molto fastidiose. Io odio particolarmente i punti dal 3 al 6.

Tuttavia, l'insieme delle migliorie introdotte dalla versione 1.0 sono stratosferiche. Quella che era una blackbox � ora un'autentica perla di estensibilit�. Certo, non che estendere il designer sia semplice, ma non � nemmeno cos� complesso. Cominciamo dalla generazione del codice. Ora tutto avviene tramite un file di templating cos� possiamo personalizzare loutput come meglio vogliamo. La generazione del database pu� essere customizzata con un workflow per quanto riguarda il modo di generare le tabelle, mentre per il codice vero e proprio del database basta usare un altro file di templating. Mettendo i file di templating nel posto giusto (in alcune directory di visual studio per la precisione) possiamo decidere tutto direttamente dalle propriet� del designer. Questa � una cosa che adoro.

Entity Framework non � ancora un al livello di NHibernate, ma parliamoci chiaro, la rincorsa ed un eventuale sorpasso passano anche per un designer ben fatto e qui direi che siamo decisamente sulla buona strada.

Stay Tuned...

Tags: Entity Framework, ORM

Continua a leggere Entity Framework 4.0 finalmente ha un buon designer.

.NET Framework 4.0 Beta 2: Entity framework 4.0

Stefano Mostarda — Tue, 20 Oct 2009 09:18:39 GMT

Ormai anche i sassi sanno che oggi � uscita la Beta 2 di Visual Studio 2010 e del .NET Framework 4.0. Visto che i compari hanno gi� fatto dei post sulle varie novit� introdotte con questa beta mi do da fare e vi parlo delle novit� di Entity Framework 4.0.

La novit� sicuramente pi� attesa sono le foreign key. Adesso nelle relazioni master detail, la entity di detail avr� non solo una propriet� del tipo master, ma anche la foreign key verso quella entit�. Per esempio, un dettaglio, avr� una propriet� ordine ed una ordineid. Dal punto di vista del design, questa � una bruttura clamorosa, ma risolve moltissimi problemi che le associazioni fatte senza foreign key avevano. Comunque, rendendo le foreign key protected, possiamo evitare di esporle all'esterno e ottenerne comunque i benefici.

Un'altra novit� importante � nel designer. Finalmente quando importiamo una SP dal database il designer ne legge il risultato e genera automaticamente un complex type o ci permette di utilizzzarne uno esistente. hip hip hurr� :)

Finalmente il designer non obbliga a mantenere le navigation properties quando c'� un'associazione. Questo vuol dire che in un'associazione cliente-ordini, possiamo avere la navigation property Cliente nell'ordine e non mettere la propriet� Ordini nel cliente. Sicuramente la comprensibilit� di un modello ne guadagna.

Una cosa che non mi piace � invece il lazy loading by default. Nel codice che viene generato, il costruttore abilita il lazy loading. Personalmente ritengo il lazy loading una delle cose pi� inutili della storia a parte in rarissimi casi che fino ad ora conto sulle dita di una mano.

Il designer � stato innoltre esteso per supportre meglio altri tipi di database e per permettere di pluggare la propria logica di generazione del database in scenari di database-first.

Infine ci sono molte altre migliorie come l'enditydatasource control per asp.net che ora supporta POCO ed i query extenders, un miglior support per l'n-tier e una riorganizzazione delle classi SqlFunction e EntityFunction utilizzate da LINQ to Entities.

Insomma le novit� ci sono e sono succulente. Io, Marco e Daniele abbiamo quasi finito di aggiornare il libro alla Beta 2 e il tutto sta per andare in MEAP quindi direi che � una buona lettura per tutti ;).

Stay Tuned...

Tags: .NET Framework 4.0, Entity Framework, ORM, .NET Framework

Continua a leggere .NET Framework 4.0 Beta 2: Entity framework 4.0.

Entity Framework 4.0 e le applicazioni preesistenti

Stefano Mostarda — Wed, 07 Oct 2009 22:24:09 GMT

Non c'� alcun dubbio che Entity Framework 1.0 abbia l'immenso limite di essere inusabile in applicazioni con database preesistenti che magari fanno uso stored procedure che tornano dati differenti dalle entity che l'applicazione tratta.

Daniele ne sa qualcosa e mi insulta ogni giorno per questo motivo. Io non c'entro niente, ma � un pattern molto diffuso dare sempre la colpa a me :D.

Comunque in Entity Framework 4.0 la cosa diventer� meno complicata. L'introduzione di POCO permetter� di mantenere il vecchio object/domain model cambiando poco codice. La possibilit� di mappare i risultati di una entity verso un complex type permette di non impazzire nel generare viste inutili sul database o nel SSDL. Insomma piccole cose che rendono l'integrazione di Entity Framework 4.0 in applicazioni preesistenti meno complicata di quanto non lo fosse con la versione precedente.

Lo so, NHibernate � ancora un bel p� avanti... ma date tempo al tempo

Stay tuned...

Tags: Entity Framework, ORM, Database

Continua a leggere Entity Framework 4.0 e le applicazioni preesistenti.

Entity Framework 4.0 e la customizzazione del codice

Stefano Mostarda — Sat, 25 Jul 2009 14:07:50 GMT

Non � una novit� che Entity Framework 4.0 permetta di generare codice tramite il motore di template T4. Quello che forse � meno noto � che si pu� customizzare anche il modo in cui il designer genera il codice per creare il database quando si usa l'approccio Model First.

Questo processo avviene tramite un worflow che analizza le classi disegnate e dapprima genera le sezioni MSL e SSDL dell'EDM e poi da quest'ultimo fa partire un la generazione dello script tramite T4. Lo script per il workflow si trova nelle cartelle di Visual Studio ed � facilmente individuabile perch� quando si apre il designer, nella finestra delle propriet� c'� il path dello xaml che lancia le activities.

Insomma semplicemente cambiando il file XAML e scrivendoci una nostra attivit�, possiamo trovare un nostro modo alternativo per creare il database. La prima cosa che mi viene in mente, � che possiamo persistere le classi che sfruttano l'ereditariet� con il modello TPH invece che TPT come avviene adesso. Magari sfruttando le annotation possiamo anche decidere di persistere in uno o nell'altro modo l'ereditariet�. inoltre, customizzando il template che genera il database dal file SSDL, invece che droppare e ricreare ogni volta le tabelle (un autentica mannaia perch� se abbiamo fatto delle ottimizzazioni come indici o altro perdiamo tutto) possiamo fare un compare con la struttura esistente nel db e aggiornare solo le discrepanze. Non dico assolutamente che sia facile, anzi. Quest'ultima cosa richiede parecchio lavoro e se Microsoft stessa ammette che non � una cosa che ha intenzione di fare un motivo ci sar�. Tuttavia se uno ha necessit� o tempo da perdere pu� costruirsi un generatore di codice veramente potente tale da rendere l'utilizzo del designer un vero e proprio gioiello.

Insomma, EF non � ancora perfetto, ma la struttura che c'� sotto � decisamente potente

Stay Tuned...

Tags: .NET Framework, .NET Framework 4.0, ORM, Database

Continua a leggere Entity Framework 4.0 e la customizzazione del codice.

Entity Framework e le performance con la Like

Stefano Mostarda — Tue, 09 Jun 2009 05:00:00 GMT

Nel bel mezzo della notte insonne ho deciso di fare qualche test per verificare quanto il problema mostrato in questo script fosse rilevante.

Ho creato una tabella con un solo campo di tipo varchar(50) e l'ho popolata con 500.000 righe. poi ho creato una console application ed ho eseguito la stessa query per 100 volte utizzando prima la sintassi LINQ To Entities e poi quella Entity SQL.

Il risultato � abbastanza impietoso perch� la sintassi LINQ To Entities impiega 1'02''815 mentre quella Entity SQL impiega 1''221. La differenza di 1 minuto su 100 query � enorme. questo fatto � da considerare quando si vogliono fare applicazioni scalabili con Entity Framework.. tenetelo a mente

Stay Tuned...

Tags: Entity Framework, LINQ

Continua a leggere Entity Framework e le performance con la Like.

Entity Framework e la generazione di codice POCO

Stefano Mostarda — Tue, 02 Jun 2009 18:22:55 GMT

Una delle cose pi� Sgradite di Entity Framework 4.0 � il fatto che il designer non genera classi POCO. Questa scelta � ovvia e rimarr� quella di default anche in RTM per mantenere la compatibilit� col passato. La buona notizia � che per la RTM il team dovrebbe anche includere un template T4 per la generazione di classi POCO.

La certezza assoluta � che questo template generer� le classi aggiungendole allo stesso assembly in cui si trova l'EDMX. Ora che finalmente abbiamo un sistema OTTIMO-FANTASTICO-ECCEZIONALE-MERAVIGLIOSO-PERFETTO di generazione del codice, questa limitazione si pu� superare. Cercando un p� in rete e partendo dalla base del template esistente, sono arrivato a creare un template che permette di:

Generare le classi e l'objectcontext in classi separate.

Aggiungere le classi ad un assembly diverso da quello in cui si trova l'edmx. Nell'assembly dell'ObjectModel o del DomainModel ad esempio. (Facoltativo).

Aggiungere l'objectcontext ad un assembly diverso da quello in cui si trova l'edmx. Nell'assembly del DAL ad esempio. (Facoltativo).

Mantenete il proprio codice aggiunto alle entities anche quando l'entit� viene rigenerata.

Ovviamente il tutto � molto Beta 1 ma credo sia un ottimo punto di partenza per capire come funziona il T4 e per avere classi POCO da subito. In altri post vedremo come ho risolto alcuni problemi. nel frattempo potete scaricare il template a questo indirizzo.

Tags: .NET Framework, .NET Framework 4.0, Entity Framework, ORM

Continua a leggere Entity Framework e la generazione di codice POCO.

.NET Framework 4.0 Beta 1: Entity Framework

Stefano Mostarda — Mon, 18 May 2009 14:14:28 GMT

In questi minuti � uscita la beta 1 del .NET Framework 4.0. Ovviamente, per quanto mi riguarda, la cosa pi� interessante � Entity Framework 4.0. Le novit� della nuova versione sono state annunciate gi� da tempo nel blog dedicato e quindi non ci sono cose nuove da scoprire.

Nonostante questo, credo che sia il caso di fare una carrellata in rigoroso ordine di preferenza personale :)

Supporto per mappare le stored procedure su tipi custom: fino ad ora le stored procedure potevano essere mappate solo verso entit� o su tipi custom che per� avessereo un mapping verso una tabella o view nel database. adesso finalente questo on sar� necessario. Baster� creare un ComplexType e mapparci la SP.
Designer decente. Finalmente il designer pu� defnirsi decente. innanzitutto c'� il supporto per i complex types ma soprattutto non ci sono crash ogni volta che si fa qualcosa di un pelino pi� complesso.
Customizzazione del codice generato tramite T4. Finalmente possiamo customizzarce il codice che genera il designer tramite un template. ovviamente possiamo anche suddividere le clasi su pi� file e molto altro ancora.
Persistence Ignorance. Gran bella novit� per carit�.... Ma non sempre mi � servit� come le altre precedenti
Miglior supporto per lo sviluppo n-tier con API che semplificano la vita.
Foreign-key per semplificare la vita quando si inseriscono sul db entit� in relazione tra loro (solo dopo la beta 1)
Possibilit� di generare il database partendo dalle classi (Model first).
Lazy loading

Ci sono altre piccole feature che scopriremo col tempo, ma direi che ormai � il momento di provarle sul campo :D.

Maggiori informazioni e le informazioni per il download sono disponibili nel nostro mini-sito dedicato al .NET Framework 4.0.

Stay Tuned...

Tags: .NET Framework 3.5, .NET Framework 4.0, Entity Framework, LINQ, ORM, .NET Framework

Continua a leggere .NET Framework 4.0 Beta 1: Entity Framework.

Entity Framework in action è in disponibile in MEAP

Stefano Mostarda — Mon, 16 Feb 2009 00:19:02 GMT

Da gioved� scorso il mio libro Entity Framework in action � ufficialmente disponibile in MEAP dal sito Manning.

Per ora sono disponibili i capitoli di introduzione, quello sul querying e quello sul mapping pi� una appendice dedicata a LINQ in generale ma molto presto ne vedrete anche altri.

E' inutile dire che la mia soddisfazione � immensa. Il libro � ancora ben lontano dall'essere perfetto ma mi piace come sta venendo su . speriamo piaccia anche a voi :D.

Stay tuned.

Tags: .NET Framework 3.5, Entity Framework, LINQ, ORM

Continua a leggere Entity Framework in action è in disponibile in MEAP.

Entity Framework e l'EDM

Stefano Mostarda — Sat, 31 Jan 2009 23:44:49 GMT

Penso che nessuno possa mettere in dubbio che il file di mapping sia una delle cose pi� complesse di Entity Framework. Microsoft ha prodotto un editor per semplificarne l'uso proprio perch� spesso, la differenze tra uno e l'altro ORM non � la potenza, ma la velocit� di startup. In questo Entity Framework non ha quasi rivali, pochi click ed il dominio � generato con tanto di mapping verso il database.

Tuttavia, l'editor nella versione attuale � monco. Non supporta Complex Types (ok non moriremo per questo, per�...), non supporta le DefiningQuery, sovrascrive ogni modifica fatta a mano nello storage layer (ogni tanto mi capita di metterci della roba che mi serve e doverla rimettere ad ogni aggiornamento mi rode), Non supporta il mapping di stored procedure polimorfiche, non supporta le QueryView. Insomma, ci sono diverse cose che qualunque progetto un tantinello pi� avanzato richiede e che il designer non supporta. Attenzione per�, per quanto riguarda i complex types, se li si introduce a mano il designer smette di funzionare, mentre negli altri casi continua a funzionare tranquillamente.

Queste lacune mi hanno fatto pensare ancora una volta di pi� che conoscere il mapping � fondamentale. Personalmente ritengo le DefiningQuery una delle feature pi� interessanti perch� permettono di creare delle view direttamente nel modello. Queste view sono interrogabili filtrabili etc etc e spesso risolvono tutti quei problemi di mapping che non sono gestibili in maniera nativa. Non emergendo nel designer, quanti le conoscono? Quanti le hanno mai usate? Nella mia esperienza in alcune aziende la risposta �: zero.

Mi riprometto di parlare di pi� di questa interessante feature di EF. Nel frattemo ribadisco quello che ho detto ad una persona tempo fa: non dire che una cosa non la puoi mappare se prima non sei passato per le DefiningQuery.

Stay Tuned...

Tags: .NET Framework 3.5, Entity Framework, LINQ, ORM

Continua a leggere Entity Framework e l'EDM.

Entity Framework e le Navigation Properties

Stefano Mostarda — Sat, 27 Dec 2008 23:12:26 GMT

Una relazione � per sua natura bidirezionale. Quello che non � sempre bidirezionale � la sua rappresentazione nel domain model. Prendiamo ad esempio la relazione tra clienti e ordini. Avere a disposizione il cliente di un ordine ha senso, ma ha senso avere a disposizione la lista degli ordini di un cliente? la risposta esatta come sempre �.... dipende. Ora non voglio disquisire sulla validit� o meno della relazione ma su come Entity Framework affronta il problema.

Per default, il wizard si accorge della relazione tra le tabelle e genera un domain model dove le relazioni tra le classi sono bidirezionali, quindi un ordine ha la relazione verso il cliente e il cliente ha una relazione verso gli ordini. Supponiamo che non ci sia utile in alcun modo la relazione tra cliente e ordine. La logica vuole che questa sia eliminata. Il primo problema � che il designer non lo permette; bisogna andare a mano nel codice ed eliminare la propriet� Ordini dalla classe Cliente e nel conceptual model del file di mapping eliminare il riferimento alla propriet� cancellata ed il gioco � fatto. Il secondo problema risale a LINQ to Entities. Abbiamo bisogno della propriet� Ordini per fare le nostre query? In tutti i progetti che ho seguito la risposta � stata no. Grazie al fatto che comunque l'ordine mantiene la propriet� Cliente si riesce a risalire a qualunque dato di cui si ha bisogno. L'unico vero problema sono le query generate a run-time. La regola numero uno � che bisogna sempre vedere le query generate per evitare problemi.

Comunque per ora la mia linea guida � quella di non creare propriet� inutili che complicano solo la vita.

Stay tuned...

Tags: .NET Framework, .NET Framework 3.5, Entity Framework, LINQ, ORM

Continua a leggere Entity Framework e le Navigation Properties.

Dubbio amletico sul codice SQL di Entity Framework con il Table per Hierarchy

Stefano Mostarda — Tue, 09 Dec 2008 00:14:02 GMT

Stavo facendo un p� di prove per smanettare con la gestione del Table per Hierarchy in Entity Framework. Innanzitutto dopo un impatto iniziale alquanto dramamtico, devo dire che il designer visuale mi ha aiutato non poco a disegnare la struttura partendo dalla classe autogenerata dal database. Visto che il designer � forse la cosa uscita peggio da Entity Framework, tutto sommato direi che questa � una buona cosa.

Dopo aver mappato tutto come si deve, ho eseguito una semplice query per trovare tutti gli oggetti: ctx.Company().ToList();

Quello che mi ha sorpreso � vedere che il generatore di codice di Entity Framework ha generato questo SQL:

SELECT
[Extent1].[Type] AS [Type],
[Extent1].[CompanyId] AS [CompanyId],
[Extent1].[Name] AS [Name],
[Extent1].[BillingAddress] AS [BillingAddress],
[Extent1].[BillingCity] AS [BillingCity],
[Extent1].[BillingZipCode] AS [BillingZipCode],
[Extent1].[BillingCountry] AS [BillingCountry],
[Extent1].[ShippingAddress] AS [ShippingAddress],
[Extent1].[ShippingCity] AS [ShippingCity],
[Extent1].[ShippingZipCode] AS [ShippingZipCode],
[Extent1].[ShippingCountry] AS [ShippingCountry],
[Extent1].[WSUserName] AS [WSUserName],
[Extent1].[WSPassword] AS [WSPassword],
[Extent1].[WSEnabled] AS [WSEnabled]
FROM [dbo].[Company] AS [Extent1]
WHERE ([Extent1].[Type] = 'C') OR ([Extent1].[Type] = 'S')

Ora, type � la colonna che mi fa da discriminatore tra i vari tipi che la tabella contiene, ma visto che tanto sto chiedendo tutti i tipi, � necessaria quella OR? Non capisco se sta li per sicurezza cos� che se ci sono altri record con un type diverso questi vengono ignorati, oppure sta li per errore.

Stay tuned...

Tags: .NET Framework 3.5, Entity Framework, LINQ, ORM

Continua a leggere Dubbio amletico sul codice SQL di Entity Framework con il Table per Hierarchy.

Il mio primo libro in inglese: Entity Framework In Action

Stefano Mostarda — Thu, 28 Aug 2008 10:12:00 GMT

Sono mesi che ci sto lavorando e finalmente il risutato si vede. Ormai tutto � pronto quindi posso annunciare che dopo ASP.NET 3.5 per tutti, partir� con la stesura del mio primo libro da "single" in inglese: Entity Framework In Action.

Come si intuisce dal titolo, il libro � pubblicato dalla Manning. Molti mi hanno sconsigliato di scrivere un libro su questo argomento vista la grande impopolarit� di Entity Framework. Io rimango della mia idea che seppur limitato da alcune scelte di design, che verranno in parte migliorate nella v2, questo framework ha un engine molto potente ed in futuro dir� la sua contro colossi come NHibernate (visto anche che � incluso nel framework).

Confesso di essere un tantinello terrorizzato perch� scrivere un libro in inglese che verr� letto in tutto il mondo � una cosa non proprio semplice da affrontare, ma ormai come mi ha detto Daniele "hai voluto la bicicletta ..." :).

Chiudo con i ringraziamenti d'obbligo ad Alessandro, lui sa benissimo il perch�. Ora non mi rimane che buttarmi a capofitto nella stesura del libro, sperando di riuscire a convincere la gente che in realt� Entity Framework non � cos� malaccio come si dice :).

Stay Tuned...

Tags: .NET Framework, .NET Framework 3.5, Entity Framework, LINQ, ORM

Continua a leggere Il mio primo libro in inglese: Entity Framework In Action.