8

Abbiamo utilizzato EF 4.0 con un approccio basato sul database utilizzando un modello .edmx.Influenza del modo in cui le classi di entità vengono create in codice EF 6 dal database

Stiamo eseguendo l'aggiornamento a EF 6.1.3 e stiamo esaminando se utilizzare o meno il modello .edmx. Sicuramente vogliamo ancora avere il controllo del nostro schema di database, quindi creeremo nuove tabelle ecc. Con lo script SQL e quindi genereremo il modello EF (o .edmx o solo classi di codice) dal database esistente.

Durante le prove con Visual Studio 2013, ho notato un punto fastidioso quando EF 6 crea le classi dal database esistente. Ho una classe Customer che si collega a una classe Contact tre volte: una per lo DesignContact, una per lo SalesContact e una terza volta per lo SupportContact. Queste sono memorizzate come colonne DesignContactId (INT) ecc. Nella tabella Customer.

È possibile creare le classi di utilizzo di questo T-SQL:

CREATE TABLE dbo.Contact 
(
    ContactID INT NOT NULL 
     CONSTRAINT PK_Contact PRIMARY KEY CLUSTERED, 
    Name VARCHAR(200), 
    Address VARCHAR(200), 
    ZipCode VARCHAR(20), 
    City VARCHAR(100), 
    Phone VARCHAR(100) 
) 

CREATE TABLE dbo.Customer 
(
    CustomerID INT NOT NULL 
     CONSTRAINT PK_Customer PRIMARY KEY CLUSTERED, 
    Name VARCHAR(200), 
    -- other properties 
    DesignContactID INT 
     CONSTRAINT FK_Customer_DesignContact 
      FOREIGN KEY REFERENCES dbo.Contact(ContactID), 
    SalesContactID INT 
     CONSTRAINT FK_Customer_SalesContact 
      FOREIGN KEY REFERENCES dbo.Contact(ContactID), 
    SupportContactID INT 
     CONSTRAINT FK_Customer_SupportContact 
      FOREIGN KEY REFERENCES dbo.Contact(ContactID), 
) 

Quando si creano le classi dal database, vedo questo:

  • classe Customer ha i miei tre xxxContactId colonne come campi - è come previsto
  • EF genera anche tre proprietà di navigazione di tipo Contact - ma le chiama Contact, Contact1, Contact2 - uuuuuggghHHHH!

Sto cercando di trovare un modo per aggirare quei terribilmente cattive caratteristiche di navigazione di nome ..... questi sono cattivi perché:

  • loro non intuitivi - punti quali uno per cui il contatto ora ?
  • sono "stabili" o potrebbero cambiare nel tempo se viene introdotta una quarta relazione con Contact? Non è sicuro ..... (non può trovare nessuna documentazione su questo)
  • solo i loro nomi sono assolutamente orribile ...... perché non si chiamano DesignContact (sulla base di DesignContactId), SalesContact (sulla base degli SalesContactId) eccetera.?

In EF 4.1 in su, sono stati in grado di aggiungere modelli T4 al .edmx e influenzare il processo di generazione - è che ancora possibile in qualche modo con EF6, se si sta facendo "Genera codice prima dal database esistente" approccio? Non sono riuscito a trovare più post o articolo su questo argomento .....

Oppure c'è un altro modo per influenzare il modo in cui EF genera le classi, in particolare le proprietà di navigazione? Posso definire qualche tipo di convenzione personalizzata o qualcosa per influenzare questo?

+1

@JulieLerman: qualche idea su questo (come il _Queen di EF_ :-)?) –

+0

@RowanMiller: idee o trucchi per gestirlo? –

+0

Applicabile: http://stackoverflow.com/a/13064383/1207195? (non votando come duplicato a causa del martello) –

risposta

0

Grazie a tutti per la cippatura in - ho provato vari approcci:

  • ho provato il progetto "EF inversione Poco" su CodePlex, ma non era molto felice con esso a tutti

  • Ho provato EF Power Tools per EF 6 - e ha funzionato bene. Questo mi ha permesso di aggiungere modelli T4 per influenzare il processo di generazione del codice. Funziona, ma ora la sfida è capire il modello oggetto utilizzato come base per la generazione del codice (che sembra non documentato ...)

  • Ho provato il pacchetto NuGet Entity Framework 6.1.3 Code Templates for C# - funziona anche molto bene, ma ha gli stessi problemi come i Power Tools - per cambiare realmente qualcosa, un sacco di scavare nel modello a oggetti saranno necessari

0

È possibile modificare le impostazioni per le classi generate nel file .edmx (tramite blocco note, ecc.). Esegui il backup prima di cambiarlo. Non è l'ideale, ma funziona e gli aggiornamenti dal db non sovrascrivono le tue modifiche.

<EntityType Name="SomeEntityName" a:TypeAccess="Internal" xmlns:a="http://schemas.microsoft.com/ado/2006/04/codegeneration"> 
    <Key> 
     <PropertyRef Name="Id" /> 
    </Key> 
    <Property Name="Id" Type="Int32" Nullable="false" annotation:StoreGeneratedPattern="Identity" /> 
    <Property Name="Contact" Type="String" Nullable="false" MaxLength="Max" FixedLength="false" Unicode="false" /> 
    <Property Name="DesignContact" Type="String" Nullable="false" MaxLength="50" FixedLength="false" Unicode="false" /> 
</EntityType> 
+0

I ** non hanno ** un file '.edmx' ...... questo viene generato dal database in ** code-first ** (o solo code) Classi C# - niente più file '.edmx' ..... –

+0

@marc_s Povera lettura da parte mia. Sono andato in codice prima e scrivere la mappatura delle entità non è poi così male, il che, se sto leggendo correttamente, allevierebbe il tuo problema. Altrimenti ho generato edmx e l'ho modificato se necessario. –