다음과 같은 관점에서 각각을 어떻게 평가 하시겠습니까?
- 공연
- 개발 속도
- 깔끔하고 직관적이며 유지 보수가 쉬운 코드
- 적응성
- 사무용 겉옷
저는 SQL을 좋아해서 항상 ADO.NET과 저장 프로 시저의 열렬한 팬 이었지만 최근 Linq와 SQL을 함께 사용하여 DataAccess 계층을 얼마나 빨리 작성하고 지출하기로 결정했는지에 대해 놀랐습니다. Linq to SQL 또는 EF를 실제로 이해하는 시간이 있습니까?
연구 시간을 쓸모 없게 만드는 이러한 기술에는 큰 결함이 없다는 것을 확인하고 싶습니다. 예를 들어 성능은 끔찍합니다. 간단한 앱에서는 멋지지만 지금까지만 사용할 수 있습니다.
업데이트 :
ORM VS SP 대신 EF VS L2S VS SP에 집중할 수 있습니다. 나는 주로 EF VS L2S에 관심이 있습니다. 그러나 평범한 SQ1이 내가 많이 알고있는 것이므로 저장된 procs와 비교해보고 싶어합니다.
답변
먼저, 새 프로젝트를 시작하는 경우 Entity Framework ( “EF”)를 사용하십시오. 이제 Linq to SQL보다 훨씬 더 나은 SQL을 생성하고 Linq to SQL ( ” L2S “). .NET 4.0 릴리스부터 Linq to SQL은 쓸모없는 기술이라고 생각합니다. MS는 L2S 개발을 계속하지 않는 것에 대해 매우 개방적이었습니다.
1) 성능
대답하기가 까다 롭습니다. 대부분의 단일 엔터티 작업 ( CRUD )의 경우 세 기술 모두에서 동등한 성능을 얻을 수 있습니다. EF와 Linq to SQL을 최대한 활용하기 위해 어떻게 작동하는지 알아야합니다. 폴링 쿼리와 같은 대량 작업의 경우 프레임 워크가 지속적으로 SQL을 재생성 할 필요가 없도록 EF / L2S가 엔티티 쿼리를 “컴파일”하도록하거나 확장 성 문제가 발생할 수 있습니다. (편집 참조)
대량의 데이터를 업데이트하는 대량 업데이트의 경우 업데이트를 수행하기 위해 유선으로 데이터를 마샬링 할 필요가 없으므로 원시 SQL 또는 저장 프로 시저가 항상 ORM 솔루션보다 성능이 우수합니다.
2) 개발 속도
대부분의 시나리오에서 EF는 개발 속도와 관련하여 알몸의 SQL / 저장된 프로세스를 날려 버릴 것입니다. EF 디자이너는 모델이 변경 될 때 (요청시) 데이터베이스에서 모델을 업데이트 할 수 있으므로 객체 코드와 데이터베이스 코드간에 동기화 문제가 발생하지 않습니다. ORM 사용을 고려하지 않을 유일한 시간은 업데이트를 수행하지 않는보고 / 대시 보드 유형 응용 프로그램을 수행하거나 데이터베이스에서 원시 데이터 유지 관리 작업을 수행하기 위해 응용 프로그램을 만드는 경우입니다.
3) 깔끔하고 유지 가능한 코드
EF는 SQL / 프로세스를 능가합니다. 관계가 모델링 되었기 때문에 코드 조인은 상대적으로 드물다. 엔터티의 관계는 대부분의 쿼리에서 독자에게 거의 자명합니다. 실제로 데이터에서 발생하는 상황을 이해하기 위해 계층에서 계층으로 또는 여러 SQL / 중간 계층을 거쳐야하는 것보다 더 나쁜 것은 없습니다. EF는 데이터 모델을 매우 강력한 방식으로 코드에 제공합니다.
4) 유연성
저장된 procs와 raw 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입니다
다른 O / RM 솔루션을 살펴보십시오. L2S만이 유일한 것은 아닙니다 (NHibernate, ActiveRecord).
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
구체적인 질문을 해결하기 위해 :
- O / RM 솔루션의 품질에 따라 L2S는 SQL 생성에 매우 적합합니다.
- 프로세스를 시작하면 일반적으로 O / RM을 사용하는 것이 훨씬 빠릅니다.
- 코드는 일반적으로 훨씬 깔끔하고 유지 관리가 쉽습니다.
- Straight SQL은 물론 더 많은 유연성을 제공하지만 대부분의 O / RM은 가장 복잡한 쿼리를 제외한 모든 작업을 수행 할 수 있습니다.
- 전반적으로 O / RM을 사용하는 것이 좋습니다. 유연성 손실은 무시할 수 있습니다.
답변
LINQ-to-SQL은 사용이 매우 간단하고 백엔드에 대해 매우 우수한 쿼리를 생성하는 뛰어난 기술입니다. LINQ-to-EF는이를 대체하기 위해 예정되었지만 역사적으로 훨씬 열등한 SQL을 사용하고 생성하는 데 매우 어려웠습니다. 현재 상황을 모르지만 Microsoft는 L2S의 모든 장점을 L2EF로 마이그레이션하기로 약속 했으므로 지금은 더 나아질 것입니다.
개인적으로, 나는 ORM 도구에 대한 열렬한 혐오감을 가지고 있습니다 (자세한 내용은 여기 에서 제 당뇨병 환자를 참조하십시오). L2S가 데이터 액세스 계층에서 필요한 모든 것을 제공하기 때문에 L2EF를 선호 할 이유가 없습니다. 실제로, 수공 매핑 및 상속 모델링과 같은 L2S 기능은 완전히 불필요한 복잡성을 추가한다고 생각합니다. 그러나 그것은 단지 나입니다. 😉
답변
저장 프로 시저의 성능과 성능, Entity Framework와 같은 도구가 제공하는 빠른 개발인지 여부를 고려할 수있는 완전히 새로운 접근 방식이 있습니다.
작은 프로젝트에서 테스트 드라이브로 SQL +를 사용했는데 실제로는 특별한 것입니다. 기본적으로 SQL 루틴에 주석의 양을 추가하고 해당 주석은 코드 생성기에 명령을 제공하여 실제 SQL 루틴을 기반으로 멋진 객체 지향 클래스 라이브러리를 빌드합니다. 이와 유사한 엔티티 프레임 워크의 종류.
입력 매개 변수는 입력 오브젝트의 일부가되고 출력 매개 변수 및 결과 세트는 출력 오브젝트의 일부가되고 서비스 컴포넌트는 메소드 호출을 제공합니다.
저장 프로 시저를 사용하고 싶지만 빠른 개발을 원한다면이 내용을 살펴볼 수 있습니다.
답변
