문제

이제 .NET v3.5 SP1이 릴리스되었으므로(VS2008 SP1과 함께) 이제 .NET 엔터티 프레임워크에 액세스할 수 있습니다.

내 질문은 이것입니다.Entity Framework와 LINQ to SQL을 ORM으로 사용하기로 결정할 때 차이점은 무엇입니까?

내가 이해하는 바에 따르면 Entity Framework(LINQ to Entities와 함께 사용되는 경우)는 LINQ to SQL의 '큰 형제'입니까?그렇다면 어떤 이점이 있습니까?LINQ to SQL이 자체적으로 수행할 수 없는 작업은 무엇입니까?

도움이 되었습니까?

해결책

LINQ to SQL은 Microsoft SQL Server에서 사용할 수 있는 데이터베이스 테이블, 뷰, 프로세스 및 함수의 일대일 매핑만 지원합니다.비교적 잘 설계된 SQL Server 데이터베이스에 대한 빠른 데이터 액세스 구성에 사용하는 훌륭한 API입니다.LINQ2SQL은 C# 3.0 및 .Net Framework 3.5와 함께 처음 출시되었습니다.

LINQ to Entities(ADO.Net Entity Framework)는 개체 도메인 모델과 다양한 ADO.Net 데이터 공급자와의 관계에 대한 광범위한 정의를 허용하는 ORM(Object Relational Mapper) API입니다.따라서 다양한 데이터베이스 공급업체, 애플리케이션 서버 또는 프로토콜을 혼합하고 일치시켜 다양한 테이블, 소스, 서비스 등으로 구성된 개체의 집계된 매시업을 설계할 수 있습니다.ADO.Net Framework는 .Net Framework 3.5 SP1과 함께 출시되었습니다.

이것은 MSDN에 대한 좋은 소개 기사입니다.관계형 데이터에 LINQ 소개

다른 팁

내 생각에 빠르고 더러운 대답은

  • LINQ to SQL은 이를 수행하는 빠르고 쉬운 방법입니다.이는 더 빠르게 작업을 진행하고 더 작은 작업을 수행할 경우 더 빠르게 결과를 제공할 수 있음을 의미합니다.
  • Entity Framework는 이를 수행하는 전면적이고 제한 없는 방법입니다.이는 더 큰 작업을 수행할 경우 사전에 더 많은 시간이 소요되고, 개발 속도가 느려지며, 유연성이 더 높아진다는 것을 의미합니다.

LINQ to SQL은 정말 죽었나요? InfoQ.com을 위한 조나단 앨런(Jonathan Allen)

Matt Warren은 [LINQ에서 SQL]을 "존재하지 않아야 할"것으로 묘사합니다. 본질적으로, 실제 ORM이 준비 될 때까지 LINQ를 개발하는 데 도움이되는 것은 단지 입장해야했습니다.

...

Entity Framework의 규모로 인해 .NET 3.5/Visual Studio 2008 마감일을 놓치게 되었습니다.서비스 팩이라기보다는 주요 릴리스에 더 가까운 ".NET 3.5 서비스 팩 1"이라는 불행하게도 이름이 붙은 시간에 맞춰 완성되었습니다.

...

개발자는 복잡성 때문에 [ADO.NET Entity Framework]를 좋아하지 않습니다.

...

.NET 4.0부터 LINQ to Entities는 LINQ to 관계형 시나리오에 권장되는 데이터 액세스 솔루션이 될 것입니다.

@lars가 게시한 기사에는 여러 가지 명백한 차이점이 설명되어 있지만 짧은 대답은 다음과 같습니다.

  • L2S는 긴밀하게 결합되어 있습니다. 개체 속성은 데이터베이스의 특정 필드에 연결되거나 더 정확하게는 특정 데이터베이스 스키마에 개체 매핑됩니다.
  • L2S는 (내가 아는 한) SQL Server에서만 작동합니다.
  • EF에서는 단일 클래스를 여러 테이블에 매핑할 수 있습니다.
  • EF는 M-M 관계를 처리합니다.
  • EF는 모든 ADO.NET 데이터 공급자를 대상으로 할 수 있습니다.

원래 전제는 L2S가 신속한 개발을 위한 것이고 EF는 더 많은 "엔터프라이즈" n 계층 애플리케이션을 위한 것이지만 L2S를 약간 부족하게 판매합니다.

LINQ에서 SQL로

  1. 동종 데이터 소스:SQL 서버
  2. 데이터 구조가 잘 설계된 소규모 프로젝트에만 권장됩니다.
  3. SqlMetal.exe를 사용하여 다시 컴파일하지 않고도 매핑을 변경할 수 있습니다.
  4. .dbml(데이터베이스 마크업 언어)
  5. 테이블과 클래스 간의 일대일 매핑
  6. 지원 TPH 계승
  7. 복합 유형을 지원하지 않습니다.
  8. 스토리지 우선 접근 방식
  9. 데이터베이스의 데이터베이스 중심 보기
  10. C# 팀에서 작성함
  11. 지원되지만 추가 개선 계획은 없음

엔터티 프레임워크

  1. 이기종 데이터 소스: 다양한 데이터 제공업체 지원
  2. 다음을 제외한 모든 새 프로젝트에 권장됩니다.
    • 작은 것(LINQ to SQL)
    • 데이터 소스가 플랫 파일(ADO.NET)인 경우
  3. 모델 및 매핑 파일 설정 시 재컴파일 없이 매핑 변경 가능 메타데이터 아티팩트 프로세스를 출력 디렉터리에 복사
  4. .edmx(엔터티 데이터 모델)에는 다음이 포함됩니다.
    • SSDL(스토리지 스키마 정의 언어)
    • CSDL(개념적 스키마 정의 언어)
    • MSL(매핑 사양 언어)
  5. 테이블과 클래스 간의 일대일, 일대다, 다대일 매핑
  6. 상속을 지원합니다:
    • TPH(계층별 테이블)
    • TPT(유형별 테이블)
    • TPC(콘크리트 등급별 테이블)
  7. 복합 유형 지원
  8. 코드 우선, 모델 우선, 스토리지 우선 접근 방식
  9. 데이터베이스의 애플리케이션 중심 보기
  10. SQL Server 팀에서 작성
  11. Microsoft 데이터 API의 미래

또한보십시오:

Entity Framework에 대한 나의 경험은 그다지 훌륭하지 않았습니다.먼저 EF 기본 클래스에서 상속해야 하므로 POCO는 이제 안녕입니다.디자인은 EF를 중심으로 이루어져야 합니다.LinqtoSQL을 사용하면 기존 비즈니스 개체를 사용할 수 있습니다.게다가 지연 로딩도 없으므로 직접 구현해야 합니다.POCO 및 지연 로딩을 사용하는 몇 가지 해결 방법이 있지만 EF가 아직 준비되지 않았기 때문에 IMHO가 존재합니다.4.0 이후에 다시 할 생각이에요

아주 좋은 답을 찾았어요 여기 what을 언제 사용해야 하는지를 간단한 단어로 설명합니다.

프레임 워크를 사용하는 기본 규칙은 프레젠테이션 계층에서 데이터를 편집하는 방법입니다.

  • Linq-SQL -프레젠테이션 계층에서 데이터의 일대일 관계를 편집 할 계획이라면이 프레임 워크를 사용하십시오.하나의 뷰 나 페이지에서 둘 이상의 테이블에서 데이터를 결합 할 계획이 없다는 것을 의미합니다.

  • 엔터티 프레임워크 - 뷰 또는 페이지에서 둘 이상의 테이블에서 데이터를 결합 할 계획이라면이 프레임 워크를 사용하십시오.이를 명확하게하기 위해 위의 용어는 표시된 것이 아니라보기 나 페이지에서 조작 될 데이터에만 해당됩니다.이것은 이해하는 것이 중요합니다.

엔티티 프레임 워크를 사용하면 표정화 된 데이터를 함께 "병합"하여 편집 가능한 양식으로 프레젠테이션 계층에 제시 할 수 있으며, 해당 양식이 제출되면 EF는 다양한 테이블에서 모든 데이터를 업데이트하는 방법을 알게됩니다.

L2보다 EF를 선택 해야하는 더 정확한 이유가있을 것입니다. 그러나 이것은 아마도 가장 이해하기 쉬운 것일 것입니다.L2S에는 View 프레젠테이션을 위해 데이터를 병합하는 기능이 없습니다.

내 생각에는 Linq2Sql이 귀하의 요구 사항에 맞지 않으면 데이터베이스가 상당히 방대하거나 매우 잘못 설계되었다는 것입니다.Linq2Sql을 사용하는 크고 작은 웹사이트가 약 10개 정도 있습니다.나는 Entity Framework를 여러 번 보았지만 Linq2Sql을 통해 그것을 사용해야 할 타당한 이유를 찾을 수 없습니다.즉, 데이터베이스를 모델로 사용하려고 하므로 이미 모델과 데이터베이스 간에 1:1 매핑이 있습니다.

현재 직장에는 200개 이상의 테이블이 있는 데이터베이스가 있습니다.잘못된 솔루션이 많은 오래된 데이터베이스이므로 Linq2Sql에 비해 Entity Framework의 이점을 볼 수 있지만 데이터베이스가 응용 프로그램의 엔진이고 데이터베이스가 잘못 설계되고 느린 경우 내 응용 프로그램보다 데이터베이스를 다시 디자인하는 것을 선호합니다. 또한 느려질 것입니다.그러한 데이터베이스에서 Entity 프레임워크를 사용하는 것은 잘못된 모델을 위장하는 빠른 수정처럼 보이지만 그러한 데이터베이스에서 얻는 나쁜 성능을 결코 위장할 수는 없습니다.

여기에 있는 답변에서는 Linq2Sql과 EF 간의 많은 차이점을 다루었지만 많은 관심을 받지 못한 핵심 사항이 있습니다.Linq2Sql은 SQL Server만 지원하는 반면 EF에는 다음 RDBMS에 대한 공급자가 있습니다.

마이크로소프트에서 제공:

  • SQL Server, OBDC 및 OLE DB용 ADO.NET 드라이버

제3자 제공업체를 통해:

  • MySQL
  • 신탁
  • DB2
  • 비스타DB
  • SQLite
  • 포스트그레SQL
  • 인포믹스
  • U2
  • 사이베이스
  • 시너지엑스
  • 파이어버드
  • Npgsql

몇 가지 예를 들자면.

이는 EF를 관계형 데이터 저장소에 대한 강력한 프로그래밍 추상화로 만듭니다. 즉, 개발자는 기본 데이터 저장소에 관계없이 작업할 수 있는 일관된 프로그래밍 모델을 갖게 됩니다.이는 광범위한 일반 RDBMS와 상호 운용되도록 하려는 제품을 개발하는 상황에서 매우 유용할 수 있습니다.

추상화가 유용한 또 다른 상황은 여러 고객 또는 조직 내의 다양한 비즈니스 단위와 협력하는 개발 팀의 일원이고 RDBMS의 수를 줄여 개발자 생산성을 향상시키려는 경우입니다. 다양한 RDBMS 위에 다양한 애플리케이션을 지원하는 데 익숙합니다.

EF를 사용할 때 동일한 데이터베이스 모델 내에서 여러 데이터베이스를 사용할 수 없다는 것을 발견했습니다.하지만 linq2sql에서는 스키마 이름 앞에 데이터베이스 이름을 붙이면 됩니다.

이것이 제가 원래 linq2sql로 작업을 시작한 이유 중 하나였습니다.EF가 아직 이 기능을 허용했는지는 모르겠지만, 이를 허용하지 않도록 의도되었다는 내용을 읽은 기억이 납니다.

데이터베이스가 간단하고 단순하다면 LINQ to SQL이 적합합니다.테이블 위에 논리적/추상적 엔터티가 필요한 경우 Entity Framework를 선택하세요.

둘 다 아직 고유한 SQL 2008 데이터 유형을 지원하지 않습니다.내 관점과의 차이점은 Entity는 향후 릴리스에서 내 지리적 데이터 유형을 중심으로 모델을 구성할 기회가 여전히 있고 Linq to SQL은 포기되지 않는다는 것입니다.

nHibernate나 OpenAccess에 무슨 일이 일어나고 있는지 궁금합니다...

중간에 이상한 일이 없이 빠르게 무언가를 개발해야 하고 테이블을 나타내는 엔터티를 갖는 기능이 필요하다고 생각합니다.

Linq2Sql은 좋은 동맹이 될 수 있으며, LinQ와 함께 사용하면 훌륭한 개발 타이밍을 얻을 수 있습니다.

저는 Linq-to-SQL을 사용하는 대규모 프로젝트를 가진 고객을 위해 일하고 있습니다.프로젝트가 시작되었을 때 그 당시 Entity Framework에는 일부 주요 기능이 부족했고 Linq-to-SQL의 성능이 훨씬 좋았기 때문에 당연한 선택이었습니다.

이제 EF는 발전했고 Linq-to-SQL에는 확장성이 뛰어난 서비스에 적합한 비동기 지원이 부족합니다.때때로 초당 100개 이상의 요청이 발생하며 데이터베이스를 최적화했음에도 불구하고 대부분의 쿼리를 완료하는 데 여전히 몇 밀리초가 걸립니다.동기 데이터베이스 호출로 인해 스레드가 차단되어 다른 요청에 사용할 수 없습니다.

우리는 이 기능만을 위해서 Entity Framework로 전환하려고 생각하고 있습니다.Microsoft가 Linq-to-SQL에 비동기 지원을 구현하지 않은 것은 유감스러운 일입니다(또는 커뮤니티에서 이를 수행할 수 있도록 오픈 소스로 제공).

2018년 12월 부록: Microsoft는 .NET Core로 전환하고 있으며 Linq-2-SQL은 .NET Core에서 지원되지 않으므로 나중에 EF.Core로 마이그레이션하려면 EF로 이동해야 합니다.

다음과 같이 고려해야 할 다른 옵션도 있습니다. LLBLGen.이는 이미 오랫동안 존재해 왔으며 MS 데이터 솔루션(ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core)보다 미래 지향성이 더 뛰어난 것으로 입증된 성숙한 ORM 솔루션입니다.

LINQ to SQL과 Entity Framework는 표면적으로 유사해 보입니다.둘 다 데이터 모델을 사용하여 데이터베이스에 대해 LINQ 쿼리를 제공합니다.

LINQ에서 SQL은 LINQ 프로젝트에서 발전하여 언어 개발과 함께 팀에서 나왔지만 엔티티 프레임 워크는 데이터 프로그래밍 가능성 팀의 프로젝트였으며 엔터티 SQL 언어에 중점을 두었습니다.Microsoft는 LINQ to SQL을 중단할 의도가 전혀 없습니다.

LINQ to SQL은 여전히 ​​ADO.NET의 일부이지만 Entity 프레임워크에는 별도의 API가 있습니다.엔터티 프레임워크는 LINQ to SQL의 상위 버전입니다. 엔터티 프레임워크는 엔터티 데이터 모델을 사용하여 애플리케이션과 데이터 저장소를 연결합니다.개념적 스키마의 정의뿐만 아니라 데이터베이스와 상호 작용하는 데 필요한 데이터베이스 스키마 정보, 그리고 마지막으로 두 가지에 연결되는 매핑 스키마를 제공하는 것이 엔터티 데이터 모델(EDM)입니다.

다음은 Entity Framework(엔티티 데이터 모델)에서 수행되는 몇 가지 작업입니다.

• 모델에서 클래스를 자동으로 생성하고 모델이 변경 될 때마다 해당 클래스를 동적으로 업데이트합니다.

• 개발자가 데이터베이스와 상호 작용하기 위해 많은 코드를 작성해야 하는 부담을 느끼지 않도록 모든 데이터베이스 연결을 관리합니다.

• 데이터베이스가 아닌 모델을 쿼리하기 위한 일반적인 쿼리 구문을 제공하고 이러한 쿼리를 데이터베이스가 이해할 수 있는 쿼리로 변환합니다.

• 모델 객체가 응용 프로그램에서 사용될 때 모델의 변경 사항을 추적하는 메커니즘을 제공하고 데이터베이스의 업데이트를 처리합니다.

Linq-SQL

SQL Server만 지원하는 공급자입니다.SQL Server 데이터베이스 테이블을 .NET 개체에 매핑하는 매핑 기술입니다.ORM(Object-Relational Mapper)에 대한 Microsoft의 첫 번째 시도입니다.

Linq-엔티티

같은 아이디어이지만 백그라운드에서 Entity Framework를 ORM으로 사용합니다. 다시 Microsoft에서 제공하는 여러 데이터베이스를 지원하는 엔터티 프레임워크의 주요 장점은 개발자가 다른 데이터베이스에서 작업을 수행하기 위해 구문을 배울 필요 없이 모든 데이터베이스에서 작업할 수 있다는 것입니다.

내 개인적인 경험에 따르면 EF가 더 좋습니다 (SQL에 대해 전혀 모르는 경우) LINQ의 성능은 Lambda에서 작성된 EF 이유 LINQ 언어에 비해 약간 빠릅니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top