Czy LINQ to SQL nie działa?

Czy jest jakiś powód, aby nadal używać Linq do SQL, czy też lepiej jest przejść do technik ORM, takich jak EF, NHibernate itp.

Używamy Linq do SQL w nowej aplikacji dla dużych przedsiębiorstw, która będzie istnieć przez długi czas. Motywacją dla tej nowej aplikacji korporacyjnej jest to, że aplikacja została napisana zwyczajnie w języku Visual Basic, a ponieważ Microsoft zatrzymał wsparcie, byliśmy zmuszeni przepisać aplikację. Wygląda na to, że już tam jesteśmy, ale tym razem z naszym DAL (Data Access Layer).

Przeczytałem już ten artykuł , ale porównuje on jedynie słabość EF.

Jeśli już go używasz i nie napotykasz żadnych trudności, trzymałbym się tego przy istniejących projektach.

Linq2SQL jest całkiem niezłą, ale ograniczoną, ORM - jeśli chcesz zmapować swoje obiekty w bardziej złożone sposoby niż podstawowe dostarczone przez Linq2SQL, to utkniesz. Microsoft naprawił kilka błędów, kiedy pojawili się z .net 4, ale stwierdził, że nie zamierzają poświęcać zasobów na jego rozszerzenie.

Powiedziałbym, że jeśli masz dość prosty projekt, który może mieć ograniczoną żywotność, to Linq2SQL jest przyzwoitym lekkim wyborem, o ile jesteś ostrożny, aby nie ujawniać zależności od Linq2SQL w dowolnym miejscu. Na cokolwiek więcej poszedłbym z czymś innym (na przykład NHibernate lub EF), ponieważ Linq2SQL jest praktycznie ślepym zaułkiem.

Nie jest martwy, ale Microsoft koncentruje się teraz na Entity Framework.

Użyłem LINQ do SQL w małych projektach i jest całkiem przyjemny jako lekka warstwa danych i rozważę użycie go ponownie w projektach o podobnej wielkości. Sama implementacja LINQ jest naprawdę dobra, a do niedawna znacznie lepsza niż projekt LINiber firmy NHibernate. W większym projekcie, w którym korzystałem z L2S, trudno mi było wymyślić wzór jednostki pracy, z którego byłem zadowolony, ze względu na ograniczenia dotyczące klasy „DataContext” L2S. Próba wdrożenia czegoś takiego jak „Sesja na żądanie” w L2S wydaje się albo bardzo trudna, albo niemożliwa.

Nie uważałbym też L2S za prawdziwą ORM, ponieważ tak naprawdę nie daje wielu opcji mapowania. Twój projekt klasy naprawdę musi być zgodny ze schematem bazy danych (tabela dla klasy), w przeciwnym razie będzie walczył z tobą na każdym etapie. Inną rzeczą, która mi się nie podoba w L2S, jest potrzeba używania określonych typów ( EntitySeti EntityRef) do obsługi kolekcji, referencji i leniwego ładowania. Oznacza to, że nie można zachować agnostyczności modelu domeny ORM bez dodania kolejnej warstwy abstrakcji.

Innym moim problemem z L2S jest wyłączne poleganie na LINQ do generowania zapytań. Dostawca LINQ jest bardzo dobrze napisany i generalnie tworzy porządny SQL dla większości zapytań, ale mam obawy, że istnieją bardziej złożone zapytania, których nie można dobrze wyrazić za pomocą LINQ. Używając L2S, musisz w zasadzie powrócić do wywoływania procedur przechowywanych w tych przypadkach, podczas gdy (na przykład) NHibernate ma kilka interfejsów API (dostawca LINQ, QueryOver, HQL itp.), Które można wykorzystać, gdy chcesz uzyskać większą kontrolę nad generowanym SQL.

W obronie L2S przed NHibernate jest o wiele mniej kosztów ogólnych związanych z uruchomieniem projektu.

Nie jest martwy, ponieważ nadal działa, ale jeśli nie będzie dalej rozwijany, sensowne może być przejście do czegoś innego.

Jeśli jednak działa w twojej aplikacji, nie ma sensu zmieniać ze względu na zmianę.

bardziej stabilny niż martwy imho:

http://www.thinqlinq.com/default/LINQ-to-SQL-enhancements-for-2010.aspx

http://jonkruger.com/blog/2009/06/06/linq-to-sql-is-not-dead/

Przenieśli wysiłki na rzecz ulepszenia do Entity Framework, gdzie jest to naprawdę potrzebne, aby ten produkt odniósł sukces. Nie spodziewaj się nic nowego, tylko kompatybilność i naprawa błędów na linq2sql przez chwilę.

Ta strona działa z dużą ilością linq2sql, jeśli się nie mylę.

To dziwne, ale często widywałem to sformułowanie („LINQ2SQL nie żyje”) i nie jestem pewien, skąd pochodzi *. Jest tak samo martwy Windows XP. Microsoft przestał wspierać i stworzył coś nowego (i moim zdaniem lepiej), ale ludzie nadal mogą korzystać z XP, podobnie jak Linq2SQL. Wprawdzie używam Linq2SQL do tworzenia niestandardowych modułów DotNetNuke. Jednak dzięki nowym funkcjom w EF4, takim jak kodowanie-pierwsze-rozwój ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx ) trudno znaleźć powody, by trzymać się Linq2SQL. Nie widzę powodu, aby przejść i zaktualizować kod, ale w przypadku nowego kodu nie wiem, dlaczego nie chcesz używać EF4.

* Szczerze mówiąc, jestem bardzo… obsesyjny na punkcie semantyki! Przepraszam, jeśli to irytuje innych :)