ORM은 안티 패턴입니까? [닫은]

나는 ORM과 그 장단점에 대해 동료와 매우 자극적이고 면담을 가졌습니다. 제 생각에 ORM은 가장 드문 경우에만 유용합니다. 적어도 내 경험으로는.

그러나 나는 지금 내 자신의 주장을 열거하고 싶지 않다. ORM에 대해 어떻게 생각하십니까? 장단점은 무엇입니까?

객체 지향 각도에서 관계형 데이터베이스에 접근하려고 할 때 상당히 크고 다양한 개념 및 기술적 어려움이 있습니다. 이러한 어려움을 통칭하여 객체 관계형 임피던스 불일치라고 하며 관련 Wikipedia 기사 는 매우 유익합니다. 이 기사는 꽤 몇 가지를 나타내며 여기에 그것들을 설명하는 합리적인 방법은 없습니다. 일반적인 아이디어를 제공하기 위해 다음과 같이 카탈로그 화되어 있습니다.

• 불일치
  • 객체 지향 개념
  • 데이터 타입 차이
  • 구조적 및 무결성 차이
  • 조작상의 차이점
  • 거래 차이
• 임피던스 불일치 해결
  • 최소화
  • 대체 아키텍처
  • 보상
• 투쟁
• 철학적 차이점

나는 당신이 기사를 읽는 데 시간이 걸리면 ORM이 때로는 반 패턴으로 묘사된다는 사실은 실제로 불가피하다는 것을 이해할 것입니다. 두 도메인은 서로 다르기 때문에 하나를 다른 것으로 취급하는 접근 방식은 기본적으로 안티 패턴입니다.

그러나 나는이 용어가 본질적으로 서로 다른 두 영역 사이의 다리 역할을하는 모든 것에 적용되어야한다고 생각하지 않습니다. 패턴을 안티 패턴으로 라벨링하는 것은 도메인 내에서만 의미가 있습니다. 따라서 안티 패턴인지 아닌지에 대한 질문은 관련이 없습니다.

그러나 유용합니까? 예 ORM은 가장 유용한 안티 패턴 중 하나입니다. 프로젝트에서 데이터베이스를 교체해야하는 실제 상황에 처한 경우에만 이유를 이해할 수 있습니다. 또는 동일한 데이터베이스의 다른 버전으로 업그레이드 할 수도 있습니다. ORM은 실제로 필요할 때만 완전히 이해하는 것 중 하나입니다.

물론 모든 것이 유용한 것처럼 ORM은 남용하기 쉽습니다. 작업중 인 데이터베이스에 대한 모든 것을 알아야 할 필요가 있다고 생각되면 다시 돌아와서 당신을 물 것입니다. 단단한.

마지막으로, "ActiveRecord 패턴이 SOLID 설계 원칙을 따르거나 장려합니까?"에 관한 또 다른 답변 중 하나를 부끄럽게 연결하겠습니다. 질문은 "반 패턴입니까?"보다 훨씬 관련성이 높은 질문입니다.

이것은 "파워 드릴이 안티 패턴입니까?"라고 묻는 것과 유사합니다. ORM은 도구 상자에서 좋은 위치를 차지하여 상용구 코드를 줄였으며 필요한 경우 여전히 사용자 지정 SQL을 사용할 수 있습니다. 안티 패턴이라면 어떤 패턴에 반하는가?

내 대답은 아니요, 당신의 삶을 훨씬 쉽게하고 코드를 이해하기 쉽게 만드는 성숙한 ORM이 많이 있습니다. 이것은 어떤 식 으로든 SQL을 이해할 필요가 없다는 것을 의미합니다.

마틴 파울러 (Martin Fowler)가 처음으로 패턴이라고 부르며 거의 모든 현대 프로그래밍 언어로 받아 들여진 "반 패턴 (anti-pattern)"이라고 부르는 것을 주저 할 것입니다. ( ActiveRecord에 대한 Wikipedia 기사를 참조하십시오 .)

좋은 ORM은 프로젝트에서 훨씬 적은 코드 (및 훨씬 적은 반복)로 이어질 수 있으며, 원래 코드의 양만큼 버그와 밀접한 관련이있는 것은 없습니다.

ORM은 일반적으로 데이터베이스 작업을위한 가장 일반적인 사용 사례를 처리하도록 설계되었습니다. 복잡한 쿼리는 여전히 명시 적으로 작성해야합니다. 그러나 모든 데이터베이스 상호 작용에 대해 명시 적 쿼리를 작성하는 것이 좋습니다. 대부분의 경우 시간 낭비입니다.

SQL을 배우는 대신 ORM을 사용하는 것은 매우 나쁜 생각입니다. 생성되는 SQL의 종류를 정확히 모르는 경우 N + 1 문제와 최적화 방법을 이해하지 못하면 확실히 좋은 것보다 더 많은 해를 입힐 수 있습니다. 나는 ORM을 사용하여 훨씬 더 생산적이라고 느낍니다. Rails ActiveRecord를 선호합니다.이 데이터베이스는 데이터베이스가 없다고 주장하지 않고 SQL 만 작성해도 방해가되지 않습니다. 나는 어떤 사람들은 자신이하고있는 일에 대한 깊은 이해없이 자신이보고있는 관용구를 너무 깊게 믿어도된다고 걱정합니다.

내 경험 : Linq2NHibernate와 함께 NHibernate를 사용하고 있습니다.

장점 :

• 그것은 "매직 스트링"을 제거하거나 적어도 한 번만 배치 할 수있는 장소를 제공합니다.
• 전체 OO 패러다임에서 일할 수 있습니다.
• 코드가 읽기 쉽다
• 위에 작성된 코드는 변경하기가 더 쉽습니다.
• 2 개의 별도 리포지토리를 유지 관리하지 않고도 실제 관계형 데이터베이스를 교체 할 수 있습니다 (드물게 수행되지만 필요한 경우 큰 이점이됩니다).

단점 :

• 코드는하기 어렵 쓰기 때문에,
• 충분한 추상화가 아닙니다. 백그라운드에서 수행하는 작업에 여전히 친숙해야합니다.

나는 그것이 대부분의 사람들이 처음에 바라는 약속에 미치지 못한다고 말할 것이다. 나는 그것이 반 패턴이라고 말하는 누군가를 비난하지 않을 것입니다. 필자의 경우 Linq2NHibernate 쿼리가 실제로 작동하는지 확인하려면 여전히 SQLite 데이터베이스에 대해 통합 테스트를 수행해야한다는 것을 알았습니다. 따라서 실제로 관계형 데이터베이스에 대해 통합 테스트를 수행하는 경우 "매직 문자열"과 관련된 문제가 해결됩니다.

새 프로젝트를 시작하려는 경우 ORM을 사용할지 여부가 확실하지 않습니다. 아마 할 것입니다, 그러나 당신 이 확실하게 말할 수는 없습니다 . 프로젝트에 C ++ 또는 Java / .NET을 선택하는 것의 차이점과 같습니다. 더 낮은 수준에서 작업 할 때 유연성이 필요합니까, 아니면 더 높은 수준에서 작업하고 (아마도) 더 많을 것입니다 생산적인? 정답은로 도망 칠 수 있는 한 높은 수준에서 작업하는 것입니다 . 일반적으로 ORM을 사용합니다.

ORM의 강점은 객체 지향 기술을 사용하여 응용 프로그램 동작을 모델링 할 수 있다는 것입니다. 신중하게 설계된 세계에는 비즈니스 언어가 개발 팀의 언어와 깔끔하게 일치하는 응용 프로그램의 한 계층이 있습니다. ORM이 현명하게 사용된다면, ORM은 그것의 인 에이 블러입니다.

약점은 실제로 실제로 객체 지향 프로그래밍을받는 사람들의 수가 적다는 것입니다. 많은 사람들이 스파게티와 미트볼을 작성합니다. 자신의 행동이 거의없는 고도로 결합 된 객체로 실제 행동은 끔찍한 8000 줄 "서비스"및 "관리자"클래스로 끝나고, 그 코드는 종종 너무 복잡하여 모든 사람이 두려워합니다 부작용이 무엇인지 파악할 수 없기 때문에 변경하는 것입니다.

또한 많은 사람들이 실제로 관계형 모델을 얻지 못합니다. ORM은 그것들을 얻는 데 도움이되지 않으며 관계형 모델을 추상화하여 도움이되지 않습니다. 그것은 단지 당신이 도메인 레이어에 일찍 집중하고 데이터베이스 디자인에 대해 너무 걱정하기 시작하기 직전에 그것을 얻을 수있게합니다. 적절한 스키마 마이그레이션 도구와 ORM을 사용하여 올바르게 적용하면 ORM을 통해 코드 부채가 발생하지 않도록 할 수 있습니다.

ORM이 응용 프로그램 코드를 단순하고 읽기 쉽고 테스트 가능하게 유지하고 합리적인 성능을 유지하는 응용 프로그램을 만들었습니다. 또한 패턴이 잘못 사용되고 코드가 복잡하고 테스트 할 수없고 느리고 취약한 응용 프로그램을 유지 관리했습니다. ORM 자체는 응용 프로그램 도메인을 잘못 모델링 한 잘못된 코드를 작성하는 대신 응용 프로그램 도메인을 잘못 모델링 한 잘못된 코드와 모든 것을 무시한 잘못된 서비스 계층 코드를 작성했다는 점을 제외하고는 ORM 자체와 관련이 거의 없었습니다. ORM이 제공 할 수있는 가치.

ORM은 당신을 더 똑똑하게 만들지 않지만, 올바른 개발자의 손에 의해 유지 보수가 용이하고 고품질의 코드를 만들 수 있습니다.

아마도 대답은 질문의 반대에 있습니다. 응용 프로그램 데이터를 관계형 데이터베이스 이외의 다른 곳에 저장하는 것이 좋은 생각입니까? 어떤 문제를 제거하고 있습니까? 다른 문제는 무엇입니까? 데이터를 쉽게 상호 참조 (조인)하거나 여러 기준에 따라 원하는 레코드를 신속하게 필터링 할 수있는 능력없이 살 수 있습니까? 확실한 거래 지원이 필요하지 않습니까 (대안이없는 것으로 가정)? 모든 응용 프로그램이 항상 일관성 있고 완벽한 데이터 저장소를 필요로하는 것은 아닙니다.

필자의 실제 반 패턴은 관계형 DB가 필요하지 않을 때 사용하고 있다고 생각합니다. 하나가 필요하면 ORM이 필요하며 반 패턴이 아닙니다.

ORM은 도구입니다. 모든 도구와 마찬가지로 적절하게 사용하면 상당히 잘 작동합니다. 부적절하게 사용하면 더 큰 망치와 덕트 테이프가 필요합니다.

현재 진행중인 프로젝트의 경우 개발자가 아닌 사람 (정확히 말하면)이 유지 관리하므로 간단하고 이해하기 쉬워야합니다. 이 그룹이 개발자를 고용 할 예산이 있기까지 몇 년이 걸릴 것입니다 (다음 대통령이 관련 기관을 폐지하지 않는다고 가정). 향후 유지 관리 기능은 우리가 고려해야 할 주요 요소입니다.