programing

엔티티 프레임워크 VS LINQ에서 SQL로의 VS ADO.저장 프로시저를 사용하는 NET?

newnotes 2023. 4. 10. 22:14
반응형

엔티티 프레임워크 VS LINQ에서 SQL로의 VS ADO.저장 프로시저를 사용하는 NET?

다음과 같은 관점에서 각 항목을 어떻게 평가하십니까?

  1. 성능
  2. 개발 속도
  3. 깔끔하고 직관적이며 유지 보수 가능한 코드
  4. 유연성
  5. 전반적으로.

SQL이 마음에 들어서 항상 ADO의 열렬한 팬이었습니다.NET 및 스토어드 프로시저입니다만, 최근, Linkq to SQL을 사용하고 있었습니다.Data Access 레이어를 쓰는 속도가 너무 빨라서 놀랐습니다.Linq to SQL 또는 EF 중 하나를 제대로 이해하기로 했습니다.아니면 둘 다?

이 기술들 중 제 연구 시간을 낭비하는 큰 결함이 없다는 것을 확인하고 싶습니다.예를 들어 퍼포먼스는 형편없고, 심플한 앱으로서는 훌륭하지만, 그 정도밖에 할 수 없습니다.

업데이트: ORM VS SP가 아닌 EF VS L2S VS SP에 집중할 수 있습니까?저는 주로 EF VS L2S에 관심이 있습니다.하지만 플레인 SQL은 제가 잘 알고 있는 것이기 때문에 스토어드 프로세서와 비교하고 싶습니다.

먼저 새로운 프로젝트를 시작할 경우 Entity Framework("EF")를 사용하십시오. 이제 훨씬 더 나은 SQL(Linq에서 SQL로 더 유사함)을 생성하고, 유지보수가 더 쉽고 강력한 SQL("L2S")을 사용할 수 있습니다.의 릴리스 시점.NET 4.0, Linkq to SQL은 구식 기술이라고 생각합니다.MS는 L2S 개발을 더 이상 지속하지 않는 것에 대해 매우 개방적이었다.

1) 퍼포먼스

이것은 대답하기 어렵다.대부분의 단일 엔티티 운영(CRUD)에서는 세 가지 기술 모두에서 거의 동등한 성능을 얻을 수 있습니다.EF 및 Linq to SQL을 최대한 활용하려면 이러한 SQL의 작동 방식을 알아야 합니다.쿼리 폴링과 같은 대량 작업의 경우 EF/L2S에서 운영 주체 쿼리를 "컴파일"하도록 하여 프레임워크가 SQL을 지속적으로 재생성하지 않아도 되며, 그렇지 않으면 확장성 문제가 발생할 수 있습니다.(편집 참조)

대량의 데이터를 갱신하는 대량 업데이트의 경우 업데이트를 수행하기 위해 유선상에서 데이터를 ORM에 집약할 필요가 없기 때문에 원시 SQL 또는 저장 프로시저는 항상 ORM 솔루션보다 성능이 우수합니다.

2) 개발 속도

대부분의 시나리오에서 EF는 개발 속도에 관한 한 SQL/스토어드 프로세서를 사용하지 않습니다.EF 설계자는 모델이 변경될 때(요청 시) 데이터베이스에서 업데이트할 수 있으므로 개체 코드와 데이터베이스 코드 간의 동기화 문제가 발생하지 않습니다.ORM을 사용하지 않는 경우는 갱신을 하지 않는 보고서/대시보드 타입의 어플리케이션을 실행하고 있는 경우나 데이터베이스 상에서 미가공 데이터 유지보수 조작만을 실시하기 위한 어플리케이션을 작성하는 경우뿐입니다.

3) 깔끔/유지관리 가능한 코드

EF는 SQL/sprocs보다 훨씬 뛰어납니다.관계가 모델링되기 때문에 코드의 결합은 비교적 빈도가 낮습니다.엔티티의 관계는 대부분의 쿼리에서 독자에게 거의 자명합니다.데이터에 실제로 무슨 일이 일어나고 있는지를 이해하기 위해 계층 간 디버깅 또는 여러 SQL/중간 계층을 거쳐야 하는 것보다 더 나쁜 것은 없습니다.EF는 매우 강력한 방식으로 데이터 모델을 코드에 포함합니다.

4) 유연성

저장된 Proc와 원시 SQL은 더 "유연성"이 높습니다.sprocs 및 SQL을 사용하여 특정 사례에 대해 더 빠른 쿼리를 생성할 수 있으며, 및 ORM보다 더 쉽게 네이티브 DB 기능을 활용할 수 있습니다.

5) 전체

ORM 선택과 스토어드 프로시저 사용이라는 잘못된 이분법에 빠지지 마십시오.같은 어플리케이션으로 둘 다 사용할 수 있으며, 아마 사용하는 것이 좋습니다.대규모 운영은 스토어드 프로시저 또는 SQL(실제로 EF에서 호출 가능)로 진행해야 하며, CRUD 운영 및 대부분의 중간 계층 요구사항에 EF를 사용해야 합니다.보고서 작성에 SQL을 사용할 수도 있습니다.나는 그 이야기의 교훈이 항상 그래왔던 것과 같다고 생각한다.작업에 적합한 도구를 사용하십시오.하지만 한마디로 요즘 EF는 매우 우수합니다(현재).NET 4.0).실시간으로 읽고 자세히 이해하면 놀라운 고성능 앱을 쉽게 만들 수 있습니다.

편집: EF 5는 자동 컴파일된 LINQ 쿼리를 통해 이 부분을 약간 단순화하지만, 실제로 대용량의 쿼리를 사용하려면 실제 환경에 가장 적합한 항목을 테스트하고 분석해야 합니다.

저장 프로시저:

(+)

  • 뛰어난 유연성
  • SQL에 대한 완전한 제어
  • 최고의 퍼포먼스

(-)

  • SQL에 대한 지식 필요
  • 저장 프로시저가 소스 제어를 벗어났습니다.
  • 동일한 테이블 및 필드 이름을 지정하면서 상당한 양의 "반복"을 수행합니다.DB 엔티티의 이름을 변경한 후 해당 엔티티에 대한 참조가 누락되면 응용 프로그램이 중단될 가능성이 높습니다.
  • 개발 속도가 느리다

ORM:

(+)

  • 급속한 발전
  • 데이터 액세스 코드가 소스 제어 중입니다.
  • DB 변경에서 격리됩니다.이 경우 모델/매핑은 한 곳에서만 업데이트하면 됩니다.

(-)

  • 퍼포먼스가 저하될 수 있다
  • ORM이 생성하는 SQL에 대한 제어가 없거나 거의 없습니다(효율적이지 않거나 버그가 더 심할 수 있습니다).개입하여 커스텀 스토어드 프로시저로 교체해야 할 수 있습니다.이로 인해 코드가 복잡해집니다(일부 LINQ는 코드, 일부 SQL은 코드 및/또는 DB는 소스 제어를 벗어남).
  • 어떠한 추상화라도, 「고급」개발자를 양산할 수 있기 때문에, 후드에서 어떻게 기능하는지는 전혀 알 수 없습니다.

일반적으로 유연성이 뛰어난 것과 많은 시간을 낭비하는 것 사이의 균형은 할 수 있는 일에 제약을 받는 것과 동시에 매우 신속하게 처리되는 것입니다.

이 질문에 대한 일반적인 답은 없습니다.이건 성스러운 전쟁의 문제야.또, 프로젝트와 고객의 요구에 따라서도 다릅니다.당신에게 가장 적합한 것을 고르세요.

기본적으로 O/RM과 수기 SQL의 비교입니다.

ORM 또는 플레인 SQL 사용

다른 O/RM 솔루션도 있습니다.L2S만이 아닙니다(NHibernate, Active Record).

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

구체적인 질문에 대처하기 위해:

  1. O/RM 솔루션의 품질에 따라 다르지만 L2S는 SQL 생성에 매우 능숙합니다.
  2. 프로세스를 파악한 후 O/RM을 사용하는 것이 보통 훨씬 빠릅니다.
  3. 또한 일반적으로 코드는 훨씬 깔끔하고 유지보수가 용이합니다.
  4. 물론 스트레이트 SQL을 사용하면 유연성이 향상되지만 대부분의 O/RM은 가장 복잡한 쿼리를 제외한 모든 작업을 수행할 수 있습니다.
  5. 전체적으로 O/RM을 사용하는 것이 좋습니다.유연성 손실은 무시할 수 있습니다.

LINQ-to-SQL은 매우 사용하기 쉬운 뛰어난 테크놀로지이며, 대체로 백엔드에 대해 매우 우수한 쿼리를 생성합니다.LINQ-to-EF는 이를 대체할 예정이었지만, 지금까지 매우 사용하기 불편하여 SQL이 크게 저하되었습니다.현재 상황은 모르겠지만 마이크로소프트는 L2S의 장점을 모두 L2EF로 이행하겠다고 약속했기 때문에 지금은 모든 것이 개선되었을지도 모릅니다.

개인적으로 저는 ORM 툴을 매우 싫어하기 때문에(자세한 내용은 여기를 참조), L2EF를 선호할 이유는 없습니다.L2S는 데이터 액세스 레이어에서 필요한 모든 것을 제공하기 때문입니다.실제로 수작업으로 만든 매핑이나 상속 모델링과 같은 L2S 기능은 전혀 불필요한 복잡성을 가중시킨다고 생각합니다.하지만 그건 저뿐입니다.;-)

스토어드 프로시저의 파워와 퍼포먼스, 그리고 엔티티 프레임워크와 같은 툴이 제공하는 신속한 개발이라면 완전히 새로운 접근방식을 고려해야 합니다.

소규모 프로젝트에서 SQL+를 시승해 본 적이 있는데, 정말 특별한 일입니다.기본적으로 SQL 루틴에 코멘트에 필요한 양을 추가하고, 이러한 코멘트는 코드 생성기에 명령을 제공합니다. 코드 생성기는 실제 SQL 루틴을 기반으로 매우 훌륭한 객체 지향 클래스 라이브러리를 구축합니다.일종의 엔티티 프레임워크와 반대입니다.

입력 파라미터는 입력 객체의 일부가 되고 출력 파라미터와 결과세트는 출력 객체의 일부가 되며 서비스 컴포넌트는 메서드 호출을 제공한다.

스토어드 프로시저를 사용하면서도 신속한 개발이 필요한 경우 이 항목을 참조하십시오.

언급URL : https://stackoverflow.com/questions/2698151/entity-framework-vs-linq-to-sql-vs-ado-net-with-stored-procedures

반응형