필자는 Dapper와 같은 소위 "Micro ORM"을 조사해 왔으며 (.NET 4.0에 의존하는 정도는 적음) 현재 시스템 이후 본격적인 ORM보다 직장에서 구현하기가 더 쉽기 때문에 대규모 저장 프로 시저에 크게 의존하며 NHibernate 또는 EF와 같은 ORM과 함께 작동하려면 상당한 리팩토링이 필요합니다. 모든 기능을 갖춘 ORM에 대해 이들 중 하나를 사용하면 어떤 이점이 있습니까? 그것은 여전히 원시 SQL을 작성하도록 강요하는 데이터베이스 연결 주위의 얇은 계층처럼 보입니다. 아마도 틀렸지 만 항상 ORM의 이유는 항상 SQL을 쓸 필요 가 없다는 이유로 들었 습니다. 자동으로 생성 될 수 있습니다; 특히 다중 테이블 조인 및 순수한 SQL에서는 쉽지 않지만 ORM에서는 사소한 테이블 간의 맵핑 관계에 적합합니다.
예를 들어 Dapper의 예를 살펴보면 다음과 같습니다.
var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });
명령을 작성할 필요가 없다는 점을 제외하고 수동 롤링 된 ADO.NET 데이터 계층을 사용하는 것과 다른 점은 매개 변수를 설정하고 빌더를 사용하여 엔티티를 다시 매핑한다고 가정합니다. 스토어드 프로 시저 호출을 SQL 문자열로 사용할 수도 있습니다.
Micro ORM이 사용하기에 여기서 또 다른 실체적인 이점이 있습니까? 몇 줄의 코드를 제외하고는 ADO.NET을 사용하는 "오래된"방법을 통해 어떻게 저장하는지 실제로 알지 못합니다. 여러분이 실행 해야하는 SQL (털이 생길 수 있음)을 알아 내기 위해 작성해야합니다. 여전히 테이블 (IMHO ORM이 가장 도움이되는 부분) 간의 관계를 매핑해야합니다.
var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });한 다음 dog.First().Age속성에 액세스하기 위해 사이트에서 Dapper의 구체적인 예를 찾을 수 없었습니다 .