Il presente articolo è stato tradotto automaticamente.

I punti dati

Il EF6, EF7 e zuppa di ASP.NET 5

Julie Lerman

Julie LermanLa colonna di punti dati gennaio 2015, "Looking Ahead Entity Framework 7," evidenziato quello che stava arrivando in EF7 guardando lo stato della alfa EF7 al momento che ho scritto l'articolo. Nel dicembre 2014, proprio come il problema di tale colonna è stato andare in stampa, il team EF fatta una decisione importante riguardo i comunicati EF7 di staging. Sono riuscito a spremere due frasi dell'articolo all'ultimo minuto: "Secondo il post a bit.ly/1ykagF0, ' EF7 — priorità, Focus e rilascio iniziale,' il primo rilascio di EF7 si concentrerà sulla compatibilità con ASP.NET 5. Le versioni successive aggiungerà ulteriori caratteristiche."

Da allora, ho trovato che l'ordinamento che cosa, esattamente, questo significa essere un po' di confusione. Voglio essere sicuro che si capisce abbastanza bene che questa release iniziale di EF7 obiettivi, se si deve usare esso e quali sono le opzioni.

Esso contribuirà a discutere la differenza tra la versione successiva di Microsoft .NET Framework e applicazioni ASP.NET 5 verranno eseguito. Io ti forniscono uno sguardo ad alto livello, ma controlla articolo su Daniel Roth, "Immersione profonda nel Runtime ASP.NET 5," la rivista di marzo 2015 per guadagnare una comprensione più approfondita. Poi ti spiego come EF6 ed EF7 inserisce nel mix.

ASP.NET 5 (aka ASP.NET vNext) è stato progettato per avere meno affidamento sulla completa di .NET Framework e anche Windows stesso. Sotto l'ombrello di ASP.NET 5, è possibile creare applicazioni Web e Web API utilizzando la nuova funzione combinata impostata in ASP.NET MVC 6, librerie di classi e anche un'applicazione console. Se pensi di ASP.NET come un modo per creare siti Web, l'applicazione console è un mistero. Ma ASP.NET 5 davvero sta fornendo una nuova "versione" di .NET Framework su cui può sedersi apps. Infatti, questa nuova versione ha attualmente due sapori — uno che gira sul completo Common Language Runtime (CLR) e un'altra che gira sul nuovo CoreCLR. Un terzo, che verrà eseguito su un CLR multipiattaforma, si aggiungeranno nel prossimo futuro. La versione più snella è chiamata il nucleo .NET, che corre in un runtime snello, CoreCLR. Se si pensa al tuoi inizio lezioni su .NET Framework, si potrebbe ricordare che Microsoft definito Common Language Infrastructure (CLI), che è una specifica. Quindi Microsoft costruito CLR basato su CLI. Mono è un'altra implementazione di CLI che gira su Linux e Mac OS X. Applicazioni .NET hanno sempre dipendeva dalla disponibilità di un'implementazione di CLI. La maggior parte di noi hanno usato Visual Studio e Windows per creare applicazioni .NET che dipendono da CLR. Novell è diventato sempre più popolare per lo sviluppo di applicazioni che possono essere eseguito su Mono.

Il Entity Framework e CoreCLR

Ora, Microsoft ha creato un'implementazione semplificata della CLI chiamato CoreCLR che non solo è open source, ma può anche essere distribuito da NuGet e altri gestori di pacchetti. Questo dà agli sviluppatori la possibilità di creare applicazioni leggeri che sono grandi per i dispositivi mobili e applicazioni server basate su cloud. E inoltre rimuove il vincolo per distribuire applicazioni solo per macchine Windows.

Entity Framework 6 (e versioni precedenti) si basa sulla completa di .NET Framework e Common Language Runtime completo e non verrà eseguito con applicazioni CoreCLR di targeting. Ma EF7 è stato progettato come un insieme di API più piccole, componibili che possono essere mescolati e abbinati basato sul set di funzionalità che è necessario. Ad esempio, se il targeting un non -­archivio dati relazionale, non è necessario la funzionalità relazionali o migrazioni progettate per database relazionali. Con EF7, quella logica è una DLL separata che non sarà necessario recuperare e caricare in memoria.

Quando si sceglie di indirizzare CoreCLR, farlo selezionando l'ambiente di runtime corretto. Per andare con ASP.NET 5, Microsoft ha creato l'ambiente di Runtime K (KRE) che, come descritto da ASP.NET MVP Gunnar Peipman, "... è il codice necessario per avviare ed eseguire un'applicazione di vNext ASP.NET . Il Runtime di K sarà rinominato a un certo punto prima che venga rilasciato. Tenere d'occhio per questo cambiamento. Ad esempio, il KVM (versione manager) diventerà il DNVM (Manager versione .NET). Il runtime include cose come il sistema di compilazione, strumenti SDK e gli host di Common Language runtime nativi"(bit.ly/1x9rpOn). Ci sono versioni a 32-bit e 64-bit la KRE che supportano il CoreCLR. Potete vedere questi come opzioni di destinazione delle applicazioni ASP.NET 5 in Figura 1.

selezionando il Target KRE in un'applicazione ASP.NET 5
Figura 1 selezionando il Target KRE in un'applicazione ASP.NET 5

Il modo più semplice per vedere EF7 in un'applicazione, di fuori di guardare il video demo nel mio corso Pluralsight, "Looking Ahead Entity Framework 7" (bit.ly/18ct13F), è quello di utilizzare il modello di progetto ASP.NET 5, che vi darà una soluzione con EF7 già cablati fino a fornire l'autenticazione basata su identità all'applicazione.

Iniziare scegliendo un'applicazione Web ASP.NET e poi il modello Starter Web ASP.NET 5, come mostrato Figura 2.

crea una nuova applicazione ASP.NET 5 con Entity Framework 7 preconfigurata
Figura 2 crea una nuova applicazione ASP.NET 5 con Entity Framework 7 preconfigurata

Troverete che i pacchetti EF7 EntityFramework.SqlServer ed EntityFramework.Commands sono già selezionati. Il pacchetto di SqlServer causerà relative dipendenze (EntityFramework.Core, EntityFramework.Relational) per essere tirato dentro.

Si può vedere questo nel file project.json, che elenca i pacchetti per NuGet recuperare nella sua sezione dipendenze. Qui sono alcune linee da quella sezione:

"dependencies": {
  "EntityFramework.SqlServer": "7.0.0-beta2",
  "EntityFramework.Commands": "7.0.0-beta2",
  "Microsoft.AspNet.Mvc": "6.0.0-beta2",

Si può anche vedere ciò che finisce nella sezione riferimenti, che, per impostazione predefinita, elenca i riferimenti per il ASP.NET 5.0 e versioni di ASP.NET 5.0 Core dell'applicazione. Figura 3 Mostra la lista con i riferimenti di Core 5.0 ASP.NET ampliati. Si noti che poiché il modello è destinato al momento la versione beta2, vedrete il pacchetto di migrazioni a cui fa riferimento, anche se in una versione successiva, le migrazioni divennero parte dell'API relazionale.

entrambi ASP.NET 5.0 e riferimenti Core 5.0 ASP.NET contengono APIs ed Entity Framework 7 pacchetti
Figura 3 entrambi ASP.NET 5.0 e riferimenti Core 5.0 ASP.NET contengono APIs ed Entity Framework 7 pacchetti

ASP.NET 5 EF7 abbracciare e fanno molto affidamento sull'iniezione di dipendenza (DI). Si può vedere in Startup.cs del progetto in Figura 4 che non c'è logica per sapere l'applicazione deve utilizzare Entity Framework, sua SQL Server API e il singolo predefiniti DbContext utilizzato per la sicurezza, ApplicationDbContext. Si può vedere questo stesso contesto essendo cablato come il servizio di identità per l'applicazione. La stringa di connessione viene memorizzata nel file config.json e i fili del costruttore di avvio su quel file, quindi l'applicazione sarà in grado di trovare quando necessario.

Figura 4 lista parziale di Default Startup.cs

public class Startup {
  public Startup(IHostingEnvironment env) {
    Configuration = new Configuration()
      .AddJsonFile("config.json")
      .AddEnvironmentVariables();
  }
  public IConfiguration Configuration { get; set; }
  public void ConfigureServices(IServiceCollection services) {
    services.AddEntityFramework(Configuration)
      .AddSqlServer()
      .AddDbContext<ApplicationDbContext>();
    services.AddIdentity<ApplicationUser, IdentityRole>(Configuration)
      .AddEntityFrameworkStores<ApplicationDbContext>();
       services.AddMvc();  }

Il modello di progetto ora imposta è di default per utilizzare EF7 e utilizzare la sua logica se il targeting CoreCLR semplificato o completa di .NET Framework. Infatti, per impostazione predefinita, il progetto non è definito da eseguire sotto il CoreCLR, ma di utilizzare il Framework .NET completo. Così vediamo dove si inserisce questa opzione.

CLR completo per ASP.NET 5 (ed Entity Framework)

C'è un aggiornamento per la venuta di .NET Framework, .NET Framework 4.6, e vi permetterà di continuare a creare tutti gli stili del software che avete potuto già — da Windows Form e Web Form Windows Presentation Foundation (WPF) e applicazioni MVC 5 ASP.NET . Grazie alle altre versioni KRE mostrati Figura 1, KRE-CLR-amd64 e KRE-CLR - x86, è anche possibile eseguire un'applicazione ASP.NET 5 .NET Framework completo. Ciò consente di avere la tua torta e mangiarla, troppo, se si desidera beneficiare di altre nuove funzionalità di ASP.NET 5, come MVC 6 o la nuova API del Web, che è una fusione di controller MVC e Web API. Vi dà anche la compatibilità perché il targeting completo .NET Framework e Common Language Runtime e può accedere il suo set completo di funzionalità. Per impostazione predefinita, il file project.json indica che si desidera essere in grado di eseguire l'applicazione con entrambe le versioni di CLR:

"frameworks": {
      "aspnet50": { },
      "aspnetcore50": { }
    },

Si potrebbe rimuovere la riga "aspnetcore50" completamente (insieme con il punto e virgola alla fine della riga precedente) e l'effetto sarebbe duplice. In primo luogo, la sezione Core 5.0 ASP.NET scomparirebbero dai riferimenti in Esplora soluzioni. In secondo luogo, gli obiettivi KRE visualizzato Figura 1 sarebbe ridotto a solo le opzioni KRE-CLR.

Si sarebbe ancora EF7 di targeting e ottenere tutti i vantaggi di questa nuova versione. Ma, ciò che non è stato evidente è che perché KRE-CLR destinato a .NET Framework completo, è compatibile con Entity Framework 6. Questo significa che se avete la logica EF6 esistente, è possibile utilizzarlo in combinazione con ASP.NET 5 (anche se non la versione CoreCLR) e di ottenere i vantaggi delle nuove funzionalità di ASP.NET 5 senza dover rielaborare il codice per allineare con EF7 EF6.

5 ASP.NET (CLR completo) con EF6

Sapendo che questo era possibile, naturalmente, ho dovuto cercare di ottenere EF6 in una soluzione di ASP.NET 5. Tenere presente che l'approccio che ho preso per raggiungere questo obiettivo può benissimo bisogno di cambiare tra la versione molto precoce che sto usando ora (nel febbraio 2015) e quando sono uscito ASP.NET 5 e Visual Studio 2015.

Ho trovato che il fattore più importante nel raggiungimento di questo era mantenendo il Entity Framework logica e dipendenze in un progetto separato dal progetto ASP.NET 5. Io in genere design mia applicazioni questa modo comunque, piuttosto che avere tutti gli strati della mia app in un singolo progetto. Con un progetto separato dedicato alla EF, non devi preoccuparti per l'app ASP.NET 5 tirando in EF7 API al volo.

Piuttosto che a partire con il progetto di Web Starter ASP.NET 5, sei meglio utilizzando il modello di progetto vuoto ASP.NET . Il file project.json ha solo una dipendenza specificata, Microsoft.Asp.NET.Server.IIS.

Successivamente, si crea un secondo progetto. Ho scelto un progetto libreria di classi .NET 4.6. Quindi potrei usare la Console di Gestione pacchetti per installare EF6 garantendo facevo a nuget.org come la sorgente del pacchetto e alla libreria di classi come progetto predefinito. A questo punto ho potuto chiamare il pacchetto di installazione entityframework come ho sempre fatto. Questo ha portato EntityFramework ed entityframework.sqlserver.dll nel progetto.

Per eseguire il test, ho creato una classe semplice, Ninja.cs (perché penso di EF6 come l'edizione di Ninja, mentre EF7 è l'edizione di Samurai):

public class Ninja {
    public int Id { get; set; }
    public string Name { get; set; }
  }

e un DbContext esposto un DbSet dei ninja:

public class NinjaContext : DbContext {
  public NinjaContext()
    :base(@"Data Source=(localdb)\mssqllocaldb;
          Initial Catalog=NinjaContext;
          Integrated Security=True;"){ }
  public DbSet<Ninja> Ninjas { get; set; }
}

Per semplicità in fase di test, ho hardcoded per la stringa di connessione del SQL Server direttamente nella mia classe DbContext.

Con il mio modello definito, posso consentire migrazioni, aggiungere una nuova migrazione e creare il database, come ho sempre fatto. Si noti che, quando ho installato EF6 nel progetto dati, ho lasciato il file app. config che il pacchetto creato così ho potuto impostare quel progetto come progetto di avvio e quindi i comandi di migrazione avrebbe funzionato correttamente. Ho anche usato il metodo di DbMigrationsConfiguration seme per pre-seme il database con alcuni ninja.

Non voglio fare EF chiamate direttamente dall'applicazione ASP.NET 5 e creare confusione versione, quindi ho una classe nel mio progetto EF6 che incapsula le query che avrò bisogno. Ho chiamato questo Repository perché fa comodo il mio scopo, ma questa non è una classe che segue il modello di repository. Questo non è difficile con un app demo e una singola query, ma è possibile utilizzare il tuo modello preferito per separazione delle preoccupazioni per le applicazioni più complesse:

public class Repository  {
  public List<Ninja> GetAllNinjas() {
    using (var context=new NinjaContext())
    {
      return context.Ninjas.ToList();
    }
  }
}

Con l'accesso ai dati progetto tutto impostato, posso tornare al progetto ASP.NET 5. Ho creato un semplice controller per recuperare e restituire una vista:

public class NinjaController : Controller
  {
    public IActionResult Index()
    {
      var repo = new Repository();
        return View(repo.GetAllNinjas());
      }
    }
  }

Ho anche creato un semplice Index.cshtml che elencherà i ninja passati dal controller:

@model List<EF6Model.Ninja>
@{
  ViewBag.Title = "EF6 Ninjas";
}
@foreach (var item in Model)
{
  @Html.Label(item.Name);
}

Infine, Figura 5 illustrato il codice aggiunto al file startup.cs, per iniettare i servizi MVC e specificare di routing per il controller di Ninja.

Figura 5 classe di avvio per configurare l'applicazione ASP.NET 5 che utilizza il Entity Framework 6

public class Startup  {
  public void Configure(IApplicationBuilder app) {
    app.UseMvc(routes =>
    {
      routes.MapRoute(
      name: "default",
      template: "{controller}/{action}/{id?}",
      defaults: new { controller = "Ninja", action = "Index" });
     });
  }
  public void ConfigureServices(IServiceCollection services)  {
    services.AddMvc();
  }
}

Anche rimosso il quadro aspnetcore50 dal file project.json, garantendo che solo a indirizzare il CLR completo.

Con il database e alcuni dati di seme creati dalle migrazioni, sono in grado di vedere l'applicazione ASP.NET 5, lavorando con il progetto basato su EF6, visualizzazione di dati che è stati recuperati utilizzando EF6 (vedere Figura 6).

ASP.NET 5 applicazione visualizzazione dei dati tramite Entity Framework 6
Figura 6 ASP.NET 5 applicazione visualizzazione dei dati tramite Entity Framework 6

Will Essere subito utilizzando EF7 e ASP.NET 5?

Io sono molto interessato a nuove funzionalità di EF7 e imparare a sfruttare meglio le loro. Sono anche impaziente di capire questo nuovo viale di programmazione che si apre ASP.NET 5. CoreCLR diventerà più ricco come si evolve, come sarà EF7. Sono impressionato con lo stato di EF7 come sarà rilasciato con ASP.NET 5. Ma perché io non sono uno sviluppatore Web, non ho un motivo per lavorare nel codice di produzione ai margini sanguinanti del ASP.NET, e il team EF è stato chiaro che consiglia di utilizzare la versione iniziale di EF7, che verrà contrassegnato come una versione provvisoria, solo con le applicazioni ASP.NET 5. In caso contrario, guida della squadra è attendere EF7 è rilasciato come versione vera. Quindi, io posso bene attendere le successive uscite di EF7, ma continuare a seguire e sperimentare con il progetto come si evolve per guadagnare ulteriori parità con le caratteristiche di EF6 che altrimenti potrei salta.

CoreCLR è attualmente troppo sanguinamento bordo per i miei gusti. Se trovo uno scenario che si inserisce quello che sarà disponibile l'intero comunicato CLR di ASP.NET 5, così come la funzionalità gruppo del prerelease EF7, quindi sarò desideroso di prendere quel sentiero. È più probabile, tuttavia, che finirò per aspettando le versioni successive. E poi ASP.NET 5 e CoreCLR sarà più ricca, troppo. Per me, personalmente, il tempo fino ad allora fornirà la possibilità di esplorare e conoscere questi strumenti in preparazione per la successiva release.

Nel frattempo, mi raccomando leggere il post sul blog di Scott Guthrie, "Introducing ASP.NET 5," a bit.ly/1wV4zzm per avere una migliore comprensione di tutte le nuove caratteristiche che ASP.NET 5 porta. Le API componibili sono solo uno dei molti miglioramenti eccitanti che gli sviluppatori guadagnerà in questo turno.


Julie Lerman è un Microsoft MVP, consulente che vive nelle colline del Vermont e mentore .net. Puoi trovare suo presentando dati accesso e other.NET argomenti a gruppi di utenti e conferenze in tutto il mondo. Blog di lei a /Blog ed è l'autore di "programmazione Entity Framework" (2010), nonché un codice prima edizione (2011) e un DbContext edizione (2012), tutti da o ' Reilly Media. Seguirla su Twitter a Twitter.com /julielerman. e vedere i suoi corsi Pluralsight presso Juliel.me/PS-video.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Rick Strahl
Rick Strahl è il Big Kahuna West Wind Technologies, situato sulla splendida isola di Maui, Hawaii. Tra windsurf sessioni e avventure spikey-dai capelli, Rick è stato uno sviluppatore di software per oltre 25 anni, costruzione di business e le applicazioni Web fin dai tempi molto precoci del Web quando vi serve una manovella a mano (o un paio di giuntatrici a filo) per ottenere on-line. Oggi Rick costruisce basato su client Web applicazioni e servizi per i clienti con HTML5, JavaScript e tecnologie Web mobile, utilizzando AngularJS sull'estremità anteriore, e terminano la pila ASP.NET e tecnologie Microsoft sul retro. Azienda di Rick, West Wind Technologies, produce anche una serie di strumenti relative agli sviluppatori, tra cui West Wind WebSurge, West Wind Web Monitor e generatore di Html Help.  Rick mantiene anche una serie di librerie open source presso github.com/RickStrahl e si può trovare il suo blog a weblog.west wind.com o contattarlo direttamente presso rstrahl@west-wind.com.