Passa ai contenuti principali

Post

Visualizzazione dei post con l'etichetta .Net Framwork 4

SqlServer di Aruba - Entity Framework 4.0 - Problema dello Schema

Lo schema in MsSql è un elemento intermedio fra il database e le tabelle, lo schema predefinito è dbo e compare nel nome tabella come [dbo].[NomeTabella] .  In fase di generazione di un modello .edmx Entity Framework permette di impostare lo schema tramite la proprietà "Database Schema Name" dell'edmx.  Questo valore però non sarà modificabile a Runtime perchè cablato nei metadati. Il servizio SqlServer di aruba purtroopo crea le tabelle in uno schema che ha lo stesso nome dell'utente (per esempio MSSql123).  Quindi un edmx generato in locale a partire da tabelle definite nello schema dbo non fuzionerà. Vi sono due possibili Soluzioni: In locale definisco le tabelle di sviluppo nello stesso schema in cui saranno sul Sql di Aruba. CREATE SCHEMA  MSSql123 GO CREATE TABLE [MSSql123].NomeTabella] ( ... ......); Impongo che i metadati non vengano inseriti nella dll, ed edito a mano i tre file xml di metadati sostituendo dbo con lo schema in uso su aruba o...

MEF

MEF ( Managed Extensibility framework ) MEF è abbondantemente usato da VS2010 ( Plugin ) MEF è in incluso nel framework Un video introduttivo da channle 9 cosa risolve MEF Plugin ( and composite application ) Decoupling Application Partitioning (download on demand ) Third Party Extensibility Il consiglio del video: se si ricorre periodicamente nel risolvere uno dei problemi sopra indicati MEF può essere d'aiuto. Se il decouplig , l' IoC non sono un problema centrale (o i partecipanti al progetto non già orientati o nemmeno sono disposti a fare un salto mentale per capire quanto decoupling e Ioc siano importanti per la manutenibilità di un progetto) allora è meglio abbandonare MEF . Per cosa non usare assolutamente MEF : come ORM (non ho capito dal video se fosse una battuta o meno, in ogni caso è meglio non farlo).