codeigniter를 사용하고 있으며 Model 메서드를 반복 한 비슷한 상황에서 자신을 발견했습니다. 컨트롤러 당 모델을 작성 중입니다. 그러나 데이터베이스 테이블 당 모델을 만드는 것이 좋은 습관으로 간주됩니까? 그렇게하면 메소드가 두 번 작성되지 않습니다.
컨트롤러 당 모델 또는 공유되는 여러 개의 작은 모델 대신.
예를 들어 get_user ($ user_id) 모델 메소드가 있으면 users_models.php에 쓸 수 있습니다 ...
내가 본 단점 중 하나는 controllername_models.php가 아닌 여러 모델을 호출해야 할 수도 있다는 것입니다.
컨트롤러에서 여러 방법을 사용하지 않을 수있는 여러 모델을로드하면 성능과 속도에 영향을 줄 수 있습니까? 이 문제를 해결하는 가장 좋은 방법은 무엇입니까?
참고 : 비슷한 질문이 있지만 데이터베이스 테이블 당 모델의 근거는 다루지 않습니다.
답변:
테이블 당 모델이 데이터베이스를 클래스 구조로 다시 작성한다고합니다. 빈혈 모델 로 알려져 있으며 반 패턴으로 간주됩니다. 클래스는 데이터와 행동을 모두 가지고 있기 때문입니다. 모델을 단일 테이블로 제한하는 경우 여러 테이블의 데이터 및 동작을 처리하는 데 필요한 코드 (행동)를 어디에 배치합니까? 그런 다음 컨트롤러에는 이러한 "테이블"모델 중 하나 이상을 사용하는 모델이 필요합니다. 따라서 가장 기본적인 앱과는 별도로이 방법으로 얻는 것이 거의 없습니다.
일반적으로 테이블 또는 컨트롤러가 아닌 비즈니스 오브젝트별로 모델을 작성해야합니다. 때로는 테이블 구조 또는 컨트롤러와 1 : 1 관계 일 수도 있지만 필요하지는 않습니다.
귀하의 예에서는 users_model여러 컨트롤러에서 호출되는 하나의 클래스가 있을 수 있습니다 . 이것은 좋으며 때로는 바람직합니다. 그러나 대부분의 경우 users_model클래스는 여러 테이블에서 데이터를 가져옵니다.
예를 들어, 클래스의 last_login_date속성은 기본 테이블 과 일대 다 관계가 있는 별도의 테이블 에서 얻을 users_model수 있습니다 ( 필수 아님) .user_auditusers
그리고 비즈니스 오브젝트 당 하나의 SQL 테이블이 있으면 데이터베이스 구조가 정규화되지 않았을 가능성이 높습니다.
비즈니스 개체별로 모델을 만들려는 Dime의 대답에 동의합니다. 비즈니스에서 해결하려는 문제로 인해 모델 클래스를 만드는 방법이 달라집니다. 실제로 테이블 당 하나의 모델을 만드는 것이 시작하기에 좋은 장소라는 것을 알았습니다. 올바르게 설계된 스키마는 응용 프로그램 코드에서 모델링해야하는 비즈니스 프로세스 (도메인 모델이라고도 함)를 모방 할 수 있습니다.
객체 / 관계형 매핑 계층을 사용하면 도메인 모델에 데이터 액세스 계층을 반복적으로 호출 할 필요없이 데이터베이스 스키마와 동일한 관계가 포함되므로 유용합니다. 확인 설득력을 예로 PHP를 위해. 스키마와 도메인 모델은 모두 비즈니스 프로세스를 지원하도록 설계되어야합니다.
이것은 Marjan Venema의 답변의 첫 부분으로 이어집니다.
테이블 당 모델이 데이터베이스를 클래스 구조로 다시 작성한다고합니다. 빈혈 모델로 알려져 있으며 반 패턴으로 간주됩니다.
빈혈 도메인 모델은 안티 패턴이다. Venema가 제안한 "테이블 당 모델"은 "데이터베이스 재생성"으로 볼 수 있지만 이것이 빈혈증 도메인 모델이라고 말하는 것은 절대적으로 올바르지 않습니다.
마틴 파울러 (Martin Fowler)
Anemic Domain Model의 기본 증상은 처음에는 홍당무가 실제처럼 보입니다. 도메인 공간에 명사의 이름을 딴 많은 개체가 있으며 이러한 개체는 실제 도메인 모델의 풍부한 관계 및 구조와 연결됩니다. 캐치는 당신이 행동을 볼 때 생기고 , 당신은 이러한 객체에 행동이 거의 없다는 것을 알고, 게터와 세터의 가방 이상을 만들지 않습니다.
(강조, 내)
빈혈 도메인 모델의 핵심 요소는 도메인 모델 클래스에서 동작 또는 메서드가 부족하다는 것입니다.
클래스는 데이터와 행동을 모두 가지고 있기 때문입니다. 모델을 단일 테이블로 제한하는 경우 여러 테이블의 데이터 및 동작을 처리하는 데 필요한 코드 (행동)를 어디에 배치합니까?
다시 한 번, 하나의 테이블에만 매핑 되더라도 도메인 모델에 동작을 넣을 수 있어야합니다. 여러 테이블에 영향을주는 동작은 실제로 여러 테이블에 매핑되는 여러 개체에 영향을줍니다. 도메인 기반 설계 는 Venema가 언급 한 동일한 문제에 대한 접근 방식입니다. "여러 테이블의 데이터 및 동작을 처리하는 데 필요한 코드 (행동)를 어디에 배치합니까?"
그리고 그 대답은 집합 루트 입니다. 마틴 파울러 상태 :
집계는 도메인 기반 디자인의 패턴입니다. DDD 집계는 단일 단위로 취급 될 수있는 도메인 개체 의 클러스터입니다. 예를 들어 광고 주문과 해당 품목이있을 수 있지만, 이들은 별도의 개체가 될 수 있지만 주문을 개별 품목과 함께 단일 집계로 취급하는 것이 유용합니다.
(강조, 내)
"도메인 개체의 클러스터"는 "여러 테이블에 매핑되는 도메인 모델"로 볼 수도 있습니다. 여러 테이블에 영향을주는 동작은 집계 루트-여러 테이블이나 개체에 영향을주는 "사물"을 캡슐화하는 클래스에서 정의해야합니다.
다시 마틴 파울러에서 :
집계에는 종종 간단한 필드와 함께 여러 개의 컬렉션이 포함됩니다.
OP의 원래 질문에 대답하려면 :
... 데이터베이스 테이블 당 모델을 작성하는 것이 우수 사례로 간주됩니까? 그렇게하면 메소드가 두 번 작성되지 않습니다.
나는 이것이 시작하기에 좋은 곳이라고 말하고 있지만 스키마와 객체 모델이 100 % 일치 할 필요는 없다는 것을 명심하십시오. 오브젝트 모델은 비즈니스 규칙 구현 및 시행에 더 관심이 있어야합니다. 스키마는 비즈니스 데이터를 모듈 식 및 확장 가능한 방식으로 저장하는 데 더 중점을 두어야합니다.
뷰 모델이라는 모델의 변화가 있지만 컨트롤러 당 모델은 좋은 연습하지 않을 것입니다 않습니다 컨트롤러 계층에 맞는. 보기 모델 , 디스플레이의 특정 종류에 맞게 그것을 GUI 응용 프로그램에서 웹 페이지 또는 양식으로 도메인 모델의 재구성이다.