내가 LINQ to SQL과 친구가되었을 때 MS가 그 밑에서 깔개를 빼내는 것처럼 보입니다.
약간의 연구를 통해 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
답변
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은 죽지 않았습니다. 장담 할 수 있습니다. 죽지 않았습니다. 아무것도 사라지지 않습니다. 우리는 그렇게 한 적이 없으며 결코 그렇게하지 않을 것입니다. “라고 말했습니다.
답변
해결해야 할 질문에 대한 모호성이 있습니다.
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 게시물에 대한 몇 가지 관련 정보 .
기본 요점 은 Entity Framework가 Visual Studio 2010 및 Dot Net 4에 대한 주요 개발자 시간을 얻는 유일한 방법 이라는 ado.net 블로그의 주석 인 것으로 보입니다 .
내 대답은-DUH. 우리는 모두 이것을 알고 있습니다. Microsoft는 PDC 2007에서 LINQ to SQL이 SQL Server에 대한 다른 LINQ 스토리가 없기 때문에 SQL Server의 단기 릴리스라고 공개적으로 말했습니다. SQL Server에서만 작동합니다. LINQ to SQL 공급자를 작성할 수 없습니다. 이에 대한 모델이 없습니다. 확장이 불가능한 일회성 기술이었습니다.
Entity Framework는 Microsoft에서 LINQ 공급자를 빌드하는 유일한 방법입니다. Entity Framework는 상당히 반박적인 것으로 판명되었지만 부분적으로는 LINQ to SQL이 오늘날 더 나은 프로그래머 경험을 가지고 있다는 사실 때문이라고 생각합니다. Entity Framework는 Microsoft의 미래 ORM / 매핑 도구이기 때문에 LINQ to SQL을 포착하고 능가합니다.
편집- 내 블로그 에 이것에 대해 약간 더 자세한 글을 작성했습니다.
EDIT2 (IQueryable Provider)는 LINQ to SQL 공급자와 동일하지 않습니다. 원하는대로 IQueryable 공급자를 직접 작성할 수 있습니다. 디자이너 지원이나 모델 생성이 없습니다. LINQ to SQL 모델 생성과 관련하여 알고있는 GUI 디자이너 모델은 없습니다.
