.NET: Konwersja z LINQ na SQL na Entity Framework

Question

Aby prototyp projektu działał jak najszybciej, użyłem LINQ do SQL dla utrwalania danych.

Teraz projekt jest bardziej dojrzały i uruchamiam ograniczenia współbieżności z LINQ na SQL. Ponieważ nie jest to ORM, ani nie był przeznaczony do użytku korporacyjnego, chciałbym zastąpić wszystkie LINQ do pracy SQL z trwałości Entity Framework.

Co się w tym bierze udział? Czy którekolwiek z moich LINQ do SQL pracy mogą zostać zmienione na EF? Czy od początku będę musiał zacząć od początku z EF? Gdzie zaczynam? Jakieś pomocne linki lub porady?

Answer 1

Wiele osób dokonuje tego samego nawrócenia. Istnieje szablon, którego można użyć do konwersji tutaj: http://blogs.msdn.com/b/efdesign/archive/2009/08/13/linq-to-sql-to-entity-framework-conversion-template.aspx

Answer 2

Jest to dość trudny problem i jednym z głównych powodów, dla których zalecałem ludziom unikanie LinqToSql przez dłuższy czas. Microsoft nie chce osób używających LinqToSql.

Twój najlepszy zakład najprawdopodobniej rozpocznie się od nowa i ponownie użyje kodu, kiedy/jeśli możesz (niektóre z twoich zapytań Linqa mogą automatycznie przetłumaczyć prawie jeden na jeden, ale nawet to nie jest pewne).

LinqToSql to prawdziwa, ale słaba funkcjonalność ORM. LinqToSql może i jest używany w przedsiębiorstwie przez osoby, które nie wymagają zaawansowanych funkcji ORM.

Nie jesteś jedyną osobą, która pójdzie tą drogą (próbując "uaktualnić" z LinqToSql do EntityFramework), ale nie jest jasne w tym momencie, czy istnieje zapotrzebowanie rynku na dobre oprzyrządowanie do wspierania tego rodzaju przesiedleńczy.

Biorąc pod uwagę zmianę kierunku dostępu Microsoftu na dostęp do danych co dwa lata przez ponad dekadę, warto rozważyć NHibernate jako alternatywę dla Entity Framework (jeśli martwisz się o Microsoft "sunsetting" Entity Framework, tak jak oni do LinqToSql).

Answer 3

Wątpię, aby możliwa była jakaś automatyczna konwersja. Istnieje kilka różnic. Najgorszy jest sposób wywoływania procedur składowanych za pomocą skalarycznych wartości zwracanych. EntityFramework nie zwraca wartości, ale liczba wierszy dotyczy. Wymaga to zmian w twoim T-SQL. Nie można tego zrobić za pomocą żadnego szablonu. Niektóre kwerendy LINQ2SQL nie działają w EntityFramework i muszą zostać zmienione. Istnieje irytująca różnica w pluralizacji. EF stara się być tak sprytny. Tabela UserInfo jest pluralizowana jako UserInfoes, gdy L2SQL UserInfos. Tabela Osób jest pluralizowana jako Ludzie zamiast Osób. Więc musisz także zmienić te plurowanie. Jeśli korzystasz z jakiejś zaawansowanej pracy z połączeniami (nie używaj połączenia), możesz po prostu zaktualizować. DBConnection nie jest kompatybilny z EntityConnection. Musisz również przepisać tę warstwę swojej aplikacji. Mnóstwo ciężkiej pracy dla szablonu konwersji.