Dva: 모델 중첩 (모듈화)을 구현하는 방법은 무엇입니까?

사업은 이렇습니다.
예를 들어 앱에는 5 개의 상대적으로 독립적 인 제품이 있고 각 제품에는 상대적으로 독립적 인 모델이 있습니다.

이 경우 모델의 단일 레이어 만 매우 비좁습니다.

물론 네임 스페이스에서도 구분할 수 있지만 현재 네임 스페이스는 상태 이름으로 직접 사용됩니다 ( . 와 같은 특수 기호는 사용할 수 없음).

모델의 단일 레이어 만 매우 비좁습니다.

이해하지 못함

@codering

문서를 보면 모델은 물리적으로 하나의 레이어 만 가지고 있습니다. 모델이 많은 경우 동일한 이름의 네임 스페이스 충돌이있을 수 있습니다 (특히 대규모 프로젝트의 경우 일부 모델의 의미가 동일 함). 이번에는 네임 스페이스에 있어야 할 수도 있습니다., 주로 접두사를 모듈 간의 구분으로 추가합니다.

그래서 더 나은 모델 중첩 또는 모듈화 체계가 있는지 묻고 싶습니다.

너무 깊숙한 상태로 중첩하는 것은 권장하지 않습니다. 그래도 모델을 중첩하면 더 복잡해지며 디자인에 문제가있는 것 같습니다.
질문을 이해하지 못합니다. 간단한 데모를 해주실 수 있나요?

이 질문은 대략적으로 이해되었습니다. 어제 논의했습니다. 주로 모델의 의미에 관한 것입니다. 두 가지 경향이 있습니다 : 관점을 따르고 비즈니스 주체를 따르는 것입니다.

현재의 디자인 관점에서는 각 모델의 상태가 격리되어 있고 모델의 모든 것이 자체 상태를 따르기 때문에보기를 따르는 것이 더 적절해야합니다. 이 경우 모델의 의미는 뷰 모델입니다.

그러나 이러한 방식으로 모델에서 사용하는 비즈니스 추가, 삭제, 확인 및 수정 효과는 사용되는 모든 모델에 존재할 수 있습니다. 예를 들면 다음과 같습니다.

보기 ABC, 비즈니스 항목 XYZ가 있습니다.

A는 XY의 CRUD를 사용합니다.
B는 YZ의 CRUD를 사용합니다.
C는 XZ의 CRUD를 사용합니다.

우리의 모델은 ABC 뷰를 따르도록 설계되었으며 그 안에 약간의 중복 효과가 있어야합니다. 예를 들어 Y는 AB에 동시에 존재하고 코드에 중복이있을 수 있습니다. 또 다른 관점에서 AB 자체에서 Y를 사용하는 것은 재사용을 고려해서는 안되며, 재사용 될 호출 프로세스는 다음 단계, 즉 서비스에 배치되어야합니다.

따라서 조직 구조는 다음과 같습니다.

  a
  b
  c
service
  x
  y
  z

그리고 modelA의 구조 :

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

modelB의 구조 :

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

나중에 좀 더 비즈니스 지향적 인 데모를 작성하고 시나리오 사용에 대한 몇 가지 제안을 할 것입니다.

@xufei 는

@xufei 데모에서 배울 수 있습니까?최근이게 걱정돼

@xufei 데모에 있나요?

@xufei 데모에 있나요?

비즈니스 모델과 뷰 모델을 모두 갖는 것이 더 합리적이라고 생각합니다. 예를 들어 현재 사용자는 글로벌 처리를위한 사용자 모델을 가질 수 있습니다.
다른 구성 요소에 현재 사용자 정보가 포함 된 경우 사용자 모델에 직접 연결하기 만하면됩니다.비즈니스 요구에 따라 다릅니다.

@ liSong5713 사용자 목록을 사용자 세부 정보 목록에 클릭하고 사용자 세부 정보를 키 관리에 클릭하여 동일한 사용자 모델에 배치해야하는지 여부

@lwbGH 모델의 책임에 따라 다릅니다. 사용자 모델은 현재 로그인 한 사용자의 기본적이고 일반적으로 사용되는 정보가 될 수 있습니다. 사용자의 작업 로그와 같은 사용자의 세부 정보를 변경하려는 경우이 정보는 다음과 같습니다. 모델과는 완전히 다릅니다. 모델 구분이 조금 있다고 생각합니다.
레벨 컴포넌트의 상태 공유 정도 . 단순 페이지가 페이지 레벨 모델에 해당하면 복잡합니다.

물론 네임 스페이스에서도 구분할 수 있지만 현재 네임 스페이스는 상태 이름으로 직접 사용됩니다 ( . 와 같은 특수 기호는 사용할 수 없음).
. 키로 사용할 수 없으며 _를 사용할 수 있습니다. 현재 네임 스페이스가 제한되어 있습니다. 모델은 뷰 및 비즈니스별로 모듈로 나눌 수 있지만 네임 스페이스는 "폴더 _ 파일 이름"에 의해 제한됩니다.