Wpływające na tworzenie klas encji w kodzie EF 6 z bazy danych

Question

Używamy EF 4.0 z podejściem bazodanowym z wykorzystaniem modelu .edmx.

Przeprowadzamy teraz uaktualnienie do wersji 6.1.3, a my badamy, czy warto zastosować ten model .edmx, czy też nie. Zdecydowanie nadal chcemy mieć kontrolę nad naszym schematem bazy danych - będziemy więc tworzyć nowe tabele itp. Za pomocą skryptu SQL, a następnie generować model EF (albo .edmx lub tylko klasy kodu) z istniejącej bazy danych.

Podczas moich prób z Visual Studio 2013, zauważyłem irytujący punkt, gdy EF 6 tworzy klasy z istniejącej bazy danych. Mam klasę Customer, która łączy się z klasą Contact trzy razy - raz dla DesignContact, raz dla SalesContact i po raz trzeci dla SupportContact. Są one przechowywane w kolumnach DesignContactId (INT) itd. W tabeli Customer.

Można tworzyć te klasy przy użyciu tego 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), 
) 

Podczas tworzenia klas z bazy danych, widzę to:

• klasa Customer ma moje trzy xxxContactId kolumn dla poszczególnych pól - zgodnie z oczekiwaniami
• EF generuje również trzy właściwości nawigacyjne typu Contact - ale nazywa je Contact, Contact1, Contact2 - uuuuuggghHHHH!

Staram się znaleźć sposób, aby dostać się wokół tych potwornie złych nazwanych właściwości nawigacyjnych ..... są złe, ponieważ:

• ich nie intuicyjne - który z nich punkty, które teraz kontakt ?
• są "stabilne", czy też mogą się zmieniać z czasem, jeśli zostanie wprowadzony czwarty związek z Contact? Nie jestem pewien ..... (nie mogę znaleźć żadnych dokumentów na ten temat)
• tylko ich nazwy są absolutnie okropne ...... dlaczego nie są nazywane DesignContact (w oparciu o DesignContactId), SalesContact (na podstawie SalesContactId) itp.?

W EF 4.1 i do góry mogli dodać szablonów T4 do .edmx i wpływać na proces generacji - czy to jeszcze możliwe w jakiś sposób z EF6, jeśli robisz „Generowanie kodu najpierw z istniejącej bazy danych” podejście? Nie mogłem już znaleźć żadnego posta na blogu lub artykułu na ten temat .....

Czy istnieje inny sposób wpływania na EF, który generuje klasy - w szczególności na właściwości nawigacji? Czy mogę zdefiniować jakąś niestandardową konwencję lub coś, co wpłynie na to?

Answer 1

Dzięki wszystkim za wykruszenia w - Próbowałem różnych podejść:

• Próbowałem projekt „EF Odwrócona Poco” na Codeplex ale nie był z niego zadowolony w ogóle

• Próbowałem EF Elektronarzędzia dla EF 6 - i działało dobrze. Pozwoliło mi to dodać szablony T4, aby wpłynąć na proces generowania kodu. Działa - ale wyzwaniem jest teraz zrozumienie, jaki model obiektowy jest używany jako podstawa generowania kodu (co wydaje się być nieudokumentowanym ...)

• Wypróbowałem pakiet NuGet Entity Framework 6.1.3 Code Templates for C# - działa też całkiem ładnie, ale ma takie same problemy jak elektronarzędzia - rzeczywiście coś zmienić, dużo kopania do modelu obiektowego będą potrzebne

Answer 2

Możesz zmienić ustawienia dla wygenerowanych klas w pliku .edmx (za pomocą notatnika itp.). Po prostu wykonaj kopię zapasową, zanim ją zmienisz. To nie jest idealne, ale działa i aktualizacje z bazy danych nie zastępują zmian.

<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>