ORM은 OO 디자인에 비생산적입니까?

Question

OOD에서 객체의 설계는 객체의 정체성과 동작으로 특징 지어진다.

과거에는 ORM을 사용했기 때문에 주된 목적은 제 생각에 데이터 저장/검색 기능을 중심으로 이루어졌습니다. 말하자면, ORM 객체는 동작에 의한 것이 아니라 데이터 (즉, 데이터베이스 테이블)입니다. 사례 및 요점 : 많은 ORM 도구에는 point-to-a 데이터베이스 테이블 및 클릭 개체 생성기가 제공됩니다.

개체가 더 이상 특성에 의해 특징 지어지지 않는다면, 내 의견으로는 개체의 신원과 책임이 진부합니다. 그 결과, 객체가 책임에 의해 정의되지 않으면 밀접하게 결합 된 클래스와 전반적인 형편없는 디자인을 제공 할 수 있습니다.

또한 응용 프로그램 설정에서 확장 성 문제로 향할 것이라고 생각합니다.

제 질문은 ORM이 OO 설계에 비생산적이라고 생각합니까? 아마도 근본적인 질문은 애플리케이션 개발에 역효과가 있는지 여부입니다.

Answer 1

좋은 데이터베이스 설계의 요구 사항과 좋은 OO 설계의 요구 사항 사이에는 잘 알려지지 않았으며 무시 된 임피던스 불일치가 있습니다. 대부분의 개발자 (내 경험)는이 임피던스 불일치를 이해하지 못하거나 신경 쓰지 않습니다. 데이터베이스로 시작하여 객체를 생성하는 것이 더 일반적이기 때문에 (역순이 아닌), 그렇습니다. 객체는 지속성 레이어로 훌륭하지만 OO 관점에서는 미 최적입니다. (역으로, 객체 모델에서 데이터베이스를 생성하면 내 눈을 찔러 내고 싶습니다.)

OO 관점에서 차선책 인 이유는 무엇입니까? 왜냐하면 ORM에 의해 생성 된 객체는 부분 클래스 등에서조차도 비즈니스 객체가 아니기 때문입니다. 비즈니스 개체 모델 동작. ORM 개체 모델 지속성. 이 구별을 주장하는 열 개의 단락을 쓰지 않을 것입니다. Rocky Lhotka은 Business Objects에 관한 그의 책과 그의 CSLA framework에서 잘 설명되어 있습니다. 당신이 CSLA를 좋아하든 사용하지 않든 그의 주장은 확실합니다.

Answer 2

내 개발의 대부분을 할 곳이기 때문에 나는 C#을 관점에서이 대답 해요 ....

난 당신 지점을 볼 수 있지만, 나는 당신이 할 수있는 부분 클래스를 만들 수있는 능력과 생각 여전히 당신이 좋아하는 행동으로 객체를 만들고 OR/M이 데이터 검색을 위해 테이블에 가져 오는 힘을 얻습니다.

Answer 3

나는 영속성이 행동의 불가결 한 부분이라고 주장하고 싶지 않다면, ORM이 OO 설계에 비생산적이라고 생각하지 않습니다.

저는 비즈니스 행동과 지속성을 구분할 것입니다. ORM이 생성하는 모든 객체에 busines 비헤이비어를 추가 할 수 있습니다.

Answer 4

내가 ORM을 보았던 것부터 그들은 OO 원칙에 어긋나지 않습니다. 사실 그들과 상당히 직교합니다. (ORM 기술, Java 관점에서 매우 새로운 정보)

내 생각에 ORM은 해당 저장소에 연결하여 코드를 직접 작성하지 않고도 클래스의 데이터 멤버를 영구 저장소에 저장하는 데 유용합니다. 여전히 데이터 멤버를 결정하고 클래스의 비헤이비어를 작성합니다.

나는 OO 원칙을 깨기 위해 ORM을 악용 할 수 있다고 생각하지만, 당신은 무엇이든 할 수 있습니다. 툴링을 사용하여 기존 테이블에서 골격 데이터 클래스를 만들 수 있지만 여전히 메서드 등을 만들 수 있습니다.

Answer 5

사례 및 요점 : 많은 OR/M 도구에는 point-to-a 데이터베이스 - 표 및 클릭 개체 생성기.

네, 그렇지만 객체 수와 데이터베이스 테이블을 생성하는 ORM 해법은 동일하지 않습니다.

데이터로 시작한 다음 자동 생성 된 개체가 개체 동작을하도록 강요하는 경우 네가 혼란스러워 할 수 있습니다 ... 그러나 개체로 시작하여 보조 계층으로 데이터베이스를 생성하면 데이터베이스가 가능한 한 최적화되지 않았더라도 훨씬 더 유용하게 사용할 수 있습니다.

ORM을 사용하지 않으려는 변명을 원할 경우 사용하지 마십시오. 나는 개인적으로 그것이 ORM이 훌륭하게하는 사소한 일을하는 수천 줄의 코드를 저장한다는 것을 발견했다.

Answer 6

또한 OO 모델에서 데이터베이스를 생성하는 경향이있는 ORM 시스템을 보았습니다.

아무튼, 좋은 데이터베이스 코드를 만드는 것보다 좋은 OO 코드를 생성하는쪽으로 ORM이 더 많이 편향되어 있다고 말할 수 있습니다.

성공적인 ORM은 두 영역을 연결하고 비즈니스 영역의 문제 해결 및 구현 관점에서 애플리케이션 코드가 우수하고 데이터베이스 코드 및 모델이 정규화, 성능 및 ETL /보고/복제에서 우수합니다. 어떤 관점이든.

Answer 7

이 유형의 질문 중 대부분은 사용법에 따라 다릅니다. ORM 도구를 사용하는

주요 방법은 다음과 같습니다

1. 는, 데이터에 의해 객체를 정의 응용 프로그램 코드 (BAD BAD BAD)
2. 사용 ORM은 데이터 액세스를 위해 개체를 전역이 개체를 사용, 자신의 객체를 정의 사이의 해석 레이어가있는 경우

처음부터 시작하는 경우 세 번째 방법은 개체 모델의 데이터를 디자인하는 것입니다. (가능하면 최상)

그렇습니다. 데이터 테이블로 개체를 정의하고 코드 전체에서 개체를 사용하면 OOD를 사용하지 않고 디자인 및 유지 관리 문제가 매우 수월해집니다.

그러나 데이터 액세스 도구 (ADO 대체)로만 ORM 개체를 사용하면 좋은 OOD와 ORM을 함께 자유롭게 사용할 수 있습니다. 물론 해석 레이어를 작성하는 데 더 많은 코드가 필요하지만 기존 ADO 코드보다 훨씬 많은 코드가 필요하지는 않으므로 훨씬 더 효과적인 방법을 사용할 수 있습니다.

Answer 8

데이터가 동작과 분리되는 시스템에서는 절대적으로 비생산적입니다.

오름 시스템은 기존 데이터베이스 테이블을 분석하여 사용자 언어로 "개체"를 생성하는 경향이 있습니다. 이러한 것들은 비즈니스 행동을 포함하지 않기 때문에 참된 대상이 아니지만 사람들은 이러한 구조를 가지고 있기 때문에이를 사용하고자하는 경향이 있습니다.

Ruby on Rails (Active Record)는 실제로 데이터를 "라이브"클래스에 바인딩합니다. 훨씬 더 좋습니다.

내가 좋아하는 시스템을 본 적이 한번도 없었습니다. ActiveRecord는 가깝지만, 내가 편하게 생각하지 못하는 몇 가지 루비 스 가정을합니다. 가장 큰 것은 공개 설정자 & 게터를 제공합니다.

하지만 요약하자면, 많은 좋은 OO 프로그래머가 ORM 때문에 코드를 작성한 것을 보았습니다.

Answer 9

개체가 더 이상 동작을 특징으로하지 않는다면 내 의견으로는 개체의 식별 및 책임이 진절머리가됩니다. 질문 에서

개체는 데이터베이스 읽기와 정의 행위로 작성을해야합니까. 그들은 단지 그 이상의 것을 가지고 있지 않습니다.

상황의 현실은 매우 간단합니다. 객체 지향은 그 자체로 끝이 아니며, 끝까지 도달 할 수있는 수단이지만, 경우에 따라 최종 결과를 향상시키는 데별로 도움이되지 못합니다. 사례를 통해 ORM을 사용하면 CRUD 응용 프로그램을 다양하게 변형 할 수 있습니다. 이러한 CRUD 응용 프로그램은 처리하는 대부분의 데이터에 실제 동작을 추가하거나 추가하려고합니다.

응용 프로그램은 전체적으로 응용 프로그램 코드에 데이터의 "동작"이 많이있는 경우에만 이 아닌 인코딩을 사용하여 유연성을 얻습니다. 대신, 그들은 종종 "벙어리 (dumb)"데이터로 UI에서 데이터베이스로 전달하고 보고서 등으로 다시 전달하는 것이 더 좋습니다. 약간의주의를 기울이면 상당한 수준의 사용자 정의가 가능해 지므로 데이터를 실제 개체로 처리하려고 할 때 응용 프로그램에 실제 인코딩 된 실제 동작을 적용하려고 할 때 거의 일치 할 수 없습니다.

물론 데이터의 무결성을 보장하기가 실질적으로 어려워 지거나 데이터가 적절하게 만 사용될 수 있습니다. 실수로 잘못된 필드를 사용한 코드를 보았습니다. 그래서 그들은 사무실 크기 대신 평방 피트 단위로 사무실 수를 평균화했습니다. 둘 다 내용이 숫자 여야한다고 말하는 사용자 정의 필드였습니다. 응용 프로그램은 완벽한 감각을 만들었고 다른 하나는 전혀 이해하지 못했습니다.