Linq to SQL은 요점을 놓치지 않습니까? ORM- 매퍼 (SubSonic 등)가 차선책이 아닌가?
Linq to Sql 및 기타 ORM 매퍼에 대해 제가 가지고 있었던 몇 가지 생각을 커뮤니티에서 받아들이고 싶습니다.
저는 Linq to Sql과 C #과 SQL 간의 "임피던스 불일치"를 처리 할 필요없이 네이티브 개발 언어로 데이터 액세스 논리 (또는 일반적으로 CRUD 작업)를 표현하는 아이디어를 좋아합니다. 예를 들어, 비즈니스 계층에 대한 ObjectDataSource 호환 이벤트 인스턴스 목록을 반환하려면 다음을 사용합니다.
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
이전 SQL-to-C # 구문을 사용하여이를 구현하려면 Command 클래스를 만들고 EventID 매개 변수 ( "@EventID"인수를 설명하는 문자열 사용)를 추가하고 SQL 쿼리 문자열을 Command 클래스를 사용하고 명령을 실행 한 다음 (cast-type) nwReader [ "FieldName"]을 사용하여 반환 된 각 필드 값을 가져 와서 새로 만든 내 EventData 클래스의 인스턴스 (yuck)에 할당합니다.
그래서, 그 사람들이 왜 같은 Linq에 / 음속 / 등이다. 동의합니다.
그러나 더 큰 그림에서는 잘못된 것들이 많이 있습니다. 내 감각은 마이크로 소프트도 뭔가 잘못된 것을보고 있기 때문에 그들이 Linq to SQL을 죽이고 사람들을 Linq to Entities로 옮기려고하는 이유 입니다. 단지, 나는 마이크로 소프트가 나쁜 내기를 두 배로 줄인 것 같다 .
그래서, 무엇이 잘못 되었습니까?
문제는 아키텍처 우주 비행사 , 특히 Microsoft에서 Linq to Sql을보고 이것이 진정한 데이터 관리 도구가 아니라는 사실을 깨닫는다는 것입니다. 여전히 C #에서 쉽게 할 수없는 일들이 많이 있으며 그들은 그것을 고치는 것을 목표로 합니다. . Linq to Entities이면의 야망, Linq의 혁명적 특성에 대한 블로그 게시물 , 심지어 LinqPad 챌린지 에서도 이러한 사실 이 드러났습니다 .
그리고의 문제 즉, 이 SQL은 문제가 있다고 가정합니다. 즉, 약간의 불편 함 (SQL과 C # 간의 임피던스 불일치)을 줄이기 위해 Microsoft는 반창고 (Linq에서 SQL로 또는 이와 유사한 것)가 잘 작동 할 때 우주복 (완전 격리)에 해당하는 것을 제안했습니다.
내가 볼 수있는 한, 개발자는 관계형 모델을 마스터 한 다음 개발 노력에 지능적으로 적용 할 수있을만큼 똑똑합니다. 사실 저는 한 단계 더 나아가 Linq to SQL, SubSonic 등이 이미 너무 복잡 하다고 말할 것입니다 . 학습 곡선은 SQL 자체를 마스터하는 것과 크게 다르지 않습니다. 가까운 미래에 개발자 는 SQL과 관계형 모델을 마스터 해야하므로 이제 두 가지 쿼리 / CRUD 언어 를 학습해야 합니다. 설상가상으로 Linq는 테스트하기가 어렵고 (쿼리 창이 없음) 실제 작업에서 하나의 레이어를 제거하고 (SQL 생성) 다음과 같은 SQL 구문에 대해 매우 서투른 지원 (기껏해야)을 제공합니다. 날짜 처리 (예 : DateDiff), "Having"및 "Group By".
대안은 무엇입니까? 개인적으로 Linq to Entities와 같은 데이터 액세스를 위해 다른 모델이 필요하지 않습니다. Visual Studio에서 간단히 창을 열고 SQL을 입력하고 유효성을 검사 한 다음 단추를 눌러 C # 클래스를 생성하거나 보완하여 호출을 캡슐화하는 것을 선호합니다. 이미 SQL을 알고 있으므로 다음과 같이 입력하는 것을 선호하지 않겠습니까?
Select EventID, Title From Events Where Location=@Location
A) EventID 및 Title 필드를 속성으로 포함하고 B) 'Location'문자열을 인수로 사용하고 List <EventData>?를 생성하는 팩토리 메서드가있는 EventData 클래스로 끝납니다. 객체 모델에 대해 신중하게 생각해야하지만 (위의 예는 분명히 처리하지 않음) 임피던스 불일치를 제거하면서 SQL을 계속 사용하는 근본적인 접근 방식은 저에게 큰 매력을줍니다.
문제는 내가 틀렸나 요? 더 이상 SQL / 관계형 데이터 관리를 배울 필요가 없도록 Microsoft가 SQL 인프라를 다시 작성해야합니까? 이러한 방식으로 SQL 인프라를 다시 작성할 수 있습니까 ? 아니면 매개 변수를 설정하고 데이터 필드에 액세스하는 수고를 덜기 위해 SQL 위에 매우 얇은 레이어가 충분하다고 생각하십니까?
업데이트 나는 그들이 내가 추구하는 것의 중요한 측면을 포착한다고 생각하기 때문에 상단에 두 개의 링크를 홍보하고 싶었습니다. 먼저 코드 몽키는 "컴퓨터 과학의 베트남" 이라는 제목의 기사를 지적합니다 . 시작하는 데 시간이 좀 걸리지 만 매우 흥미로운 읽기입니다. 둘째, AnSGri는 Joel Spolsky의 가장 유명한 작품 중 하나 인 The Law of Leaky Abstractions를 지적합니다 . 주제에 대한 정확한 것은 아니지만 가깝고 훌륭한 읽기입니다.
업데이트 2 : 여기에는 훌륭한 답변이 많고 "올바른"답변의 선택은 순전히 주관적이지만 ocdecio에 "답변"을주었습니다. 이 경우 그의 대답은 현재 기술 상태를 고려할 때 진정으로 모범 사례라고 생각하는 것과 제곱되었습니다. 그러나 이것은 내가 완전히 진화 할 것으로 기대하는 영역이므로 상황이 바뀔 수 있습니다. 기여 해주신 모든 분들께 감사 드리며, 사려 깊은 답변을 해주신 분들께 찬성표를 던졌습니다.
최소 6 년 동안 저는 매우 간단한 개념 인 투영에 기반한 자체 ORM을 사용해 왔습니다. 각 테이블은 클래스로 프로젝션되고 SQL은 클래스 정의를 기반으로 즉석에서 생성됩니다. 여전히 SQL을 알아야하지만 90 % 간단한 CRUD를 처리하고 연결 등을 관리 할 필요가 없었으며 주요 DB 공급 업체에서 작동합니다.
나는 내가 가진 것에 만족하고 그것을 떨어 뜨릴만한 가치를 찾지 못했습니다.
내가 염색 한 데이터베이스 전문가라고 말하면서 서문을 시작하겠습니다.
과도한 일반화 : 개발자는 SQL을 모릅니다. 개발자는 실제로SQL을 알고 싶어 하지 않습니다. 그들은 그것을 쓸 수 있고, 테이블을 디자인 할 수 있지만, 그것은 그들을 어리석게 만듭니다. 그들은 필요한 쿼리가 단순한 조인 이상일 때 어리석은 일을하는 경향이 있습니다. 개발자들이 멍청해서가 아니라 귀찮게 할 수 없기 때문입니다. 그들은하나의 개념 공간 만 다루면되는 세상에서 사는것을 좋아 합니다. 물건에서 테이블로 그리고 뒤로 이동하는 것은 그들이 지불하는 것을 좋아하지 않는 가격을 컨텍스트 전환하는 것입니다.
이것은 그들이 나쁘거나 틀렸다는 것을 의미하지 않습니다. 개선의 기회가 있음을 의미합니다. 고객 (이 경우 프레임 워크를 사용하는 개발자)이 SQL과 테이블을 좋아하지 않는 경우 기본 혼란을 처리하지 않고도 벗어날 수있는 추상화 계층을 제공하십시오.
가비지 수집 / 자동 메모리 관리를 대히트하게 만드는 것과 동일한 논리입니다. 예, 개발자가 처리 할 수 있습니다. 예, 그들은 그것 없이도 더 잘 최적화 된 코드를 작성할 수 있습니다. 하지만 그것을 다룰 필요가 없으면 더 행복하고 생산적이됩니다.
ORM의 인기는 개발자들이 데이터 레이어를 개발하고 응용 프로그램 이후에 동일한 CRUD 코드를 반복해서 작성하면서 시작되었다고 생각합니다. ORM은 개발자가 동일한 SQL 문을 반복해서 작성하는 데 소요되는 시간을 줄이고 대신 응용 프로그램의 논리에 집중할 수있게 해주는 또 다른 도구 / 기술입니다.
IMHO, OR / M은 'SQL을 추상화'하거나 SQL을 숨기거나 다중 DBMS 지원을 활성화하는 것 뿐만이 아닙니다.
지루한 CRUD SQL 쿼리를 작성하는 데 소요되는 시간이 줄어들 기 때문에 문제 영역에 더 집중할 수 있습니다. 반면에 좋은 OR / M을 사용하는 경우이 OR / M을 사용하면 필요한 경우 SQL 쿼리를 작성할 수 있습니다.
OR / M은 적절하게 사용한다면 강력한 도구가 될 수 있습니다. 지연 로딩, 다형성 쿼리 / 연결을 처리 할 수 있습니다
. 오해하지 마십시오. 평범한 SQL에는 아무런 문제가 없지만 (잘 생각하고 정규화 된) 관계형 모델을 표현적인 OO / 도메인 모델로 변환하는 데주의를 기울여야한다면 배관 작업에 많은 시간을 소비하고 있다고 생각합니다.
OR / M을 사용한다고해서 개발자로서 SQL에 대한 지식이 없어야한다는 의미는 아닙니다. 그 반대는 진정한 imho입니다.
SQL을 알고 효율적인 SQL 쿼리를 작성하는 방법을 알면 OR / M을 올바르게 사용할 수 없습니다.
또한 NHibernate를 염두에두고이 글을 쓰고 있음을 인정해야합니다. 이것은 내가 atm을 사용하는 OR / M이며 Linq를 SQL로 또는 Linq를 엔터티에 사용하지 않았습니다 (아직).
Linq의 디자인과 linq to entity 프레임 워크는 확실히 orm 도구로 사용되지만 큰 아이디어는 RDBMS뿐만 아니라 모든 데이터 소스를 쿼리하는 공통 API로 사용된다는 것입니다.
linq는 분명히 SQL을 염두에두고 설계되었지만 모든 데이터 저장소에 대한 쿼리 언어를 의미한다는 것을 기억합니다. SQL에 대한 linq 쿼리를 작성할 수 있지만 이론적으로는 ldap, 파일 시스템, 교환, 웹 서비스, ad infinitum을 대상으로하는 linq 쿼리를 작성할 수도 있습니다. 이러한 프로그램에는 SQL을 사용할 수 없습니다.
또한 거의 모든 데이터 저장소에 대해 다른 API를 배워야합니다. Linq는 모든 사람에게 데이터 액세스 API를 만드는 공통 대상을 제공합니다.
이 비전이 작동하는지 여부는 아직 알 수 없지만 그것이 아이디어입니다. 시스템이 점점 더 상호 운용되기를 원하면 l2e에 대한 아주 좋은 용도를 찾을 수있을 것입니다.
다시 찾을 수 있으면 몇 가지 참조를 추가하겠습니다.
http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/
걱정하지 말고 ORM을 사랑하는 법을 배워야합니다. 이와 같은 추상화는 우리가 기술에 집중하고 현장에서 발전하는 데 도움이 될 것입니다.
습득 한 기능적 기술을 활용하고이를 애플리케이션 계층에 적용 할 여지가 여전히 충분합니다. 이것은 사실 다른 ORM에 비해 LINQ to SQL의 강점 중 하나입니다.
나는 다른 많은 의견들에만 동의 할 수 있습니다. 시간을 절약하면 도메인 모델을 구체화하고 더 나은 애플리케이션을 만드는 데 집중할 수 있습니다. 그리고 병목 현상을 파악했으면을 사용하여 최적화 된 SQL을 생성하십시오.
당장 명확하지 않은 것은 ORM에 정말 멋진 기능이 많이 포함되어 있다는 것입니다. 항목을 반복해서로드하지 않는 데 도움이되는 ID 맵, 지연로드는 적은 연결로 도메인을 표현하는 데 도움이되며 작업 단위는 변경 사항을 추적하고 데이터베이스 쓰기를 최적화하는 데 도움이됩니다.
100 % 동의합니다. 이 중 많은 부분은 절차 적 코딩 기술과 SQL 코딩 기술이 매우 다르다는 사실의 결과입니다. 그리고이 사실은 널리 알려져 있지 않습니다. 따라서 그 실현이 이루어질 때까지 프로그래머는 자신의 스킬 셋을 한 도메인에서 다른 도메인으로 이전 할 수있는 방법을 찾습니다.
작동하지 않습니다.
단순히 위상 이동 방법을 배워야합니다. 주소를 지정하는 도메인에 따라 코드에 대해 다르게 생각하는 방법을 배워야합니다.
SQL에서 LINQ로 매핑 될 때 쿼리가 얼마나 더 복잡하고 장황 해지는 지 다른 사람이 눈치 채 셨나요? 모든 온라인 예제에서?
Dmitriy가 지적했듯이 개발자는 SQL을 모릅니다. 더 정확하게는 대다수 가 SQL을 알고 있지만 이해 하지 못하고 확실히 좋아하지 않기 때문에 그들은 마법의 총알을 찾는 경향이 있습니다. 따라서 Linq와 같은 것을 요구하여 그들이 생각하는 착각 (흠, 추상화)을 만듭니다. 사랑하는 수업과 다른 것을 사용하지 마십시오.
새는 추상화의 법칙이 항상 사실 이기 때문에 그것은 매우 나쁘다 .
일부 ORM 솔루션은 확실히 좋습니다 (예 : JPA / Hibernate). SQL에 대해 걱정할 필요가 없기 때문이 아닙니다. 사실 JPA를 효과적으로 사용하려면 일반적으로 DB에 대한 깊은 이해, 특히 쿼리 기능이 필요합니다. 좋은 점은 처음부터 전체 데이터베이스를 자동 생성하는 지점까지 기계가 지루한 작업을 수행하도록 한다는 것 입니다 .
Linq to SQL은 내가 생각하는 것처럼 실제 문제를 해결하지 못합니다. 그것은 다른 표현입니다. 이미 복잡한 언어를 지나치게 복잡하게 만들지 만 좋을 수도 있습니다. 반면에 Linq to Objects는 컬렉션을 SQL 쿼리하는 방식이기 때문에 매우 흥미로운 개념입니다.
역사적 관점.
Codd et. al. 원래는 관계형 데이터베이스의 이론과 구현을 연구하고 있었는데, 완전히 별개의 문제는 "어떻게 이러한 것들을 쿼리합니까?"였습니다. 다양한 강점과 약점을 포함한 다양한 전략과 구문이 제안되었습니다. 이러한 후보 중 하나는 SQL (초기 형태, 당연히)입니다. 다른 하나는 QBE (Query By Example)입니다. 다른 하나는 "quel"이라고 불렀습니다. 다른 몇 가지가있었습니다. SQL이 다른 모든 것보다 우월하다고 평가 되었기 때문에 확실히 지배적이지는 않았습니다. 그러나 불행히도 다른 것들은 우리 모두의 빈곤으로 거의 사라졌습니다 (동일한 데이터에 동시에 사용될 수 있기 때문입니다.)
Microsoft가 이러한 다른 언어 중 하나를 되 살리고 있거나 가치있는 추가 기능을 발명했다는 좋은 이야기를 가지고 있다면 잘 들어 보시는 것이 좋습니다. 그러나 지금까지 내가 본 것은 또 다른 "모두를 지배하는 하나의 반지"입니다.
SQL 뒤에는 엄청나게 많은 생각과 엄격함이 있으며 시간이 입증 된 내구성이 많습니다. 마이크로 소프트는 그들의 최고 수준의 개발 조직이 우리의 집단적인 기관 기억을 포함하여 우리의 나머지 부분을 능가 할 수 있다고 믿고 있습니다. 그렇게 자주 작동하지 않는 것 같습니다. 우리가 관계형 데이터 저장소에 연결되어있는 한 동일하거나 더 나은 성능을 약속하면서 베어 메탈에서 벗어나게하는 수퍼 세트 추상화 패러다임에 대해 두 번 생각해야합니다.
ORM 프로젝트의 저자이기 때문에 이와 같은 질문에 대한 나의 답변이 약간 편향되기 쉽다는 것을 인정해야합니다. 나는 이미 질문을 읽기 전에 답에 대한 내 자신의 생각을 개발 했으므로 이미 다소 고정되어 있습니다.
ORM을 개발 한 이유는 SQL과 명령형 프로그래밍 사이의 "임피던스 불일치"때문이 아니라 데이터베이스 플랫폼에 구애받지 않기위한 것입니다. 지속성을 관리하기 위해 더 많은 코드를 작성해야하는 이전 문제는 하나의 데이터베이스 공급 업체와 만 작업하는 경우 쉽게 해결할 수있는 작은 장애물입니다. 데이터베이스 플랫폼에 구애받지 않는 것은 훨씬 더 어려운 문제이며 imo는 저처럼 다른 사람에게 소프트웨어를 판매 할 계획이라고 가정 할 때 비즈니스의 수익성에 훨씬 더 큰 영향을 미칩니다.
몇 년 전 ORM 도구 작업을 시작했을 때이 개념은 내가 선호하는 언어로는 실용적이지 않았고, 제가 대화 한 대부분의 사람들은 내가 작업하는 이유를 이해하지 못했고 커뮤니티에서 존경받는 일부 목소리는 글만큼 많은 글을 썼습니다. 무역 잡지에서 내가 이미 한 일은 불가능할뿐만 아니라 바람직하지도 않다고 말했습니다. 동일한 이유 중 일부가 주어졌습니다. 너무 복잡하고 제한적이며 오버 헤드를 추가합니다. 오늘날 동일한 커뮤니티에는 적어도 세 가지 인기있는 데이터베이스 추상화 도구가 있습니다 (ORM이라는 용어의 정의에 대한 논쟁이 있지만). 제가 이것을 언급 한 이유는 제가 이러한 도구를 작업하기 시작했을 때 원래의 반대 의견이 지금보다 훨씬 더 중요했기 때문입니다. 하드웨어와 소프트웨어의 기본 기술은 장기적으로 이러한 도구를 훨씬 더 실용적으로 만들기 위해 몇 년 동안 변경되었습니다. 저의 경향은 소프트웨어에 대한 장기적인 관점을 가지고 아직 실용적이지는 않지만 곧 실용적이 될 솔루션에 대해 작업하는 것입니다. 따라서 특정 문제에 대한 좋은 솔루션으로 LINQ to Entities를 고려하지 않을 것입니다.
나는 또한 적은 것보다 더 많은 옵션을 선호하는 경향이 있습니다. 따라서 LINQ to Entities 개발에 대한 아이디어를 지원할 수는 있지만 LINQ to Entities를 사용할 수있게 되었기 때문에 LINQ to SQL을 중단하는 것을 지원하기에는 적합하지 않습니다. 객체는 객체가하는 일에 적합합니다. 그에 대해 의심 할 여지가 없습니다 ... 제 (다시 한 번 편향된) 의견으로는, 사람들이 주어진 도구 또는 소프트웨어 패러다임을 "마법의 총알"로보고 모든 것을 주장하려는 문제가 발생합니다. 그래야만합니다. 관계형 데이터베이스는 다른 특정 작업을 처리하는 데 매우 능숙하며보고가 좋은 예라는 것은 잘 알려져 있습니다. 그래서 제 생각에는 모든 것이 실체 여야한다고 주장하기 위해 자신을 쏘는 것과 같습니다. 왜냐하면 그 작업에 비효율적 인 도구를 사용하도록 강요하고 있기 때문입니다. 특히보고와 관련하여추상화 반전 안티 패턴.
그래서 내 대답의 시놉시스는 이것입니다. 문제가 못이라면 망치를 사용하고 문제가 나사라면 드라이버를 사용하십시오.
개발자가 SQL을 좋아하지 않는다는 Dmitry의 진술에는 많은 진실이있을 수 있지만 해결책은 ORM만이 아닙니다. 해결책은 개발 팀의 일원으로 개발 DBA를 고용하는 것입니다. 우리 회사의 .net 개발 팀에는 프로덕션 dba 작업을 전혀 수행하지 않는 뛰어난 Oracle DBA가 있습니다. 우리 팀에서 그의 역할은 데이터 모델링, 물리적 DB 설계, 저장된 procs 생성, 데이터 분석 등입니다. 그는 DB 측이 매우 깨끗하고 성능이 뛰어난 이유입니다. 모든 DB 액세스는 저장된 procs를 통해 이루어집니다.
개발 DBA 란 무엇입니까? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/
저는 데이터베이스와 분산 애플리케이션 프로그래밍 (웹 및 컴파일)을 모두 수행하며 저장 프로 시저 기반 데이터 액세스 계층을 개발하는 데 시간을 할애하는 것이 시간이 많이 걸린다고 생각합니다. 개인적으로 저는 데이터 모델링을 선호하고 개발 프로세스 초기에 필요한 프로세스를 식별하는 것을 선호합니다. 디자인 / 인터페이스 로직 / 구조 문제를 발견하는 데 도움이되는 것 같습니다.
나는 인라인 데이터베이스 프로그래밍의 열렬한 팬이 아닙니다 (SQL 코드가 수 동인지 기계 생성인지 여부). 저는 데이터베이스가 애플리케이션의 기초이며 저장된 procs를 직접 코딩하는 데 시간을 할애하는 것이 가치가 있다고 생각합니다.
즉, 저는 OODBMS 개념에 흥미를 느끼고 언젠가 프로덕션 환경에서 작업 할 수 있기를 바랍니다.
데이터베이스가 확장됨에 따라 수행되도록하려면 데이터베이스 관계형 모델 모범 사례에 따라 설계 및 정규화해야합니다.
객체 모델과 ORM이 데이터 모델을 지시하도록하면 정규화되지 않았거나 객체 모델의 아티팩트를 포함하는 불량 데이터 모델로 끝날 것입니다.
1 테이블 = 1 클래스는 나쁜 생각입니다.
시작하려면 다 대다 또는 다 대일 링크 테이블을 나타내는 클래스가 절대로 없습니다. 이들은 개체 모델의 자식 컬렉션에 해당하며 링크 자체는 개체가 아닙니다.
데이터베이스를 테이블로 취급하여 단순히 개체를 행에 보관하고 (한 가지 일반적인 접근 방식) 애플리케이션에 테이블에 대한 직접 액세스를 제공하면 데이터베이스가 보호하는 데 사용할 수있는 데이터베이스 서비스의 인터페이스 계층을 정의하는 모든 이점을 포기하게됩니다. 그 둘레.
ORMs have their place, but if you use them to simply persist your objects as designed in your object model, your database will not be a relational database, and it will not be able to be used as one for the purposes of ETL, reporting, refactoring, etc.
I think the logic behind these things is that the overhead of building and running an SQL statement in the framework layer is insignificant compared to overhead in other parts of the system (e.g., a HTTP request round trip is orders of magnitude longer).
The advantages - fast development, queries that fit in with the language rather than being escaped strings, etc, often outweigh the disadvantages. If performance is an issue, then you can optimise later.
I don't think that "not needing to know SQL" is a factor. Any decent developer will need to know SQL at some point in their development. The idea of a database abstraction layer is to remove the effort of generating boilerplate code for database queries.
Indeed in our system in Java, I created a code generator utility that took annotated classes and generated a full CRUD API, and handling all those quirky things you pick up over time. Far easier to create your model and annotate it than to slog through writing a DAO. Scale such a tool up and you end up with LINQ or Hibernate or myriad other ORM DB solutions.
There was another question here that asked about ORMs in general. Check that out for some more discussion of whether or not the impedance mismatch is as big a deal as all that.
I think the real solution that they needed was something more like SQL literal. VB.Net 9.0 supports XML Literals, which allow you to write XML right in your code, and ensure that it's validated and meets the DTD. A similarly nice feature would be SQL literals that allow you to write inline SQL code in your .Net code, and have it validated by the IDE. There would need to be some sort of plugin architecture to verifying the information against the database, but that could be easily written for the popular database engines. This would provide what I think to be the real solution, to the problem they were trying to solve, without resorting to sub-optimal solutions.
Codemonkey makes a very good point: stored procedures offer a level of abstraction that fulfills some of the promise of the more complex ORM models. This isn't intuitive at first glance but I can think of an example right from my own code. I have a "check-in" sproc that touches nearly a dozen tables (who does this ID belong to? do they have a membership? Are there any messages? Do they get points for this check-in? etc.).
Modeling this in C# - no matter how sophisticated the data model - would never be a good idea as it would necessitate many trips "over the wire" to check on data and update various tables. While it is true that you can handle sprocs in Linq or other ORMS, all I need is a wrapper class that allows me to call the sproc with standard C# parameters. In fact, this was such a pressing need for me that I wrote a code generator in T-SQL to create such wrappers.
I don't like any of the current solutions - but i prefer more choices over less choices ;-)
i used an OODBMS in a project long ago that was the closest to getting it right (unfortunatley the product had some heinous bugs and terrible tech support) - object persistence was largely invisible, handled behind the scenes (via preprocessor code-generator) and controlled by very simple Update, Delete, and Find methods and simple containers.
I'd love to see this (and perhaps some object-entity model does this well already) again, with OCL (Object Constraint Language) as the native multi-object query language
I have to agree that the outburst of ORM tools largely stems from the annoyance of writing SQL, dealing with whatever DB driver you have to use, internally abstracting between DBs (Oracle vs SQL Server, vs whatever for code reusability), and transforming data types.
Ideal solution? definately not! However, I think this is an iteration in the process of better merging the application with the data store. After all, in most cases, having a DB without an accessing application written in whatever language is practically useless. (would you really ever just install oracle, and expect all employees to work in SQLPlus directly?)
As such, I think the data store and the application are just moving together in a way that the application developer can more easilly interact with the data store.
For .NET in particular, what I'd much rather see instead of Linq is a built in way to map a class definition to an underlying data source to an underlying data store, and have all the plumbing just work.
In other words I could just say "Employee.Name = 'rally25rs';" and the object's property would change, and underneath that it would persist to the data store itself. Just ditch SQL completely instead of going 1/2 way like Linq to SQL does now.
Of course, a solution like that brings up issues with performance, transaction handling, etc.
Maybe the entire concept of programming language and relational database need to be rethought and realigned? At their core, they are completely separate and disjointed entities. Maybe its time to just ditch the "relational sql aware database" and build the next thing, whee executing a line of code would directly operate on the database.
there´s no problem with linq, but with those who use it and ignore what happens "behind the scenes"
I still prefer to get my hands dirty with SQL. At least i´ll know exatcly whats happening.
Ted Neward wrote a great essay on his take on this subject - that ORM's are the "Vietnam" of computer science...
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
Most people have missed an essential point: in most cases, you are significantly more productive when querying in LINQ than in SQL. I've written an article on why this is so.
When I set the LINQPad Challenge, I wasn't joking: I do nearly all of my ad-hoc querying in LINQ because most queries can be written more quickly and reliably in LINQ than in SQL. I've also designed and worked on large business applications using LINQ to SQL and seen a major gains in productivity. This is not "architecture astronaut" stuff - LINQ to SQL is a productive and practical technology that drives this very site.
The biggest hindrance with LINQ is failing to properly learn it. I've seen so many LINQ queries that are horrible transliterations of SQL queries to back this up. If you write LINQ queries using only your knowledge of SQL, the end result can only be the same - or worse - than SQL.
I just discovered this question. I guess it's pretty much played out by now, but I'm going to throw in my two cents anyway...
I only want to write code for the things that aren't obvious.
CRUD code is obvious. I don't want to write it. Therefore, ORMs are a good idea.
This doesn't mean that ORMs don't have problems, but the problems are with execution, not intent. As ORMs mature, the problems will diminish, and the productivity gains already available for simple scenarios will eventually extend to complex scenarios as well.
LINQ is also a good idea. Others have mentioned a number of the advantages, but all I have to do is think about the first time I tried to do a pivot in LINQ where I didn't know the number of columns in advance. Or the first time I realized I didn't have to create a new DataView every time I wanted to sort or filter something. LINQ empowers me to do everything I want to do with data in C#, rather than having to figure out how divide up the work between SQL and C#.
So, yes, ORMs, LINQ, and other emerging technologies are suboptimal solutions, but they don't miss the point, and they won't be suboptimal forever.
I wanted to write this as a reply to @SquareCog reply here, but it told me I had -1836 characters left. S.O. noob here so apologies if I've done this wrong.
In the 18th century gentleman of leisure used to study science. At that time science in its entirety was not such a large subject that a reasonably intelligent person couldn't understand it all. By which I mean a single learned fellow could understand the entirety of scientific thinking of the time.
As time has gone by hundreds of new fields of science have been discovered and each one researched to the point where these days very few people can even understand the entirety of a single complete field of science.
So it is with programming.
These days the programming language field is large enough and growing fast enough that it is as much as can be reasonably be expected of a developer to know the entirety of his own specialised languages(s). For a skilled coder to also be expected to understand the entirety of the database field too, including database design, the nuances of native SQL and how it operates on different databases and the administration of those databases too, is possibly asking a bit much.
I think some of the responders here are glossing over some of the complexities of developing a large performant enterprise level database, knowing a 'handful of SQL statements' most certainly does not cut it. Which is why most large software houses have dedicated teams of database developers. As Stroustrup says, 'Divide and conquer' is the only way to effectively deal with the complexity inherent in developing and managing large software projects.
Developers don't dislike working with SQL because they are lazy or because it makes them feel 'icky'. They dislike working with SQL because they are smart. They know better than anyone that only someone who specialises in SQL will deliver the highest quality database functionality and that for them to be put into the position of being 'jack of all trades' developers is a suboptimal development strategy.
'Nice programing' 카테고리의 다른 글
| Sierra의 보안 / 코드 로그인 : 키 체인은 액세스 제어 설정 및 권한에 대한 UI 프롬프트를 무시합니다. (0) | 2020.11.06 |
|---|---|
| Subversion Externals는 반 패턴입니까? (0) | 2020.11.06 |
| svn의 마지막 변경 사항보기 (0) | 2020.11.06 |
| WCF가 보안되지 않거나 잘못 보안 된 오류 오류를 제공함 (0) | 2020.11.06 |
| LINQ를 사용하여 문자열에 숫자가 하나 이상 있는지 확인 (0) | 2020.11.06 |