ORM을 사용하지 않는 이유가 있습니까? [닫은]

견습 기간 동안 저는 주로 제가 직접 코딩하고 디자인 한 소규모 프로젝트에 NHibernate 를 사용했습니다 . 이제 더 큰 프로젝트를 시작하기 전에 데이터 액세스를 설계하는 방법과 ORM 레이어 사용 여부에 대해 논의했습니다. 나는 여전히 견습생이고 여전히 엔터프라이즈 프로그래밍의 초보자라고 생각하기 때문에 데이터베이스에 대한 객체 관계형 매퍼를 사용하면 개발을 상당히 쉽게 할 수 있다는 내 의견으로는 실제로 추진하려고하지 않았습니다. 개발팀의 다른 코더들은 저보다 훨씬 더 경험이 많기 때문에 그들이 말하는 대로만 할 것 같습니다. :-)

그러나 NHibernate 또는 유사한 프로젝트를 사용하지 않는 두 가지 주요 이유를 완전히 이해하지 못합니다.

1. SQL 쿼리를 사용하여 자신의 데이터 액세스 개체를 만들고 Microsoft SQL Server Management Studio에서 이러한 쿼리를 복사 할 수 있습니다.
2. ORM 디버깅은 어려울 수 있습니다.

따라서 물론 많은 SELECTs 등으로 데이터 액세스 계층을 구축 할 수 있지만 여기서는 자동 조인, 지연로드 프록시 클래스 및 테이블이 새 열을 얻거나 열이 발생하는 경우 유지 관리 노력이 줄어드는 이점을 놓칩니다. 이름이 변경되었습니다. (다수의 업데이트 SELECT, INSERT및 UPDATE매핑 설정을 업데이트 할 가능성이 비즈니스 클래스와 DTO들 리팩토링 대 쿼리.)

또한 NHibernate를 사용하면 프레임 워크를 잘 모르면 예기치 않은 문제가 발생할 수 있습니다. 예를 들어 자동으로 유효성을 검사 할 문자열의 길이를 설정 한 Table.hbm.xml을 신뢰하는 것이 될 수 있습니다. 그러나 "간단한"SqlConnection 쿼리 기반 데이터 액세스 계층에서 유사한 버그를 상상할 수도 있습니다.

마지막으로, 위에서 언급 한 주장이 중요한 데이터베이스 기반 엔터프라이즈 애플리케이션에 ORM을 사용하지 않는 좋은 이유입니까? 그들이 놓친 다른 주장이 있습니까?

(나는 이것이 팀워크가 필요한 최초의 "대형".NET / C # 기반 애플리케이션이라고 생각한다고 덧붙여 야 할 것입니다. 단위 테스트 또는 지속적인 통합과 같이 Stack Overflow에서 매우 평범한 것으로 보이는 모범 사례는 그렇지 않습니다. -지금까지 여기에 존재합니다.)

최근 몇 년 동안 ORM이 폭발적으로 성장하고 있으며 경험이 많은 동료들은 여전히 ​​"모든 데이터베이스 호출이 저장 프로 시저를 통해 이루어져야한다"는 생각을하고있을 수 있습니다.

ORM이 디버깅을 더 어렵게 만드는 이유는 무엇입니까? 저장된 proc 또는 ORM에서 가져온 것과 동일한 결과를 얻을 수 있습니다.

제가 ORM에 대해 생각할 수있는 유일한 진짜 단점은 보안 모델이 약간 덜 유연하다는 것입니다.

편집 : 귀하의 질문을 다시 읽었으며 쿼리를 인라인 SQL에 복사하여 붙여 넣는 것 같습니다. 이로 인해 보안 모델이 ORM과 동일 해 지므로 ORM에 비해이 접근 방식보다 이점이 전혀 없습니다. 매개 변수화되지 않은 쿼리를 사용하는 경우 실제로 보안 위험이 있습니다.

짧은 대답은 그렇습니다. 정말 좋은 이유가 있습니다. 실제로 ORM을 사용할 수없는 경우가 있습니다.

예를 들어, 저는 대기업 금융 기관에서 일하고 있으며 많은 보안 지침을 따라야합니다. 우리에게 부과되는 규칙과 규정을 충족하기 위해 감사를 통과하는 유일한 방법은 저장 프로 시저 내에서 데이터 액세스를 유지하는 것입니다. 이제 어떤 사람들은 그것이 멍청하다고 말할지 모르지만 솔직히 그렇지 않습니다. ORM 도구를 사용하면 도구 / 개발자가 원하는 것을 삽입, 선택, 업데이트 또는 삭제할 수 있습니다. 저장 프로시 저는 특히 클라이언트 데이터를 처리하는 환경에서 훨씬 더 많은 보안을 제공합니다. 이것이 고려할 가장 큰 이유라고 생각합니다. 보안.

ORM의 스윗 스팟

ORM은 적용 가능한 쿼리의 95 % 이상을 자동화하는 데 유용합니다. 그들의 특별한 강점은 강력한 개체 모델 아키텍처와 그 개체 모델과 잘 어울리는 데이터베이스가있는 응용 프로그램이 있다는 것입니다. 새로운 빌드를하고 있고 팀에 강력한 모델링 기술이 있다면 ORM으로 좋은 결과를 얻을 수 있습니다.

손으로 더 잘 수행되는 몇 가지 쿼리가있을 수 있습니다. 이 경우이를 처리하기 위해 몇 가지 저장 프로 시저를 작성하는 것을 두려워하지 마십시오. 여러 DBMS 플랫폼에 앱을 이식하려는 경우에도 데이터베이스 종속 코드는 소수입니다. 지원하려는 플랫폼에서 애플리케이션을 테스트해야한다는 점을 염두에두고 일부 저장 프로 시저에 대한 약간의 추가 포팅 노력은 TCO에 큰 차이를 만들지 않습니다. 첫 번째 근사치로 98 %의 이식성은 100 %의 이식성과 동일하며 ORM의 한계를 극복하기 위해 복잡하거나 성능이 저조한 솔루션보다 훨씬 낫습니다.

저는 이전의 접근 방식이 매우 큰 (직원 수 100 년) J2EE 프로젝트에서 잘 작동하는 것을 보았습니다.

ORM이 가장 적합하지 않을 수있는 곳

다른 경우에는 ORM보다 응용 프로그램에 더 적합한 접근 방식이있을 수 있습니다. Fowler의 엔터프라이즈 애플리케이션 아키텍처 패턴에는 이에 대한 다양한 접근 방식을 카탈로그 화하는 데 상당히 좋은 작업을 수행하는 데이터 액세스 패턴에 대한 섹션이 있습니다. ORM이 적용되지 않을 수있는 상황에 대해 본 몇 가지 예는 다음과 같습니다.

• 저장 프로 시저의 실질적인 레거시 코드 기반이있는 애플리케이션에서 기능 지향 (기능 언어와 혼동하지 말 것) 데이터 액세스 계층을 사용하여 기존 sproc을 래핑 할 수 있습니다. 이렇게하면 기존 (따라서 테스트 및 디버깅 된) 데이터 액세스 계층 및 데이터베이스 디자인을 재사용 할 수 있습니다. 이는 종종 상당한 개발 및 테스트 노력을 나타내며 데이터를 새 데이터베이스 모델로 마이그레이션해야하는 시간을 줄여줍니다. 레거시 PL / SQL 코드베이스를 중심으로 Java 레이어를 래핑하거나 웹 인터페이스를 사용하여 리치 클라이언트 VB, Powerbuilder 또는 Delphi 앱을 대상으로 다시 지정하는 것은 종종 매우 좋은 방법입니다.

• 변형은 OR 매핑에 반드시 적합하지 않은 데이터 모델을 상속하는 곳입니다. 예를 들어 외부 인터페이스에서 데이터를 채우거나 추출하는 인터페이스를 작성하는 경우 데이터베이스를 사용하는 것이 더 나을 수 있습니다.

• 특히 2 단계 커밋으로 복잡한 분산 트랜잭션을 사용하는 경우 시스템 간 데이터 무결성이 중요한 금융 응용 프로그램 또는 기타 유형의 시스템입니다. ORM이 지원할 수있는 것보다 트랜잭션을 더 잘 관리해야 할 수도 있습니다.

• 실제로 데이터베이스 액세스를 조정하려는 고성능 애플리케이션. 이 경우 낮은 수준에서 작업하는 것이 좋습니다.

• '충분히 좋은'ADO.Net과 같은 기존 데이터 액세스 메커니즘을 사용하고 있으며 플랫폼을 잘 사용하는 상황은 ORM이 가져 오는 것보다 더 큰 이점이 있습니다.

• 때로는 데이터가 데이터 일 수 있습니다. 예를 들어 애플리케이션이 '객체'가 아닌 '트랜잭션'으로 작업하고 있으며 이것이 도메인에 대한 합리적인보기 일 수 있습니다. 이에 대한 예는 구성 가능한 분석 필드가있는 트랜잭션이있는 재무 패키지 일 수 있습니다. 애플리케이션 자체는 OO 플랫폼에서 빌드 될 수 있지만 단일 비즈니스 도메인 모델에 묶여 있지 않으며 GL 코드, 계정, 문서 유형 및 6 개 이상의 분석 필드를 인식하지 못할 수 있습니다. 이 경우 애플리케이션은 비즈니스 도메인 모델을 인식하지 못하며 개체 모델 (원장 구조 자체를 넘어서)은 애플리케이션과 관련이 없습니다.

먼저 ORM을 사용한다고해서 코드를 테스트하기가 더 쉬워지지는 않으며 지속적 통합 장면에서 반드시 이점을 제공하지도 않습니다.

제 경험상 ORM을 사용하면 개발 속도를 높일 수 있지만 해결해야 할 가장 큰 문제는 다음과 같습니다.

1. 코드 테스트
2. 코드 유지

이에 대한 해결책은 다음과 같습니다.

1. 코드를 테스트 가능하게 만들기 ( SOLID 원칙 사용)
2. 가능한 한 많은 코드에 대해 자동화 된 테스트 작성
3. 가능한 한 자주 자동 테스트 실행

귀하의 질문에 대해, 귀하가 나열한 두 가지 반대는 다른 무엇보다 무지처럼 보입니다.

손으로 SELECT 쿼리를 작성할 수 없다는 것은 (이것이 복사-붙여 넣기가 필요한 이유라고 생각합니다) SQL 교육이 긴급히 필요하다는 것을 나타냅니다.

ORM을 사용하지 않는 데에는 두 가지 이유가 있습니다.

1. 회사 정책에 의해 엄격히 금지되어 있습니다 (이 경우 다른 곳에서 일할 것입니다)
2. 이 프로젝트는 매우 데이터 집약적이며 공급 업체별 솔루션 (예 : BulkInsert)을 사용하는 것이 더 합리적입니다.

ORM (특히 NHibernate)에 대한 일반적인 거부는 다음과 같습니다.

1. 속도

   ORM을 사용하는 것이 직접 코딩 된 데이터 액세스보다 느릴 이유가 없습니다. 실제로 캐싱 및 최적화 기능이 내장되어 있기 때문에 더 빠를 수 있습니다. 좋은 ORM은 스키마를 최적화 할 수있는 반복 가능한 쿼리 세트를 생성합니다. 좋은 ORM은 다양한 가져 오기 전략을 사용하여 관련 데이터를 효율적으로 검색 할 수도 있습니다.

2. 복잡성

   복잡성과 관련하여 ORM을 사용한다는 것은 코드가 적다는 것을 의미하며 일반적으로 복잡성이 적다는 것을 의미합니다. 손으로 쓴 (또는 코드 생성) 데이터 액세스를 사용하는 많은 사람들은 "저수준"데이터 액세스 라이브러리 (예 : ADO.Net 용 도우미 메서드 작성)를 통해 자체 프레임 워크를 작성합니다. 이것들은 더 복잡한 것과 같지만 더 나쁜 것은 거의 문서화되거나 잘 테스트되지 않는다는 것입니다.
   특별히 NHibernate를보고 있다면 Fluent NHibernate 및 Linq To NHibernate와 같은 도구도 학습 곡선을 부드럽게합니다.

전체 ORM 논쟁에 대해 저를 이해하게하는 것은 ORM을 사용하는 것이 너무 힘들거나 느릴 것이라고 주장하는 동일한 사람들이 Linq To Sql 또는 Typed Datasets를 사용하는 것을 행복하게 생각하는 동일한 사람들이라는 것입니다. Linq To Sql이 올바른 방향으로 나아가는 큰 발걸음이긴하지만 일부 오픈 소스 ORM이있는 곳은 여전히 ​​광년 뒤에 있습니다. 그러나 Typed Datasets와 Linq To Sql 모두에 대한 프레임 워크는 여전히 매우 복잡하며이를 사용하여 (Table = Class) + (기본 CRUD)를 너무 많이 사용하는 것은 어리석은 일입니다.

내 조언은 하루가 끝날 때 ORM을 얻을 수없는 경우 데이터 액세스가 나머지 코드와 분리되어 있는지 확인하고 Gang Of Four의 코딩 조언을 따라야한다는 것입니다. 인터페이스. 또한 연결을 수행하기 위해 Dependancy Injection 프레임 워크를 가져옵니다.

(폭언은 어때?)

Hibernate와 같은 ORM 도구가 신의 선물 인 광범위한 공통 문제가 있으며 장애가되는 몇 가지 문제가 있습니다. 나는 그것이 무엇인지 알만큼 당신의 프로젝트에 대해 충분히 알지 못합니다.

Hibernate의 강점 중 하나는 말을 3 번만 할 수 있다는 것입니다. 모든 속성은 클래스, .hbm.xml 파일 및 데이터베이스에서 언급됩니다. SQL 쿼리를 사용하면 속성이 클래스, 데이터베이스, select 문, 삽입 문, 업데이트 문, delete 문, SQL 쿼리를 지원하는 모든 마샬링 및 마샬링 해제 코드에 있습니다! 이것은 지저분해질 수 있습니다. 반면에 어떻게 작동하는지 알고 있습니다. 디버그 할 수 있습니다. 타사 도구의 내부에 묻히지 않고 자체 지속성 레이어에 문제가 없습니다.

Hibernate는 Spolsky의 Leaky Abstractions의 법칙에 대한 포스터가 될 수 있습니다. 구타의 길을 조금 벗어나면 도구의 내부 작업에 대해 자세히 알아야합니다. 몇 분 만에 SQL을 수정할 수 있다는 것을 알고 있으면 매우 성 가실 수 있지만 대신 dang 도구를 사용하여 합리적인 SQL을 생성하는 데 몇 시간을 소비합니다. 디버깅은 때때로 악몽이지만 거기에 가보지 않은 사람들을 설득하기는 어렵습니다.

편집 : NHibernate에 대해 돌아 보지 않고 SQL 쿼리를 제어하려는 경우 iBatis.NET을 살펴볼 수 있습니다.

편집 2 :하지만 여기에 큰 위험 신호가 있습니다. "단위 테스트 또는 지속적인 통합과 같이 Stack Overflow에서 매우 평범한 것으로 보이는 모범 사례는 지금까지 여기에 존재하지 않습니다." 그렇다면이 "경험이있는"개발자들은 개발 경험이 무엇입니까? 직업 안정? 당신이 그 분야에 특별히 관심이없는 사람들 사이에있는 것 같으니 그들이 당신의 관심을 죽이게하지 마세요. 균형이 필요합니다. 싸워라.

나는 ORM을 사용하지 않는 것이 매우 성공적이었던 한 프로젝트에서 일했습니다. 그것은 프로젝트였습니다

1. 처음부터 수평으로 확장되어야 했어
2. 빨리 개발 되어야만했다
3. 비교적 단순한 도메인 모델을 가졌습니다.

수평으로 분할 된 구조에서 NHibernate를 작동시키는 데 걸리는 시간은 우리의 분할 체계를 인식하는 매우 간단한 데이터 매퍼를 개발하는 데 걸린 시간보다 훨씬 더 길었을 것입니다.

그래서 제가 ORM에서 작업 한 프로젝트의 90 %는 귀중한 도움이되었습니다. 그러나 ORM을 사용하지 않는 것이 최고라고 볼 수있는 매우 구체적인 상황이 있습니다.

먼저 ORM이 제대로 통합되면 개발 생활을 더 쉽게 만들 수 있지만 ORM이 실제로 명시된 요구 사항과 목표를 달성하는 데 방해가되는 몇 가지 문제가 있습니다.

성능 요구 사항이 높은 시스템을 설계 할 때 시스템 성능을 향상시키는 방법을 찾는 데 종종 어려움을 겪는다는 사실을 알게되었습니다. 많은 경우 쓰기 성능 프로필이 많은 솔루션으로 끝납니다 (데이터를 읽는 것보다 훨씬 더 많은 데이터를 쓰고 있음을 의미합니다). 이러한 경우에는 성능 목표 (OLAP가 아닌 OLTP)를 달성하기 위해 데이터베이스 플랫폼이 제공하는 기능을 활용하고 싶습니다. 따라서 SQL Server를 사용하고 있고 작성할 데이터가 많다는 것을 알고 있다면 대량 삽입을 사용하지 않는 이유는 무엇입니까 ... 글쎄요, 이미 발견 하셨겠지만 대부분의 ORMS (나는 단 하나라도) 대량 삽입과 같은 플랫폼 특정 이점을 활용할 수있는 능력이 없습니다.

ORM 기술과 비 ORM 기술을 혼합 할 수 있다는 것을 알아야합니다. ORM이 귀하의 요구 사항을 지원할 수없는 소수의 엣지 케이스가 있으며 이러한 경우를 해결해야합니다.

50000000 레코드를 업데이트해야 할 때. 깃발 등을 설정하십시오.

스토어드 프로 시저 또는 원시 SQL 명령 을 호출 하지 않고 ORM 을 사용하여이를 수행하십시오 .

업데이트 1 : 필드가 몇 개만있는 레코드 하나를 검색해보십시오. (매우 "넓은"테이블이있을 때). 또는 스칼라 결과. ORM도 이것에 짜증이납니다.

업데이트 2 : EF 5.0 베타가 일괄 업데이트를 약속하는 것 같지만 이것은 매우 뜨거운 소식입니다 (2012, 1 월).

사소하지 않은 데이터베이스 기반 엔터프라이즈 애플리케이션의 경우 실제로 ORM을 사용하지 않는 것은 정당화되지 않습니다.

제쳐두고 기능 :

• ORM을 사용하지 않음으로써 대규모 커뮤니티 또는 상당한 자원을 보유한 회사에서 이미 반복적으로 해결 한 문제를 해결하는 것입니다.
• ORM을 사용하면 데이터 액세스 계층의 핵심 부분이 해당 커뮤니티 또는 회사의 디버깅 노력으로부터 혜택을받습니다.

인수에 대한 관점을 제시하려면 ADO.NET을 사용하는 것보다 테이블 형식 데이터 스트림을 직접 구문 분석하는 코드를 작성하는 것의 이점을 고려하십시오.

ORM을 사용하는 방법에 대한 무지가 ORM에 대한 개발자의 경멸을 정당화하는 것을 보았습니다. 예를 들어 : eager loading (당신이 언급하지 않은 것을 알아 차 렸습니다). 고객과 모든 주문 및 모든 주문 세부 항목을 검색한다고 가정 해보십시오. 지연로드에만 의존하는 경우 "ORM이 느립니다."라는 의견으로 ORM 경험에서 벗어날 수 있습니다. 즉시로드를 사용하는 방법을 배우면 5 줄의 코드로 2 분 안에 동료가 구현하는 데 반나절이 걸리는 작업을 수행하게됩니다. 데이터베이스에 대한 쿼리 한 번과 결과를 개체 계층에 바인딩하는 것입니다. 또 다른 예는 페이징을 구현하기 위해 SQL 쿼리를 수동으로 작성하는 어려움입니다.

ORM 사용에 대한 가능한 예외는 해당 애플리케이션이 특수 비즈니스 로직 추상화를 적용하도록 설계된 ORM 프레임 워크이고 여러 프로젝트에서 재사용되도록 설계된 경우입니다. 그러나 그럴 경우에도 이러한 추상화를 통해 기존 ORM을 향상시켜보다 빠르게 채택 할 수 있습니다.

선임 팀원의 경험이 컴퓨터 과학 진화의 반대 방향으로 끌리지 않도록하십시오. 저는 23 년 동안 전문적으로 발전해 왔고, 상수 중 하나는 구식의 새로운 것에 대한 경멸입니다. ORM은 C 언어가 어셈블리에 해당하는 것처럼 SQL에 해당하며 C ++ 및 C #에 해당하는 기능이 진행 중임을 확신 할 수 있습니다. 새 학교 코드 한 줄은 구식 학교 20 줄과 같습니다.

: 난 당신이 더 큰 시스템에서 작동 어쩌면 때 대신 ORM의 CodeSmith 같은 코드 생성 도구를 사용할 수 있다고 생각 ... 나는 최근에 발견 협력자 프레임 워크 , 비즈니스 엔티티, 매퍼, 게이트웨이를 생성 또한 SQL 서버 저장 프로 시저를 생성하고 lazyload와 C #의 모든 것 ... 확인해보세요 ... 아르헨티나의 한 팀이 작성했습니다 ...

전체 데이터 액세스 레이어를 코딩하고 ORM을 사용하는 중간에 있다고 생각합니다.

개인적으로 저는 (최근까지) ORM 사용에 반대했으며 모든 SQL 명령을 캡슐화하는 데이터 액세스 계층을 작성하는 데 익숙했습니다. ORM에 대한 주된 반대는 ORM 구현이 정확한 SQL을 작성하는 데 신뢰하지 않는다는 것입니다. 그리고 내가 보았던 ORM (대부분 PHP 라이브러리)으로 판단하면 내가 완전히 옳았다 고 생각합니다.

이제 내 웹 개발의 대부분은 Django를 사용하고 있으며 포함 된 ORM이 정말 편리하다는 것을 알았습니다. 데이터 모델이 첫 번째 용어로 표현되고 나중에 SQL로만 표현되기 때문에 내 요구에 완벽하게 작동합니다. 나는 그것을 능가하는 것이 너무 어렵지 않을 것이며 손으로 작성한 SQL로 보완 할 필요가있을 것이라고 확신합니다. 그러나 CRUD 액세스의 경우 충분합니다.

나는 NHibernate에 대해 모른다. 그러나 나는 당신이 필요로하는 대부분의 것에 대해 "충분히 좋은"것 같아요. 그러나 다른 코더들이 그것을 신뢰하지 않는다면; 모든 데이터 관련 버그에 대한 주요 용의자가되어 검증을 더 지루하게 만듭니다.

직장에 점진적으로 도입하고 간단한 데이터 액세스와 같은 작은 '명백한'애플리케이션에 먼저 집중할 수 있습니다. 잠시 후 프로토 타입에 사용될 수 있으며 교체되지 않을 수 있습니다.

OLAP 데이터베이스 (예 :보고 / 분석에 사용되는 정적, 읽기 전용 데이터 등) 인 경우 ORM 프레임 워크를 구현하는 것은 적절하지 않습니다. 대신 저장 프로 시저와 같은 데이터베이스의 기본 데이터 액세스 기능을 사용하는 것이 좋습니다. ORM은 트랜잭션 (OLTP) 시스템에 더 적합합니다.

ORM을 사용하지 않는 데에는 많은 이유가 있다고 생각합니다. 무엇보다도, 저는 .NET 개발자이고 멋진 .NET 프레임 워크가 이미 제공 한 것을 고수하고 싶습니다. 내가 필요한 모든 것을 수행합니다. 이렇게하면 더 표준적인 접근 방식을 유지하므로 길을 따라 같은 프로젝트에서 작업하는 다른 개발자가 거기에있는 것을 선택하고 실행할 수있는 가능성이 훨씬 더 높습니다. Microsoft에서 이미 제공하는 데이터 액세스 기능은 상당히 풍부하므로 폐기 할 이유가 없습니다.

저는 10 년 동안 전문 개발자로 일했으며 수백만 달러 이상의 프로젝트를 성공적으로 이끌 었으며 데이터베이스로 전환하는 데 필요한 애플리케이션을 한 번도 작성한 적이 없습니다. 왜 고객이이 작업을 수행하기를 원하십니까? 신중하게 계획하고 필요한 항목에 적합한 데이터베이스를 선택하고이를 고수하십시오. 개인적으로 SQL Server는 내가해야 할 일을 할 수있었습니다. 쉽고 훌륭하게 작동합니다. 최대 10GB 데이터를 지원하는 무료 버전도 있습니다. 아, 그리고 .NET에서 훌륭하게 작동합니다.

저는 최근에 ORM을 데이터 레이어로 사용하는 여러 프로젝트에서 작업을 시작해야했습니다. 나는 그것이 나쁘다고 생각하고 아무런 이유없이 사용법을 배워야했습니다. 고객이 데이터베이스를 변경해야하는 매우 드문 상황에서 ORM 제공 업체를 속이는 것보다 짧은 시간에 전체 데이터 레이어를 쉽게 재 작업 할 수있었습니다.

솔직히 ORM의 실제 용도가 하나 있다고 생각합니다. SAP와 같은 애플리케이션을 구축하는 경우 실제로 여러 데이터베이스에서 실행할 수있는 기능이 필요합니다. 그렇지 않으면 솔루션 제공 업체로서이 응용 프로그램이이 데이터베이스에서 실행되도록 설계되었으며 그게 방법이라고 클라이언트에게 말합니다. 다시 한 번, 10 년 동안 수많은 응용 프로그램을 적용한 후에도 이것은 문제가되지 않았습니다.

그렇지 않으면 ORM은 덜 이해하지 못하는 개발자를위한 것이라고 생각하며, 앱에서 사용하는 타사 도구가 더 멋질수록 앱이 더 좋아질 것이라고 생각합니다. 나는 이런 일을 열심히하는 괴짜들에게 맡기고, 그 동안 모든 개발자가 즉시 생산성을 발휘할 수있는 훨씬 더 훌륭한 소프트웨어를 개발할 것이다.

런타임 성능은 제가 생각할 수있는 유일한 단점이지만 ORM이 개발 / 테스트 등을 절약 할 수있는 시간에 대한 공정한 절충 이상이라고 생각합니다. 그리고 대부분의 경우 데이터 병목 지점을 찾고 객체 구조를보다 효율적으로 변경할 수 있어야합니다.

이전에 Hibernate를 사용 해본 적이 없지만 몇 가지 "기성품"ORM 솔루션에서 알아 차린 한 가지는 유연성이 부족하다는 것입니다. 나는 이것이 당신이 무엇과 함께 가고 무엇을 해야하는지에 달려 있다고 확신합니다.

ORM에는 두 가지 측면이 있습니다. 첫째, 다른 사람이 작성한 코드이며, 때로는 폐쇄 된 소스, 때로는 오픈 소스이지만 범위가 엄청납니다. 둘째, 그들은 데이터를 복사합니다.

첫 번째 문제는 두 가지 문제를 일으 킵니다. 외부인 코드에 의존하고 있습니다. 우리 모두이 일을하지만 그렇게하는 선택을 가볍게해서는 안됩니다. 그리고 그것이 당신이 필요로하는 것을하지 않는다면? 언제 이것을 발견 할 것인가? 당신은 당신의 ORM이 당신을 위해 그리는 상자 안에 살고 있습니다.

두 번째 문제는 2 단계 커밋 중 하나입니다. 관계형 데이터베이스가 개체 모델에 복사되고 있습니다. 개체 모델을 변경하면 데이터베이스가 업데이트됩니다. 이것은 2 단계 커밋이며 디버깅하기 가장 쉬운 것은 아닙니다.

ORM의 단점 목록을 위해이 읽기를 제안합니다.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

제 자신에게는 제가 작성한 대부분의 응용 프로그램에 ORM이 매우 유용하다는 것을 알았습니다!

/ Asger

내가 Hibernate에서 경험 한 것은 그것의 의미가 미묘하고 문제가있을 때 내부에서 무엇이 잘못되었는지 이해하기가 조금 어렵다는 것입니다. 나는 종종 Criteria로 시작한 후 약간 더 많은 유연성이 필요하고 HQL이 필요하고 나중에 원시 SQL이 필요하다는 것을 알게 된 친구로부터 들었습니다 (예를 들어, Hibernate에는 Union AFAIK가 없습니다).

또한 ORM을 사용하면 사람들은 기존 매핑 / 모델을 쉽게 남용하는 경향이 있으며, 이로 인해 초기화되지 않은 속성이 많은 개체가 있습니다. 따라서 쿼리 후 Hibernate 트랜잭션 내부에서 추가 데이터 가져 오기를 수행하여 잠재적 인 속도 저하를 초래합니다. 또한 슬프게도 하이버 네이트 모델 객체가 뷰 아키텍처 계층으로 유출되는 경우가 있으며 LazyInitializationExceptions가 표시됩니다.

ORM을 사용하려면 정말로 이해해야합니다. 안타깝게도 쉽지만 쉽지 않다는 인상을받습니다.

대답 자체가 아니라 최근에들은 인용문을 다시 말하고 싶습니다. "좋은 ORM은 예티와 같습니다. 모두가 하나에 대해 이야기하지만 아무도 보지 못합니다."

ORM에 손을 댈 때마다 저는 대개 해당 ORM의 문제 / 제한 사항으로 어려움을 겪고 있습니다. 결국, 그것은 내가 원하는 것을 수행하고 그 형편없는 문서의 어딘가에 쓰여졌지만 나는 결코 얻을 수 없을 것입니다. nhibernate를 사용하고 postgresql에 대한 유창한 nhibernate를 사용하는 사람은 내가 겪은 일을 이해할 것입니다. "이 코드는 내 통제하에 있지 않습니다"라는 끊임없는 느낌은 정말 짜증납니다.

나는 손가락을 가리 키거나 그들이 나쁘다고 말하지 않지만, 하나의 표현으로 CRUD를 자동화하기 위해 내가 무엇을 줄지 생각하기 시작했습니다. 요즘에는 ORM을 적게 사용해야한다고 생각합니다. 최소한 db 작업을 가능하게하는 솔루션을 만들거나 찾아야합니다. 그러나 그것은 나뿐입니다. 나는이 ORM 분야에서 어떤 것이 잘못되었다고 생각하지만, 나는 그것을 표현할만큼 충분히 숙련되지 않았습니다.

ORM을 사용하는 것이 여전히 좋은 생각이라고 생각합니다. 특히 당신이주는 상황을 고려하면. 귀하의 게시물에 따르면 db 액세스 전략에 관해서는 더 경험이 많으며 ORM을 사용하여 가져올 것입니다.

쿼리를 복사하고 붙여넣고 텍스트에 하드 코딩하는 것은 유연성을 제공하지 않기 때문에 # 1에 대한 주장은 없습니다. 그리고 # 2의 경우 대부분의 orm은 원래 예외를 래핑하고 생성 된 쿼리를 추적 할 수 있으므로 디버깅도 로켓 과학이 아닙니다.

검증과 관련하여 ORM을 사용하면 일반적으로 내장 된 검증 외에도 검증 전략을 개발하는 데 훨씬 더 쉽게 시간을 할애 할 수 있습니다.

자신 만의 프레임 워크를 작성하는 것은 힘들 수 있으며 종종 누락되는 경우가 많습니다.

편집 : 한 가지 더 요점을 만들고 싶었습니다. 귀사가 ORM 전략을 채택하면 사용 및 구현에 대한 지침과 관행을 개발하고 모든 사람이 선택한 프레임 워크에 대한 지식을 더욱 강화하여 제기 한 문제 중 하나를 완화함으로써 가치를 더욱 향상시킬 수 있습니다. 또한 상황이 발생할 때 효과가있는 것과 효과가없는 것을 배우고 결국 많은 시간과 노력을 절약 할 수 있습니다.

모든 ORM, 심지어 "좋은"ORM은 소프트웨어가 응용 프로그램 계층과 데이터 저장소 사이에서 데이터를주고받는 데 사용하는 기본 메커니즘과 관련된 특정 수의 가정과 함께 제공됩니다.

적당히 정교한 애플리케이션의 경우 이러한 가정을 해결하는 데 일반적으로 데이터 쿼리 및 수동으로 새 엔터티 인스턴스화와 같은보다 간단한 솔루션을 작성하는 것보다 더 많은 시간이 걸립니다.

특히, 코드를 다운로드 할 때 ORM이 제공 한 편리한 예제의 범위를 벗어난 다중 열 키 또는 기타 적당히 복잡한 관계를 사용하자마자 문제가 발생할 가능성이 있습니다.

특정 유형의 애플리케이션, 특히 매우 많은 수의 데이터베이스 테이블 또는 동적으로 생성 된 데이터베이스 테이블이있는 애플리케이션의 경우 ORM의 자동 마법 프로세스가 유용 할 수 있음을 인정합니다.

그렇지 않으면 ORM과 함께 지옥에. 나는 이제 그것들이 기본적으로 유행이라고 생각합니다.