Udostępnianie modelu między wieloma plikami edmx (Entity Framework 4.0)

Question

Poszukuję rozwiązania problemu, w którym jestem i prawdopodobnie wiele osób musi się zmierzyć.

Obecnie pracuję nad aplikacją zawierającą prawie 400 tabel. Aplikacja składa się z siedmiu projektów biblioteki klas (StudentInfo, biblioteka, opłaty itp.) I każdy ma własny plik .edmx (składający się z 50 tabel) ze strategią generowania kodu = domyślnie I pojedynczy projekt aplikacji internetowej, który odwołuje się do projektów biblioteki klas .
Istnieje około 15 tabel, które są wspólne i będą obecne w pliku .edmx w każdym projekcie biblioteki klas. Przestrzeń nazw klas/modeli jest taka sama (Campus) we wszystkich plikach .edmx.

Utworzyłem klasę częściową, mianowicie Szkołę (która jest jedną z commom table/model), która zawiera pewne metody.

Jednak następujący błąd kompilacji czas jest wyrzucane Rodzaj istnieje 'Campus.School' zarówno 'D: \ Project \ Campus \ CampusStudent \' i „D: \ Project \ Campus \ CampusLibrary \ bin \ Debug \ CampusLibrary.dll '

Rozwiązania zasugerowane przez innych użytkowników
1) Mają oddzielne przestrzenie nazw dla każdego pliku .edmx.
2) Użyj różnych nazw modeli, takich jak StudentSchool, LibrarySchool itp.
Oba rozwiązania zmusią mnie do powielenia wspólnych klas z ich metodami w każdym z projektów bibliotek klasowych. Czy ktoś może mi pomóc?

Answer 1

Może istnieć sposób, jeśli używasz szablonu POCO T4 do generowania bieżącego obiektu. POCO w EF może być dowolną klasą w dowolnym obszarze nazw, które mają taką samą nazwę jak encja w twoim EDMX i które mają wszystkie właściwości o tej samej nazwie co encja w EDMX (włączając te same typy i możliwości dostępu dla pobierających i ustawiających).

Zdefiniuj swoje 15 klas współdzielonych w innym zestawie (musisz przestrzegać tych zasad POCO) i odwołaj się do nich we wszystkich projektach bibliotecznych. Po utworzeniu tego zestawu utwórz własną wersję szablonu POCO T4, która nie będzie tworzyć nowych plików klas dla tych jednostek współużytkowanych, a zamiast tego będzie używać klas z zestawu referencyjnego.

Inną opcją jest ręczne tworzenie i konserwacja wszystkich tych 400 klas i typów kontekstu EF. To właśnie zrobisz, jeśli użyjesz mapowania tylko kodu (również jako kodu pierwszego) i nie będziesz miał takich problemów.