Entity Framework와 LINQ to SQL

Entity Framework와 LINQ to SQL

---

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

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

이것은 MSDN에 대한 좋은 소개 기사입니다. LINQ to Relational Data 소개

---

빠르고 더러운 대답은

• LINQ to SQL은이를 수행하는 빠르고 쉬운 방법입니다. 즉, 더 작은 작업을 수행하는 경우 더 빨리 진행하고 더 빨리 제공 할 수 있습니다.
• Entity Framework는이를 수행 할 수있는 전면적이고 보류가없는 방법입니다. 즉, 더 큰 것을 작업하는 경우 초기에 더 많은 시간이 소요되고 개발 속도가 느리고 유연성이 높아집니다.

---

LINQ to SQL은 정말 죽었나요? InfoQ.com을위한 Jonathan Allen

Matt Warren은 [LINQ to 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는 MM 관계를 처리합니다.
• EF는 모든 ADO.NET 데이터 공급자를 대상으로 할 수 있습니다.

원래 전제는 L2S는 Rapid Development를위한 것이고 EF는 더 많은 "엔터프라이즈"n-tier 애플리케이션을위한 것이었지만, L2S는 조금 짧게 판매되고 있습니다.

---

LINQ to SQL

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

Entity Framework

1. 이기종 데이터 소스 : 많은 데이터 공급자 지원
2. 다음을 제외한 모든 새 프로젝트에 권장됩니다.
   • 작은 것 (LINQ to SQL)
   • 데이터 소스가 플랫 파일 (ADO.NET) 인 경우
3. 모델 및 매핑 파일 메타 데이터 아티팩트 프로세스를 출력 디렉터리에 복사 할 때 다시 압축하지 않고 매핑을 변경할 수 있습니다.
4. .edmx (엔티티 데이터 모델)는 다음을 포함합니다.
   • SSDL (Storage Schema Definition Language)
   • CSDL (개념적 스키마 정의 언어)
   • MSL (Mapping Specification Language)
5. One-to-one, one-to-many, many-to-one mappings between tables and classes
6. Supports inheritence:
   • TPH (Table Per Hierarchy)
   • TPT (Table Per Type)
   • TPC (Table Per Concrete Class)
7. Supports complex types
8. Code-first, Model-first, Storage-first approaches
9. Application-centric view of a database
10. Created by SQL Server team
11. Future of Microsoft Data APIs

---

See also:

• LINQ To SQL Vs Entity Framework
• Difference between LINQ to SQL and Entity Framework
• Entity Framework vs LINQ TO SQL

---

My experience with Entity Framework has been less than stellar. First, you have to inherit from the EF base classes, so say good bye to POCOs. Your design will have to be around the EF. With LinqtoSQL I could use my existing business objects. Additionally, there is no lazy loading, you have to implement that yourself. There are some work arounds out there to use POCOs and lazy loading, but they exist IMHO because EF isn't ready yet. I plan to come back to it after 4.0

---

I found a very good answer here which explains when to use what in simple words:

The basic rule of thumb for which framework to use is how to plan on editing your data in your presentation layer.

• Linq-To-Sql - use this framework if you plan on editing a one-to-one relationship of your data in your presentation layer. Meaning you don't plan on combining data from more than one table in any one view or page.

• Entity Framework - use this framework if you plan on combining data from more than one table in your view or page. To make this clearer, the above terms are specific to data that will be manipulated in your view or page, not just displayed. This is important to understand.

With the Entity Framework you are able to "merge" tabled data together to present to the presentation layer in an editable form, and then when that form is submitted, EF will know how to update ALL the data from the various tables.

There are probably more accurate reasons to choose EF over L2S, but this would probably be the easiest one to understand. L2S does not have the capability to merge data for view presentation.

---

My impression is that your database is pretty enourmous or very badly designed if Linq2Sql does not fit your needs. I have around 10 websites both larger and smaller all using Linq2Sql. I have looked and Entity framework many times but I cannot find a good reason for using it over Linq2Sql. That said I try to use my databases as model so I already have a 1 to 1 mapping between model and database.

At my current job we have a database with 200+ tables. An old database with lots of bad solutions so there I could see the benefit of Entity Framework over Linq2Sql but still I would prefer to redesign the database since the database is the engine of the application and if the database is badly designed and slow then my application will also be slow. Using Entity framework on such a database seems like a quickfix to disguise the bad model but it could never disguise the bad performance you get from such a database.

---

You can find a good comparision here:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

---

The answers here have covered many of the differences between Linq2Sql and EF, but there's a key point which has not been given much attention: Linq2Sql only supports SQL Server whereas EF has providers for the following RDBMS's:

Provided by Microsoft:

• ADO.NET drivers for SQL Server, OBDC and OLE DB

Via third party providers:

• MySQL
• Oracle
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Firebird
• Npgsql

to name a few.

This makes EF a powerful programming abstraction over your relational data store, meaning developers have a consistent programming model to work with regardless of the underlying data store. This could be very useful in situations where you are developing a product that you want to ensure will interoperate with a wide range of common RDBMS's.

Another situation where that abstraction is useful is where you are part of a development team that works with a number of different customers, or different business units within an organisation, and you want to improve developer productivity by reducing the number of RDBMS's they have to become familiar with in order to support a range of different applications on top of different RDBMS's.

---

I found that I couldn't use multiple databases within the same database model when using EF. But in linq2sql I could just by prefixing the schema names with database names.

This was one of the reasons I originally began working with linq2sql. I do not know if EF has yet allowed this functionality, but I remember reading that it was intended for it not to allow this.

---

If your database is straightforward and simple, LINQ to SQL will do. If you need logical/abstracted entities on top of your tables, then go for Entity Framework.

---

Neither yet supports the unique SQL 2008 datatypes. The difference from my perspective is that Entity still has a chance to construct a model around my geographic datatype in some future release, and Linq to SQL, being abandoned, never will.

Wonder what's up with nHibernate, or OpenAccess...

---

I think if you need to develop something quick with no Strange things in the middle, and you need the facility to have entities representing your tables:

Linq2Sql can be a good allied, using it with LinQ unleashes a great developing timing.

---

I am working for customer that has a big project that is using Linq-to-SQL. When the project started it was the obvious choice, because Entity Framework was lacking some major features at that time and performance of Linq-to-SQL was much better.

Now EF has evolved and Linq-to-SQL is lacking async support, which is great for highly scalable services. We have 100+ requests per second sometimes and despite we have optimized our databases, most queries still take several milliseconds to complete. Because of the synchronous database calls, the thread is blocked and not available for other requests.

We are thinking to switch to Entity Framework, solely for this feature. It's a shame that Microsoft didn't implement async support into Linq-to-SQL (or open-sourced it, so the community could do it).

Addendum December 2018: Microsoft is moving towards .NET Core and Linq-2-SQL isn't support on .NET Core, so you need to move to EF to make sure you can migrate to EF.Core in the future.

There are also some other options to consider, such as LLBLGen. It's a mature ORM solution that exists already a long time and has been proven more future-proof then the MS data solutions (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

---

Linq-to-SQL

It is provider it supports SQL Server only. It's a mapping technology to map SQL Server database tables to .NET objects. Is Microsoft's first attempt at an ORM - Object-Relational Mapper.

Linq-to-Entities

Is the same idea, but using Entity Framework in the background, as the ORM - again from Microsoft, It supporting multiple database main advantage of entity framework is developer can work on any database no need to learn syntax to perform any operation on different different databases

According to my personal experience Ef is better (if you have no idea about SQL) performance in LINQ is little bit faster as compare to EF reason LINQ language written in lambda.

참고URL : https://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sql