RDBMS를 사용한 객체 지향 접근법

Question

mysql과 같은 RDBMS를 사용하면서 객체 지향 접근법을 사용하는 방법에 관한 질문이 있습니다. 청구서를 추적 할 작은 애플리케이션을 개발 중입니다. 그것은 자바에 내장되어 있으며 데이터를 저장하기 위해 MySQL 데이터베이스를 사용하고 있습니다. 내 응용 프로그램에는 costumer 및 제품 클래스가 있습니다. 이제는 일반적으로 배열이나 다른 데이터 컨테이너를 사용하여 영구 데이터 저장소를 처리하는 경우 고객 클래스와 제품 클래스에 대한 업데이트 등을 삭제할 것입니다. 그러나 나는 그 어느 때보 다 더 정적 인 방법을 사용하여 자신을 찾는다. 예를 들어 고객 배열이 없으므로 고객 정보가있는 데이터베이스가 있습니다. 고객 개체를 만드는 데 아무런 의미가 없기 때문에 고객 (또는 제품)을 삭제하는 정적 메서드를 호출하면 삭제할 수 있습니다 그것에 기본 ID입니다. 결국 특정 방법에 대한 필요성이 없기 때문에 고객 또는 제품 클래스를 만들 필요가없는 것처럼 느껴집니다.

내가 모두에게 묻고 싶은 것은 RDBMS를 사용할 때 어떻게 객체 지향 접근 방식을 사용합니까?

Answer 1

OO 원칙을 사용하여 Java 클래스를 디자인하십시오.

SQL 및 정규화 원칙을 사용하여 DB를 디자인하십시오.

그런 다음 객체/관계 매핑이라는 챌린지에 최대 속도를 실행하십시오! :-)

최대 절전 모드 및 Ibatis와 같은 기술은이 문제를 해결하기 위해 특별히 설계된 것으로 잘 문서화 된 문제입니다. Spring과 같은 추가 기술을 사용하면 실제로 사용하기가 쉽고 즐겁습니다.

요약 DAO (데이터 액세스 개체) 레이어에 대한 지속성을 요약합니다. Vehicle과 Animal과 같은 수업이 많은 경우 VehicleDao 및 AnimalDao와 같은 DAO를 사용하여 시스템에서 근본적으로 수행하는 작업에서 DB와 대화하는 방법을 구분할 수 있습니다.

FWIW, 나는 앱 사이드에서 좋은 앱 디자인을, 데이터 측면에서 좋은 DB 디자인을하고 있다고 주장한다. 이렇게하면 DB와 클래스 데이터를 유지 및 검색 할 때 두 클래스를 매핑하는 방법이 항상 있으며, 이는 개별 레이어 중 하나를 손상시켜 다른 클래스를 "도움"하는 것보다 훨씬 뛰어납니다.

Answer 2

데이터베이스의 개체를 나타내는 클래스 인 DTO (데이터 전송 개체)를 사용하면 단일 책임 원칙을 준수합니다. OOP 원리 (보다 구체적으로 캡슐화 과정)를 기반으로 한 디자인 패턴입니다. 이렇게하면 각 학급이 하나의 목적을 달성 할 수 있습니다. 비즈니스 문자열을 SQL 문자열에 저장하면 유지 관리가 어려워지고 DRY "Do not Repeat Yourself"원칙을 위반하게됩니다. 내 경험에 비추어 볼 때 ORM은 시스템 설계 프로세스를 신속하게 처리했습니다. NHibernate를 시도하십시오. http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx

Answer 3

이 응용 프로그램이 성장할 것으로 예상되면 (아마도 응용 프로그램의 99 %) 응용 프로그램이 생성 될 것으로 예상되면 개체를 만듭니다. 삭제가 단일 SQL 호출 인 경우에도 로직을 추가해야 할 수 있습니다 (하위 테이블의 행 삭제, 감사 데이터 저장, 하드 삭제 대신 논리적 삭제로 이동 등)

Answer 4

데이터베이스 완전히 정규화 된 비즈니스 개체를 나타냅니다.

개체 모델은 코드에서 데이터로 작업하는 방법을 나타냅니다. 그것들은 대개 동일하지 않습니다. 예를 들어 주소 테이블에 일대 다 링크 된 고객 테이블이 있지만 코드에서 두 유형의 정보가 모두 들어있는 객체를 사용합니다.

데이터 액세스 개체 (DAO)는 비즈니스 개체 (예 : 읽기/쓰기)를 처리합니다. 서비스 계층은 필요한 경우 DAO의 출력을 개체에 결합하여 작업을 완료합니다.서비스 계층은 필요에 따라 트랜잭션을 처리합니다.

서비스 계층에서 데이터 액세스를 추상화하면 코드 유지 관리, 데이터베이스 스키마 업데이트 및 테스트가 더 쉬워집니다.

Answer 5

데이터베이스 처리 및 Oo 코드는 항상 중요한 주제입니다. 그리고 어떤 사람들은 "JUST DON'T"라고 말할 수도 있습니다.

나는 이것들에 동의하지 않지만 그렇게해야 할 때 많은 문제점들을 보았다. 나는 Hibernate와 같은 OR-Mappers를 즉시 추천하는 몇몇 다른 사람들과 절대적으로 동의하지 않는다. 많은 경우 개발 중에 실제로 이점이 없으며 런타임 중에 많은 문제 (성능, 오류 진단)가 발생합니다.

언제나처럼 모든 것은 앱에서 무엇을하는지에 달려 있습니다. 당신은 고객의 물건이 없다고 말합니다. 왜 이런거야? 예를 들어 gui 내부의 테이블에 모든 고객을 표시하고 사용자가 마우스 오른쪽 버튼을 클릭하거나 다른 방법으로 삭제할 수있는 경우 가장 좋은 방법은 JDBC를 통해 DB 데이터를 읽은 다음 JTable에 넣고 JDBC를 다시 사용하는 정적 삭제 메소드.

하지만 당신은 정말 응용 프로그램 내부 고객과 거래 그것은 고객 객체 다음 필요 OR 매핑을 설정하는 것이 유용 할 것입니다 경우. 하지만 프레임 워크가 필요하지 않습니다. 손으로 작성된 sql/JDBC는 대부분의 경우 훌륭한 작업을 수행합니다.

내 견해로는 OR-Mapper-Frameworks는 성능이 흥미롭지 않은 응용 프로그램에서 좋은 점이 될 수 있으며 대부분의 다른 경우 (예 : 프로토 타이핑)의 모든 DB 항목에 대해 생각할 기분이 아닙니다. 나는 독서와 저장을 위해 손으로 쓴 코드로 갈 것입니다.

Answer 6

Domain model 좋은 접근 방식입니다. 비즈니스 로직을 데이터베이스에 직접 의존하지 않는 계층으로 분리하십시오. SOLID 원칙을 사용하고 도메인 기반 디자인을 살펴보십시오. 이렇게하면 격리되어 쉽게 테스트 할 수있는 읽을 수있는 OO 코드가 생깁니다. 'Repository'와 같은 패턴을 사용하면 관계형 데이터베이스의 실제 작업을하면서 비즈니스 요구 사항에 집중할 수 있습니다. 본질적으로 사용자는 다음과 같이 정의하고 인터페이스합니다.

List<Customer> customers = Customers.WithOutstandingOrders(DateRange range) 

그런 다음이 인터페이스를 (도메인 외부의) 데이터 액세스 계층에 구현하십시오. 가장 쉬운 방법은 Hibernate와 같은 ORM을 사용하는 것입니다. 이 아키텍처에서 데이터베이스의 역할은 '비트 버켓'에 가깝습니다. 즉, OO 코드와 데이터베이스의 대부분의 로직은 데이터 예외로부터 보호하고 정상화, 참조 무결성 및 인덱스를 사용하여 작업 속도를 향상시킵니다.