구식 SQL DB 액세스와 ORM(NHibernate, EF 등).누가 이겼어?

Question

나는 저장 프로시저와 매개변수화된 쿼리, 그리고 ADO.NET 그런지를 최소화하기 위해 작성한 작은 래퍼 라이브러리를 조합하여 나만의 SQL 액세스 코드를 작성하는 데 성공했습니다.과거에는 이 모든 것이 나에게 매우 효과적이었고 나는 그것으로 꽤 생산적이었습니다.

저는 새로운 프로젝트를 시작하려고 합니다. 기존의 학교 업무를 뒤로하고 ORM 기반 솔루션을 탐구해야 할까요?(나는 NHibernate와 EF 사이에 엄청난 고개념 차이가 있다는 것을 알고 있습니다. 여기서는 그것에 대해 다루고 싶지 않습니다.논쟁의 편의를 위해 LINQ를 기존 대안과 동일시하겠습니다.) 저는 제가 알고 있는(그리고 꽤 잘 알고 있는) ORM 유형의 실제 적용에 대한 조언을 찾고 있습니다.

구식 ADO.NET 코드 또는 ORM?나는 곡선이 있다고 확신합니다. 곡선에 가치 있는 ROI가 있습니까?나는 불안하고 배우고 싶지만 마감일이 있습니다.

Answer 1

좋은 질문이지만 매우 논란이 많은 주제입니다.

Frans Bouma의 이 블로그 게시물 몇 년 전부터 저장 프로시저에 대한 동적 SQL(ORM 암시)의 장점을 인용하면서 격렬한 불꽃 전쟁이 촉발되었습니다.

Answer 2

코드 프로토타입을 작성할 때 LINQ to SQL이 훨씬 더 빠르다는 것을 알았습니다.지금 뭔가가 필요할 때 다른 방법을 사용하지 않아도 됩니다.

그러나 비용이 발생합니다.수동으로 저장한 프로세스에 비해 LINQ는 느립니다.특히 사소해 보이는 변경 사항이 갑자기 1+N 쿼리로 바뀔 수 있으므로 매우 조심하지 않으면 더욱 그렇습니다.

내 추천.처음에는 LINQ to SQL을 사용한 다음, 필요한 성능을 얻지 못하면 procs로 전환하세요.

Answer 3

몬트리올의 DevTeach에서 이 주제에 관해 훌륭한 토론이 있었습니다.이 URL로 이동하면: http://www.dotnetrocks.com/default.aspx?showNum=240 해당 분야의 두 전문가(Ted Neward 및 Oren Eini)가 각 접근 방식의 장단점에 대해 논의하는 내용을 들을 수 있습니다.아마도 실제로 명확한 답이 없는 주제에 대해 찾을 수 있는 가장 좋은 답일 것입니다.