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

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

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

SQL 쿼리를 사용하여 자신의 데이터 액세스 개체를 만들고 Microsoft SQL Server Management Studio에서 이러한 쿼리를 복사 할 수 있습니다.
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을 사용하면 개발 속도를 높일 수 있지만 해결해야 할 가장 큰 문제는 다음과 같습니다.

코드 테스트
코드 유지

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

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

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

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

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

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

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

속도

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

복잡성과 관련하여 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을 사용하지 않는 것이 매우 성공적이었던 한 프로젝트에서 일했습니다. 그것은 프로젝트였습니다

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

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

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

답변

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

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

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