http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch저는 Object-relational_impedance_mismatch에 대해 정말로 확신하지 못했습니까?
저는 여러 프로젝트에서 작업했으며 모두 데이터베이스 중심 디자인을 사용했으며 제대로 작동하는 것으로 보입니다.
새로운 아이디어가 번성하고 있으며 이제는 괜찮아 보이지만 그 가치는 시험받을 가치가 있거나 잘못 되었나요?
개체 관계형 불일치의 개념은 관계형 데이터베이스를 기반으로하는 개체 지향 프로그래밍 방법을 시도하고 사용할 때 발생하는 문제에서 비롯됩니다. 문제는 객체 모델이 일반적으로 오브젝트를 전체적으로 저장하는 대신 여러 테이블에서 파쇄하고 다시 빌드해야하는 객체의 계층을 포함한다는 사실로부터 발생합니다.
그러나이 시점에서 일반적으로 제기되는 논점은 문제를 발견하지 못했다면 '적절한'객체 지향을하지 않기 때문에 자신의 잘못입니다. 불일치를 찾을 수 있습니다 당신이 객체 지향을 '제대로'하는 것을 배울 때. 그리고 우리 모두는 객체 지향이 유일한 '적절한'개발 패러다임이라는 것을 알고 있습니다.
아, 잠깐.
많은 시스템이 객체 지향 시스템으로 모델링하는 데 적합하지 않습니다. 실제로 전체적으로 복잡성이 낮고 복잡성이 높은 웹 응용 프로그램과 같이 높은 동시성과 확장 성이 필요한 웹 응용 프로그램의 경우 서비스 지향 및 메시지 전달 기술을 사용하는 것이 더 나은 옵션 일 수 있습니다. 이 방법으로 응용 프로그램을 작성하면 지연로드 및 복잡한 객체 계층 구조와 같은 것을 사용하지 않고 객체가 변경되지 않으므로 객체 관계형 불일치가 너무 많이 발생하지 않는 경향이 있습니다. 데이터베이스에 다시 파쇄해야합니다.
개체 관계형 불일치가 있습니까? 예, 관계형 데이터베이스와 함께 객체 지향 기술을 사용해보십시오. 그러나 다른 접근 방식이 응용 프로그램에 더 적합 할 경우 객체 지향 기술을 사용하지 않아도이를 완화 할 수 있습니다.
어, 메시지 전달은 OO 설계의 가장 중요한 단일 특성입니다. OO의 어떤 것도 불변 객체를 막지 않습니다. 서비스 지향 시스템은 대규모의 정형화 된 시스템입니다. –
@ Pete - 그 결론에 어떻게 도달했는지 확신 할 수 없다. 나는 ad-hoc 다형성이 객체 지향 설계의 가장 특징적인 특성이라고 주장 할 것이다. 나는 내가 묘사했던 건축물의 유형에도 아무런 자리가 없다고 언급 했어야했다. OO가 불변 객체를 막지는 않지만, 완전히 불변 인 객체로 객체 지향 시스템을 구축하는 것은 비 전형적인 방식입니다. 마지막 문장에서 무슨 뜻인지 모르겠다. 그래서 나는 반론을 제기 할 수 없다. –
글쎄, 앨런 케이 (Alan Kay)는 메시지가 캡슐화보다 더 중요하다고 말한 것으로 기록되어 있습니다. 따라서 스웨덴 캠프에 가면 메시지가없는 특별한 다형성을 가질 수 없습니다. SOA에서는 불투명 한 핸들 (예 : URI)과 메시지 (예 : XML. 서)를 전달합니다. 인터페이스가 정의되고 구현이 숨겨집니다. 그것은 단지 OO이지만 더 커야합니다. –
객체 - 관계 임피던스 불일치는 관계형 데이터베이스와 객체 지향 소프트웨어 모델의 차이와 관련이 있습니다. 불일치가 보이지 않는다면 코드가 실제적으로 올바르게 작동하지 않기 때문입니다.
OO를 제대로 시작하고 이러한 관계를 RDBMS에 매핑하려고하면 문제를 이해하게됩니다.
도메인 모델이 간단하고 깊은 상속 기능이없는 경우 임피던스가 일치하지 않을 수 있습니다.
예를 들어 클래스 Foo가 속성 foo를 정의한다고 가정 해 보겠습니다. Bar 서브 클래스 Foo와 속성 막대를 도입했습니다. 어떻게 Foos와 Bars를 데이터베이스에 저장합니까?
필드 foo 및 bar ...가 포함 된 테이블 Foo를 가질 수 있으며 모든 Foo는 "bar IS NULL"을 만족시킵니다. 그러나 하위 클래스가 전체 속성 집합을 도입한다면 이는 낭비입니다.
그래서 두 테이블 Foo 및 Bar가 있습니다. 하나의 SELECT에 전체 막대를로드 할 수 있도록 Foo의 모든 열을 Bar로 복사합니까? 아니면 바를로드하기 위해 Bar와 함께 Foo에 가입해야합니까?
임피던스는 개체를 하나 이상의 테이블로 "파쇄하는 방법"(그렉 비치의 용어를 사용하는 방법)에 대한 모든 세부 사항에 대해 생각해야한다는 사실을 나타냅니다.
디자인은 데이터베이스 중심이지만 적절한 코드입니까? – Skilldrick
보통 아니지만 앞으로의 프로젝트에서 나는 희망을 가지고있다. – poo
임피던스는 프로젝트의 한 조각이 한쪽으로 쓰여지고 다른 한 조각이 다른쪽에 쓰여지는 경우에만 나타낼 수있다. 그래서 데이터베이스에 대한 관계형 모델을 갖고, 기반 도메인 모델. –