ORM을 사용해야하는 이유는 무엇입니까? [닫은]

113

관리 / 클라이언트에게 ORM을 사용하는 이유에 대한 "프로"에게 동기를 부여하려면 그 이유는 무엇입니까?

가장 좋은 이유가 무엇인지 확인할 수 있도록 답변 당 하나의 이유를 유지하십시오.

database  orm 
— Simon Munro
소스
3
설문 조사를 원한다면 위키로 만들어야합니다
— frankodwyer
설문 조사를 원하면 위키로 만드는 +1
— cletus
16
죄수는 어떻습니까?
— Brian Matthews
4
그리고 숟가락도 없습니다. 아니요, 실제로 단점이 있습니다. 성능입니다. ORM을 거치지 않아도 DB 쿼리를 최적화하는 것이 훨씬 쉽습니다. (저는 불평하지 않습니다. 최근 에 ORM으로 전환 한 후 대부분 만족합니다. 일반적인 목적으로는 ORM을 사용하는 것이 좋습니다.하지만 성능이 필요한 경우 쿼리를 금속에 더 가깝게 실행할 수있는 방법이 있습니다. )
— Piskvor 건물 왼쪽
2
@ UğurGümüşhan, IMHO ORM 사용의 가장 큰 이점은 개발자가 나머지 앱에서 사용하는 동일한 언어와 OO 패러다임으로 프로그래밍 할 수 있도록함으로써 개발자의 생산성을 높이는 것입니다. 저장 프로시 저는 RDBMS 저장 프로 시저 언어로 개발자 코드를 만들 때이를 제공 할 수 없습니다. 그래서 그들은 ORM이 할 수있는 모든 것을 할 수 없습니다 .
— Bill Karwin 2013

답변:

53

데이터 액세스를보다 추상적이고 이식 가능하게 만듭니다. ORM 구현 클래스는 공급 업체별 SQL을 작성하는 방법을 알고 있으므로 그럴 필요가 없습니다.

— 빌 카윈
소스
61
이것이 ORM의 기능이라는 데 동의하지만 사용 사례가 상당히 제한적이라고 제안합니다. 나는 약 10 년 동안 MySql과 sqlite 외에는 어떤 것도 사용하지 않았습니다. 대부분의 개발자에게 매우 드문 요구 사항이라고 생각합니다.
— troelskn
40
@troelskn : 동의합니다. 많은 RDBMS 제품을 사용했지만 프로젝트 당 한두 개 이상은 사용하지 않았습니다. 따라서 이식성은 SQL 추상화의 가장 실용적인 가치가 아닙니다. 많은 ORM 사용자가 단순히 SQL로 코딩하는 것을 피하고 싶어한다고 생각합니다.
— Bill Karwin
2
공급 업체는 항상 새로운 버전 / 기능을 제공합니다 ... 방언을 작성하고 쉽게 업그레이드 할 수있는 멋진 사람들이 필요합니다!
— dotjoe
5
전형적인 쓸모없는 대답 왜 그것이 좋은 대답으로 표시되는지 궁금합니다. 질문을하는 사람은 자신이 ORM을 사용해야한다고 상사에게 정당화하려고 노력하는 것 같습니다. stackoverflow.com/questions/6477170/…
— user310291 2011-06-25
2
@ user310291 : OP는 문제 나 함정을 요구하지 않고 ORM 사용의 이점을 요청했습니다. 물론 장단점이 있지만 그는 장단점을 요구했습니다. 솔직히 ORM의 주요 이점으로 간주하지 않기 때문에이 답변이 받아 들여지고 많은 찬성 투표를 받았다는 사실에 놀랐습니다.
— Bill Karwin 2011-06-25
83

ORM을 사용하는 가장 중요한 이유는 풍부한 객체 지향 비즈니스 모델을 보유하면서도이를 저장하고 관계형 데이터베이스에 대해 효과적인 쿼리를 빠르게 작성할 수 있기 때문입니다. 제 관점에서는 작성할 수있는 고급 유형의 쿼리 외에 다른 생성 된 DAL과 비교할 때 좋은 ORM이 제공하는 실제 이점이 없습니다.

제가 생각하는 쿼리 유형 중 하나는 다형성 쿼리입니다. 간단한 ORM 쿼리는 데이터베이스의 모든 셰이프를 선택할 수 있습니다. 모양 모음을 다시 얻습니다. 그러나 각 인스턴스는 판별 자에 따라 정사각형, 원형 ​​또는 직사각형입니다.

또 다른 유형의 쿼리는 단일 데이터베이스 호출에서 개체와 하나 이상의 관련 개체 또는 컬렉션을 열심히 가져 오는 쿼리입니다. 예를 들어 각 모양 객체는 해당 정점 및 측면 컬렉션이 채워진 상태로 반환됩니다.

다른 많은 사람들과 의견이 일치하지 않아서 미안하지만 코드 생성만으로는 ORM을 사용할 충분한 이유가 아니라고 생각합니다. ORM이 수행하는 개념적 또는 성능 오버 헤드가없는 코드 생성기를위한 좋은 DAL 템플릿을 많이 작성하거나 찾을 수 있습니다.

또는 ORM을 사용하기 위해 좋은 SQL을 작성하는 방법을 알 필요가 없다고 생각하는 경우 다시 동의하지 않습니다. 단일 쿼리를 작성하는 관점에서 ORM에 의존하는 것이 더 쉽다는 것은 사실 일 수 있습니다. 그러나 ORM을 사용하면 개발자가 쿼리가 ORM과 변환되는 SQL과 함께 작동하는 방식을 이해하지 못할 때 성능이 떨어지는 루틴을 만드는 것이 너무 쉽습니다.

여러 데이터베이스에 대해 작동하는 데이터 계층이 있으면 이점이 될 수 있습니다. 그래도 자주 의존해야하는 것은 아닙니다.

결국, 내 경험상 ORM의 고급 쿼리 기능을 사용하지 않는 경우 학습을 줄이고 CPU주기를 줄여 나머지 문제를 해결하는 다른 옵션이 있다는 것을 반복해야합니다.

오 예, 일부 개발자는 ORM으로 작업하는 것이 재미 있다고 생각하므로 ORM은 개발자를 행복하게 유지하는 관점에서도 좋습니다. =)

— 척
소스
1
잘했다. 원본 포스터는 "단점"이 아닌 "장점"을 구체적으로 찾았지만 ORM을 사용하는 방법의 영향을 이해하지 못하여 생성 된 끔찍한 SQL을 보았습니다. 저에게 가장 큰 이점은 트랜잭션 시스템을위한 DAL 코드의 대부분인 간단한 CRUD 트랜잭션입니다. 순수한 ORM과 다른 생성 된 DAL 방법 사이에 머리카락을 나누고 있다고 생각합니다. 객체와 DB 간의 변환에 도움이되는 모든 것이 ORM으로 간주 될 수 있다고 생각합니다. 이는 단지 다른 운영 모델 일뿐입니다.
— Doug Lampe 2013 년
1
@Doug-저는 단순한 DAL이 생성 된 CRUD SQL보다 조금 더 많이 구성되는 반면 ORM에는 탐색 속성, 컬렉션 지속성, 전용 쿼리 언어, 캐시 등과 같은 더 많은 추상화가 포함되어 있다는 차이점이있었습니다.-더 나은 방법 당신의 관찰에 비추어 내 요점을 언급하는 것은 ORM의 더 많은 기능을 사용하면 더 빨리 구현할 수 있다는 것이 사실이지만 이러한 기능이 작동하는 방식을 무시하는 것은 결코 용납되지 않습니다. 아마도 ORM의 추상화가 대부분의 것보다 더 많이 유출되기 때문일 것입니다. ( en.wikipedia.org/wiki/Leaky_abstraction )
— Chuck
이에 대해 좀 더 자세히 설명해주십시오. "ORM의 고급 쿼리 기능을 사용하지 않는 경우 나머지 문제를 해결하는 다른 옵션이 있습니다." 또한 hibernate의 제작자 인 gavin king은 다음과 같이 말합니다. "실제로 Hibernate와 같은 시스템은 필요한 경우 네이티브 SQL을 쉽게 혼합 할 수 있도록"누수 추상화 "로 설계되었습니다. ORM 추상화의 누출은 버그가 아니라 기능입니다. ! " - reddit.com/r/programming/comments/2cnw8x/...
— jungle_mole
1) 이것은 오래되었습니다. 당시 ORM에는 모든 기능 (캐시, 쿼리, 일괄 처리 등)이있었습니다. IMHO, 개체 기반, 다형성 쿼리는 코드 생성 (명시 적 ADO 매핑)이 쉽게 제공 할 수없는 유일한 ORM 기능이었습니다. 2) 일부 유용한 구멍이 의도적으로 남겨졌지만 ORM에서 높은 학습 곡선을 생성하는 필요한 악과 고급 기능도있었습니다. 그래서 내 대답은 고급 쿼리가 필요하지 않는 한 ORM 대신 코드 생성을 사용하는 것이 었습니다. *) 현재, ORM에는 팀에 적합한 기능 세트가있을만큼 다양한 ORM이 있습니다. 우리 팀은 이제 Linq2DB를 좋아합니다.
— Chuck
60

빠른 개발. 예를 들어 쿼리 결과 필드를 개체 멤버에 매핑하거나 그 반대로 매핑하는 것과 같은 반복적 인 코드를 제거합니다.

— 빌 카윈
소스
3
반복적 인 코드는 매우 나쁘지만 이것을 제거하는 추상화를 만들 수 없습니까? 예를 들어, 작업을 수행 할 수있는 행을 다시 제공하는 테이블 / 쿼리 결과 개체를 가질 수 있습니다. ORM은 쿼리 결과의 테이블 / 행인 DB가 선택한 추상화에 들어가는 대신 개별 클래스 인스턴스로 행을 나누는 것처럼 보입니다. 이것이 ORM이 좋지 않다는 것을 의미하지는 않지만 이것만으로도 ORM을 사용하는 이유는 확실하지 않습니다.
— Benjohn 2011
@Benjohn, ORM 솔루션은 개별 행을 객체로 취급하는 반면 RDBMS는 행 세트 를 엔티티로 취급한다는 데 동의합니다 . OO 마인드로는 할 수없는 RDBMS 마인드로 할 수있는 일이 있습니다.
— Bill Karwin 2014
이 단지 트렁크를 사용하는 전체 차를 사는 것과 같다, 반복적 인 작업을 피하기 위해 여러 가지 방법이 있습니다
— mohas
15

데이터 액세스 계층에서 비즈니스 규칙의 OO 캡슐화를 지원합니다. 어설픈 트리거 및 저장 프로 시저 언어 대신 선호하는 애플리케이션 언어로 비즈니스 규칙을 작성 (및 디버그) 할 수 있습니다.

— 빌 카윈
소스
그래도 데이터베이스에 비즈니스 규칙을 갖고 싶지 않습니까? 이것이 바로 데이터베이스의 이점입니다. 여러 클라이언트가 DBMS에서 제공하는 동일한 인터페이스를 사용할 수 있습니다. 많은 인터페이스 로직이 특정 클라이언트의 ORM 코드에 잠겨있는 경우 데이터베이스에없고 다른 클라이언트에서 사용하지 않는 것입니다. 큐 프론트 오피스 백 오피스 중단 (한 클라이언트 모델이 다른 클라이언트 모델과 일치하지 않음).
— Benjohn 2014
1
@Benjohn, 저는 단순히 비즈니스 규칙을 데이터베이스에 넣는 경향이 있지만 선언적 제약 조건에서는 더 복잡한 규칙이 쉽게 형성되지 않습니다. 예 : "고객은 동일한 브랜드에서 3 켤레 이상의 바지를 처음 구매할 때 전체 주문에서 10 % 할인을받습니다." 비즈니스 규칙을 데이터베이스에 어떻게 넣을까요 (저장 프로 시저와 관련된 대답은 어색함을 명심하십시오).
— Bill Karwin 2014
2020 년이되었는데 더 이상 저장 프로 시저를 사용하는 사람이 보이지 않습니다. 그래서 당신은 여전히 ​​서 있습니까?
— ospider
내 요점은 사람들 이 저장 프로 시저를 사용 하지 않고 응용 프로그램 코드를 사용한다는 것입니다. 뭔가 다른 걸 이해 했나요?
— Bill Karwin
8

추상화로 개발 중이므로 다른 데이터베이스 소프트웨어로 쉽게 이동할 수 있습니다.

— Matt Fenelon
소스
41
30 년 이상 데이터베이스 작업을하면서 한 번도이 작업을 수행 할 필요가 없었습니다.
— HLGEM
4
불가능하다는 뜻은 아닙니다! :)
— Matt Fenelon
2
@HLGEM은 클라이언트에 대한 선택을 닫고 있음을 의미합니다. 실제로 웹 어플리케이션 작업의 불과 3 년 만에 일어날 수있는, 우리는 ORM들을 사용하여 휴대용 소프트웨어를 내장 한
— Alfabravo
1
메모리 내 데이터베이스에서 테스트를 실행하려는 경우 유용 할 수 있습니다
— Carlos Parraga 2018-08-30
동일한 소프트웨어의 여러 인스턴스가 다른 데이터베이스를 사용할 수 있습니다. 그러나 실제로 기존 데이터를 한 DB 소프트웨어에서 다른 DB 소프트웨어로 옮기는 일은 거의 발생하지 않습니다. 그럴 때 많은 ORM이 실제로 도움을주지 않습니다.
— jlh
4

개체 모델과 지속성 모델이 일치하도록합니다.

— 클레 투스
소스
1
지속성이 객체 모델에 투명하도록 할 수 있습니다
— S.Lott
4

개발 행복, IMO. ORM은 SQL에서 수행해야하는 많은 베어 메탈 작업을 추상화합니다. 코드베이스를 단순하게 유지합니다. 관리 할 소스 파일이 적고 스키마 변경에 몇 시간의 유지가 필요하지 않습니다.

저는 현재 ORM을 사용하고 있으며 개발 속도가 빨라졌습니다.

— 호기심 많은
소스
3

내가 조사하는 이유는 VS2005의 DAL 도구 (스키마 매핑, TableAdapters)에서 생성 된 코드를 피하는 것입니다.

내가 1 년 이상 전에 만든 DAL / BLL은 다른 사람이 생성 된 함수 중 일부를 활용하기 위해 사용하기 시작할 때까지 (내가 만든 것에 대해) 잘 작동했습니다.

http://wwww.asp.net 의 DAL / BLL 솔루션보다 훨씬 더 직관적이고 깨끗한 솔루션을 제공 할 것 같습니다 .

나만의 SQL Command C # DAL 코드 생성기를 만들려고 생각했지만 ORM은 더 우아한 솔루션처럼 보입니다.

— 댄 맥클레인
소스
2

쿼리 컴파일 및 테스트.

ORM의 도구가 향상됨에 따라 컴파일 시간 오류 및 테스트를 통해 쿼리의 정확성을 더 빨리 결정하는 것이 더 쉽습니다.

쿼리를 컴파일하면 개발자가 오류를 더 빨리 찾는 데 도움이됩니다. 권리? 권리. 이 컴파일은 개발자가 SQL 또는 SQL과 유사한 명령문의 문자열 대신 비즈니스 객체 또는 모델을 사용하여 코드에서 쿼리를 작성하기 때문에 가능합니다.

.NET에서 올바른 데이터 액세스 패턴을 사용하는 경우 메모리 컬렉션에서 쿼리 논리를 단위 테스트하기가 쉽습니다. 이렇게하면 데이터베이스에 액세스하거나 데이터베이스에 데이터를 설정하거나 완전한 데이터 컨텍스트를 스핀 업할 필요가 없기 때문에 테스트 실행 속도가 빨라집니다. [편집] 이것은 내가 생각했던 단위만큼 사실이 아닙니다. 메모리 테스트는 극복하기 어려운 과제 를 제시 할 수 있습니다 . 그러나 이러한 통합 테스트는 이전보다 작성하기가 더 쉽습니다. [/ EDIT]

이것은 몇 년 전 질문을 받았을 때보 다 오늘날 확실히 더 관련성이 있지만 내 경험이있는 Visual Studio 및 Entity Framework의 경우에만 해당 될 수 있습니다. 가능하면 자신의 환경을 플러그인하십시오.

— 척
소스
1

95 %의 시간 동안 SQL을 추상화하므로 팀의 모든 사람이 매우 효율적인 데이터베이스 특정 쿼리를 작성하는 방법을 알 필요가 없습니다.

— 자레드
소스
1

여기에는 좋은 점 (이동성, 개발 / 유지 보수 용이성, OO 비즈니스 모델링에 집중 등)이 많이 있다고 생각하지만 고객이나 경영진을 설득하려고 할 때 모두 사용하여 얼마나 많은 돈을 절약 할 수 있는지로 귀결됩니다. ORM .

일반적인 작업 (또는 다가올 더 큰 프로젝트)에 대해 몇 가지 추정을 수행하면 무시하기 어려운 전환에 대한 몇 가지 인수를 얻게됩니다.

— Anders Fjeldstad
소스
0

코드 스미스 템플릿을 사용하는 .net 계층

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

생성 될 수있는 무언가를 코딩하는 이유.

— 조보
소스
으. 우리는 대규모 상업 프로젝트에서 Net Tier를 사용했으며 사용하지 않는 것이 좋습니다. 문제는 구성 할 수 없다는 것입니다. Foo 및 Bar 개체를 쿼리하고 싶으십니까? 조인을 작성할 수 없으며 원하는 각 개체 유형에 대해 별도의 쿼리를 실행해야합니다. 이로 인해 데이터베이스에 대한 많은 호출이 발생하여 성능과 원 자성이 손상 될 수 있습니다. 나쁘다, 나쁘다, 나쁘다. 떨어져.
— 유다 가브리엘 희망 고
0

변경 사항이 들어올 때 얼마나 많은 시간 / 비용을 절약 할 수 있는지 설득하고 ORM 도구가이를 수행하므로 SQL을 다시 작성할 필요가 없습니다.

— zmf
소스
0

한 가지 단점은 ORM이 POJO에서 업데이트가 필요하다는 것입니다. 주로 스키마, 관계 및 쿼리와 관련이 있습니다. 따라서 모델 객체를 변경하지 않는 시나리오는 프로젝트 또는 b / w 클라이언트 및 서버에서 공유되기 때문일 수 있습니다. 따라서 이러한 경우에는 추가 노력이 필요한 두 수준으로 분할해야합니다.

저는 안드로이드 개발자이며 모바일 앱은 일반적으로 크기가 크지 않으므로 순수 모델과 orm 영향을받는 모델을 분리하려는이 추가 노력은 충분히 가치가 없어 보입니다.

나는 질문이 일반적인 질문이라는 것을 이해합니다. 하지만 모바일 앱도 일반 우산 안에 들어 있습니다.

— 샤일 렌드 라 싱 라자 왓
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.