Programing

LINQ to SQL은 Dead 또는 Alive입니까?

lottogame 2020. 8. 28. 07:50
반응형

LINQ to SQL은 Dead 또는 Alive입니까?


내가 LINQ to SQL과 친구가되었을 때 MS가 그 밑에서 깔개를 빼내는 것처럼 보입니다.

http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx

약간의 연구를 통해 EF는 단순한 작업에 너무 과잉입니다. 하지만이 발표 이후에도 LINQ to SQL을 계속 사용할 필요가 있습니까?

LINQ to SQL의 미래를 넘어서 이것은 일반적으로 잘못된 신호를 보내지 않습니까? MS가 벽에 비트를 던지는 속도를 고려할 때 새로운 비트를 일찍 사용하는 것이 합리적입니까? (그리고 그것은 친절합니다. LINQ to SQL의 경우 거의 이르지 않습니다!).

LINQ to SQL 작업을 위해 SubSonic으로 향하고 있다고 생각합니다!

업데이트 : 몇 가지 새로운 의견 :

http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx


1) Linq-to-SQL은 이미 .net 프레임 워크의 일부이므로 "죽일"수 없습니다. 그들이 할 수있는 일은 기능 추가를 중단하는 것입니다. 그렇다고 이미 L2S를 사용하고있는 수천 명의 개발자가 확장하고 개선하는 것을 막지는 못합니다. 일부 핵심 영역은 다루기가 까다 롭지 만 이미 견고하며 누락 된 디자이너 기능을 쉽게 추가 할 수 있습니다 .

2) PDC EF 세션 중 하나는 EFv1 실패에서 몇 가지 교훈을 배웠으며 이제 L2S의 많은 장점을 EF에 복사하여 붙여넣고 새로운 EF 항목 인 척하고 있음을 보여줍니다. 즉, L2S 버전 2가 EF "재 라벨링"되었습니다.

3) LINQ (Language Integrated Query)는 슬라이스 아이스크림 이후 가장 좋은 방법이며 L2S (Linq에서 개체로, Linq에서 엔터티로, Linq에서 XML로, Linq에서 Anything으로) 이외의 많은 것들과 함께 사용할 수 있습니다. ). 따라서 DP 그룹의 [광범위한 대중] L2S 채택 자들을 [덜 인기 있고 현재 결함이있는] Entity Framework로 강제 적용하려는 시도는 Linq를 배우지 않을 이유가 아닙니다.

또한 다음 스레드 (Tim의 블로그 게시물을 부분적으로 트리거 한 것으로 생각됩니다)를 참조하십시오 . http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1

업데이트 1 : Roger Jennings의 Visual Studio Magazine 커버 스토리 2008 년 12 월호는 일부 L2S와 EF 비교를 통해이 주제에 대해 잘 읽었습니다. http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583

업데이트 2 : Anders Hejlsberg는 Redmond Developer News 에서 " LINQ to SQL은 죽지 않았습니다. 장담 할 수 있습니다. 죽지 않았습니다. 아무것도 사라지지 않습니다. 우리는 그렇게 한 적이 없으며 결코 그렇게하지 않을 것입니다. "라고 말했습니다.

http://reddevnews.com/blogs/weblog.aspx?blog=3016


해결해야 할 질문에 대한 모호성이 있습니다.

LINQ! = LINQ to SQL

LINQ 기술과 공급자는 다양합니다.

  • Linq에서 SQL로;
  • Linq to Entities;
  • Linq to Objects;
  • Linq에서 XML로;

... 그리고 그것들은 Microsoft에서 제공 한 것입니다. NHibernate를 포함하여 MS가 아닌 공급자도 있습니다.

링크 한 블로그 게시물은 Linq to SQL에 대해서만 설명합니다.

LINQ의 주요 이점은 하나의 쿼리 구문을 학습 및 사용하고 여러 기술에서 재사용 할 수 있다는 것입니다.

이 점을 감안할 때 "Linq To SQL"에 대한 미래의 부족으로 인식되는 것은 무관하다고 생각합니다. LINQ 쿼리를 작성하는 데 습득 한 기술은 앞으로 다른 도구로 이전 될 수 있기 때문입니다.


우리는 LINQ to SQL을 죽이는 것이 아닙니다. 우리는 EF를 최적화하고 있지만 LINQ to SQL은 확실히 죽지 않습니다. :)

-Scott / Microsoft.


Linq (System.Linq.Enumerable 및 System.Linq.Queryable)를 배워야 할뿐만 아니라 .net 언어에 대한 프로그래밍 언어 향상을 배워야합니다.

C # 3.0에서는 다음이 포함됩니다.

  • 확장 메서드 (첫 번째 매개 변수에 this 키워드가있는 정적 메서드)
  • 컴파일러 유추 유형 (var)
  • Lambda 구문 (컨텍스트에 따라 익명 메서드 또는 표현식 생성)
  • 이니셜 라이저
  • 속성 기본 구현 (줄임말)

여기에서 자세한 내용을 읽어보십시오 .


VB 9.0에는 인라인 XML 마법과 다른 많은 것들이 있습니다 (많은 것들이 위의 C # 목록과 유사합니다).

여기에서 자세한 내용을 읽어보십시오 .


나는 솔직히 그 기사에서 link2sql이 죽었다는 것을 읽은 곳을 이해하지 못합니다.

링크 한 블로그 게시물에 다음과 같이 표시됩니다.

우리는 LINQ to SQL에 대한 고객의 의견을 듣고 있으며 커뮤니티에서받은 피드백을 기반으로 제품을 계속 발전시킬 것입니다.

나를 위해 이것은 LINQ to SQL과 같은 읽기가 향후 개발되고 지원 될 것입니다. 왜 죽었다고 생각하십니까?


물론, LINQ to SQL, LINQ to Entities 및 LINQ to [insert 3rd Party ORM] 중에서 선택하면 소프트웨어 개발자가 선택할 수있는 데이터 액세스 계층 방법론의 완벽하게 건강한 에코 시스템이 제공됩니다. NHibernate, LLBLGen 및 심지어 Subsonic (LINQ 공급자를 제공 할 것인지 확실하지 않음)과 같은 타사 공급자는 확실히 경쟁을 더 좋고 흥미롭게 만들 것입니다.

즉, Microsoft가 LINQ to SQL을 포기하는 것은 전적으로 슬픈 일입니다. 특히 StackOverflow가 그 위에 구축되어 있기 때문에 특히 좋은 추종자가 있기 때문입니다.


그것에 대한 흥미로운 블로그 게시물. 그리고 Stackoverflow 게시물에 대한 몇 가지 관련 정보 .

The basic gist appears to be comments made on the ado.net blog that state the Entity Framework is the only thing getting major developer time for Visual Studio 2010 and Dot Net 4.

My response is - DUH. We have all known this. Microsoft said publicly back at the PDC 2007 that LINQ to SQL was a short term release for SQL Server because there was no other LINQ story to SQL Server. It only works with SQL Server. You cannot write a LINQ to SQL provider - there is no model for it. It was a one off technology, not extensible.

The Entity Framework is the ONLY way from Microsoft to build a LINQ Provider. The Entity Framework has turned out to be quite contreversial, but I think that is partly due to the fact that LINQ to SQL has a better programmer experience today. Entity Framework will catch and surpass LINQ to SQL because it is the ORM/Mapping tool of the future from Microsoft.

EDIT - I just did a slightly more detailed write up about this on my blog

EDIT2 - IQueryable Provider - is NOT the same thing as a LINQ to SQL provider. You can write your own IQueryable Provider for anything you like. You get no designer support or model generation. There is no gui designer model that I know of for tying into LINQ to SQL model generation.


I guess I don't really see the problem here. From the article you've linked:

We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.

Am I missing something? What gives the impression of LINQ to SQL being dead on arrival?


Scott Guthrie told me they would not kill LINQ to SQL:

Post at LINQDev.com


Anyone remember VB6? Whether you personally loathe it or love it, Microsoft sold millions of copies, and businesses spent millions of dollars writing millions of lines of VB6. What happened next?

  • Well, Microsoft do still support VB6 (kind of - not the IDE).
  • And Microsoft still say that they are listening to VB6 customers even now (in September 09).
  • But are VB6 customers happy? Not since 2002, 4 years after VB6 launched.
  • Why not? The upgrade paths for your code investment to the replacement technology, VB.Net, are expensive.

So just consider that lesson. To me, it seems LinqToSQL support will be rather grudging. They are obliged to support it because it is in the current .NET framework. But will it be in .NET 5, 6, 7...? Just think about how much that matters to you (for all I know, it doesn't matter to you at all).


Maybe you should not bother learning Linq to SQL, but there's still the Entities Linq that they will keep.


See also http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx and the the comments there


Its obvious that 2 ORMs is one to many in Microsoft's toolbox, but to me it seems to be the wrong framework has been chosen for all the wrong reasons. The fact that the C# team did the job that the ADO.NET team was supposed to do in lot shorter time and did the job way better is tough to swallow for the ado.net team. Not that I know the internal workings of the 2 frameworks but I think it would be a lot faster to upgrade the shortcomings linq2sql has to the entity framework.

There seem to be too much politics involved and I think this is really going to hurt the asp.net reputation, since I have no trust in that Entity framework will give us a equally user friendly experience as Linq2sql. The ado.net team could also learn some communication skills from the asp.net mvc team as the clarifications on the problem is at best vague.

It would be fun learning what Scott Gu and his MVC team stands here as most of their examples are using Linq2Sql.


It was always a bit weird that with Linq 2 Sql and Entity Framework there was large areas of overlap. I think the only reason L2S only ever made it into the .NET 3.5 release was because there was a large doubt that EF would ever see the light of day. Now that EF1 is out, all be it a very rough v1, there was no need for L2S anymore.


(no, StingyJack, LINQ to SQL does not use the entity framework)

Anyway, I wouldn't worry. Tim states that they are listening to customers regarding LINQ to SQL. Judging from the enthusiasm I've seen for L2S, the customers (that's us) will speak their minds.

And, as KristoferA points out, they can't actually 'kill' L2S, only freeze it. And L2S, once polished, doesn't really require much further development. With the L2S provider in place, any advances in LINQ should be available in L2S as well. So the choice will still be ours.


The next version of Windows Phone 7, codename Mango, includes a SQL Server Compact Edition accessible via Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/

참고URL : https://stackoverflow.com/questions/252683/is-linq-to-sql-dead-or-alive

반응형