객체 지향은 이러한 유형의 시나리오가 발생하기 때문에 특히 유용하며 복잡성을 캡슐화 할 수있는 추상화를 합리적으로 디자인 할 수있는 도구를 제공합니다.
여기서 진짜 질문은, 그 복잡성을 어디에 캡슐화합니까?
잠시 후퇴하고 여기서 말하는 '복잡성'에 대해 이야기하겠습니다. 귀하의 문제는 (내가 이해하고, 틀린 경우 수정) 지속성 모델로, 데이터로 완료해야하는 작업에 효과적으로 사용할 수있는 모델이 아닙니다. 그것은 효과적이고 다른 작업에 사용할 수 있지만 수 있습니다 귀하의 작업.
따라서 수단에 적합한 모델이 아닌 데이터가있을 때 어떻게해야합니까?
옮기다. 당신이 할 수 있는 유일한 일 입니다. 그 번역은 위에서 언급 한 '복잡성'입니다. 이제 모델을 번역한다는 점을 받아들이 기 때문에 몇 가지 요소를 결정해야합니다.
양방향을 번역해야합니까? 다음과 같이 두 방향이 동일하게 번역됩니까?
(Tbl A, Tbl B)-> Obj X (읽기)
Obj X-> (Tbl A, Tbl B) (쓰기)
또는 삽입 / 업데이트 / 삭제 활동이 다른 유형의 객체를 나타내므로 Obj X와 같은 데이터를 읽지 만 데이터가 Obj Y에서 삽입 / 업데이트됩니까? 이 두 가지 방법 중 어느 것이 가고 싶 거나 업데이트 / 삽입 / 삭제가 불가능한 경우 번역을하려는 위치에 중요한 요소가 있습니다 .
어디에서 번역합니까?
이 답변에서 내가 한 첫 번째 진술로 돌아가십시오. OO를 사용하면 복잡성을 캡슐화 할 수 있으며 여기서 내가 참조하는 것은 복잡성을 캡슐화하여 누출되지 않고 모든 코드에 침투하지 않도록하려면 해당 복잡성을 캡슐화 해야 한다는 것입니다. 동시에, 완벽한 추상화 를 할 수 없다는 것을 인식하는 것이 중요 하므로 매우 효과적이고 유용한 것을 갖는 것보다 걱정하지 않아도됩니다.
다시 지금; 문제는 :이 복잡성을 어디에 두시겠습니까? 글쎄 당신은 선택이 있습니다.
저장 프로 시저를 사용하여 데이터베이스 에서 이를 수행 할 수 있습니다 . 이것은 종종 ORM과 잘 어울리지 않는 단점이 있지만 항상 그런 것은 아닙니다. 저장 프로시 저는 성능을 포함하여 몇 가지 이점을 제공합니다. 그러나 저장 프로 시저에는 많은 유지 관리가 필요할 수 있지만 특정 시나리오를 분석하고 유지 관리가 다른 선택보다 많거나 적은지 여부를 결정하는 것은 사용자의 몫입니다. 저는 개인적으로 저장 프로 시저에 매우 능숙하므로 이러한 가용 한 재능은 간접비를 줄입니다. 아는 바에 따라 의사 결정의 가치를 과소 평가 하지 마십시오 . 최적의 솔루션보다 솔루션을 더 잘 작성하고 유지 관리하는 방법을 알고 있기 때문에 차선의 솔루션이 올바른 솔루션보다 최적 일 수 있습니다.
다른 데이터베이스 내 옵션은 뷰입니다. 데이터베이스 서버에 따라 이들은 최적 또는 하위 최적화이거나 전혀 효과적이지 않을 수 있으며, 데이터베이스에서 사용 가능한 색인 옵션에 따라 쿼리 시간이 단축 될 수 있습니다. 데이터를 수정할 필요가없는 경우 (삽입 / 업데이트 / 삭제)보기가 더 나은 선택이됩니다.
데이터베이스를 지나서 리포지토리 패턴을 사용하는 이전 대기 상태가되었습니다. 이것은 매우 효과적 일 수있는 시간 테스트 된 접근 방식입니다. 단점은 보일러 플레이트를 포함하는 경향이 있지만 잘 정리 된 리포지토리는이 정도의 양을 피할 수 있으며, 이로 인해 불행히도 보일러 플레이트가 발생하더라도 리포지토리는 이해하기 쉽고 유지하기 쉬우 며 우수한 API를 제공하는 간단한 코드 인 경향이 있습니다. /추출. 또한 리포지토리는 데이터베이스 내 옵션으로 손실되는 단위 테스트 가능성에 적합 할 수 있습니다.
자동 매퍼와 같은 도구가있어 ORM을 사용하여 데이터베이스 모델을 orm에서 사용 가능한 모델로 변환 할 수 있지만,이 도구 중 일부는 마술처럼 동작을 유지 / 이해하기가 까다로울 수 있습니다. 그러나 최소한의 오버 헤드 코드를 만들어 잘 이해하면 유지 관리 오버 헤드가 줄어 듭니다.
다음으로 데이터베이스 에서 점점 더 나아가고 있습니다. 이는 번역되지 않은 퍼시스턴스 모델을 다루는 더 많은 양의 코드가 있다는 것을 의미하며, 이는 실제로 불쾌합니다. 이 시나리오에서는 번역 레이어를 UI에 배치하는 방법에 대해 설명합니다. 이것은 일반적으로 매우 나쁜 생각이며 시간이 지남에 따라 끔찍하게 붕괴됩니다.
이제 미친 이야기를 시작합시다 .
이 Object존재하는 경우에만 최종 모든 일이 모든 추상화가 아닙니다. 수년에 걸쳐 컴퓨터 과학을 연구 해 왔으며 그 이전에도 수학 연구를 통해 많은 추상화가 개발되었습니다. 우리가 창의력을 발휘하기 시작한다면 연구 된 알려진 추상화에 대해 이야기 해 보도록하겠습니다.
배우 모델이 있습니다.이것은 모든 작업을 다른 코드로 효과적으로 위임하는 다른 코드로 메시지를 보내는 것이므로 모든 코드에서 복잡성을 캡슐화하는 데 매우 효과적이기 때문에 흥미로운 접근 방식입니다. 이것은 배우에게 "I에게 Obj X를 보내야한다"라는 메시지를 보내고 위치 Y에서 응답을 기다리는 리셉터클이 있고 Obj X를 처리하는 한 작동 할 수있다. 심지어 지시하는 메시지를 보낼 수도있다. "Obj X와 계산 Y, Z가 필요해"기다릴 필요도 없습니다. 번역은 해당 메시지 전달의 다른 쪽에서 발생하며 결과를 읽을 필요가없는 경우 계속 진행할 수 있습니다. 이는 사용자의 목적에 따라 액터 모델을 약간 남용 할 수 있지만 모두 다릅니다.
또 다른 캡슐화 경계는 프로세스 경계입니다. 복잡성을 매우 효과적으로 분리하는 데 사용할 수 있습니다. SOAP, REST를 사용하거나 자신의 프로토콜을 원하는 경우 (권장되지 않음) 통신이 단순한 HTTP 인 웹 서비스로 변환 코드를 작성할 수 있습니다. STOMP는 완전히 새로운 프로토콜이 아닙니다. 또는 시스템 로컬 공개 메모리 파이프와 함께 일반 데몬 서비스를 사용하여 선택한 프로토콜을 사용하여 매우 빠르게 다시 통신하십시오. 이것은 실제로 몇 가지 좋은 이점이 있습니다.
- 이전 및 최신 버전 지원을 위해 번역을 수행하는 여러 프로세스를 동시에 실행할 수 있으므로 변환 서비스를 업데이트하여 오브젝트 모델 V2를 공개 한 다음 나중에 별도로 소비 코드를 업데이트하여 새 오브젝트로 작업 할 수 있습니다 모델.
- 성능을 위해 프로세스를 핵심에 고정시키는 것과 같은 흥미로운 작업을 수행 할 수 있으며,이 방법에서는 보안 권한으로 실행되는 프로세스 만 해당 데이터를 만지도록하여 보안 안전성을 확보 할 수 있습니다.
- 번역 공간에서 코드를 작성하는 것은 번역 공간 외부에서 호출 될 수 없으므로 변환 공간에서 코드를 작성할 수 없기 때문에 오랫동안 추상화 유출을 최소화하는 고정 된 프로세스 경계에 대해 이야기 할 때 매우 강력한 경계를 갖게됩니다. 프로세스 범위를 공유하지 않으므로 계약에 따라 고정 된 사용 시나리오 세트가 보장됩니다.
- 비동기 / 비 차단 업데이트 기능이 더 간단 해졌습니다.
단점은 성능 및 유지 관리에 영향을 미치는 통신 오버 헤드가 일반적으로 필요한 것보다 분명히 유지 관리입니다.
복잡성을 캡슐화하는 다양한 방법이 있으므로 시스템에서 복잡하고 이상한 곳으로 복잡성을 배치 할 수 있습니다. 고차 함수 형태 (전략 패턴이나 다양한 다른 이상한 형태의 객체 패턴을 사용하여 위조)를 사용하면 매우 흥미로운 일을 할 수 있습니다.
맞습니다. 모나드에 대해 이야기 해 봅시다.필요한 독립 번역을 수행하는 작은 특정 함수의 매우 독립적 인 방식으로이 변환 계층을 만들 수 있지만 이러한 변환 함수를 모두 보이지 않게 숨겨서 외부 코드에서는 거의 액세스 할 수 없습니다. 이는 외부 코드에 영향을주지 않으면 서 쉽게 변경할 수 있도록하는 의존성을 줄이는 이점이 있습니다. 그런 다음 멋진 OO 모델 유형 객체에서 작동하는 고차 함수 (익명 함수, 람다 함수, 전략 객체, 그러나 구조화해야 함)를 허용하는 클래스를 만듭니다. 그런 다음 해당 함수를 허용하는 기본 코드가 적절한 변환 방법을 사용하여 리터럴 실행을 수행하도록합니다.
이렇게하면 모든 변환 에서 경계의 반대편 에만 모든 변환 이 존재 하는 경계가 만들어집니다 . 그것은 그 측면에서만 사용되어 나머지 코드는 해당 경계의 진입 점이 아닌 다른 코드를 알 수 없습니다.
그래, 정말 미쳤어.하지만 누가 알 겠어? 당신은 그 미쳤을 수도 있습니다.