Dva: Как реализовать вложение (модуляризацию) моделей?

Бизнес такой,
Например, в приложении есть 5 относительно независимых продуктов, и каждый продукт имеет относительно независимую модель.

В этом случае будет очень тесно только один слой модели.

Конечно, его также можно выделить в пространстве имен, но в настоящее время пространство имен будет напрямую использоваться как имя состояния (специальные символы, такие как . , использовать нельзя)

Только один слой модели будет очень тесным

Не понял

@codering

Глядя на документ, модель физически имеет только один слой. При большом количестве моделей может возникнуть конфликт пространства имен с тем же именем (особенно для больших проектов, некоторые модели имеют одинаковую семантику). на этот раз они, возможно, должны быть в пространстве имен., Преимущественно добавляйте префикс как различие между модулями.

Поэтому я хотел бы спросить, есть ли лучшая схема вложения или модуляризации моделей?

Не рекомендуется вкладывать слишком глубоко в состояние.Если вы все-таки вложите модель, это будет сложнее.Считается, что есть проблема с конструкцией.
Я не понимаю вопроса, вы можете дать мне простую демонстрацию?

Этот вопрос примерно понятен. Вчера мы его обсуждали. В основном речь идет о значении модели. Есть две тенденции: следовать точке зрения и следовать бизнес-субъекту.

С точки зрения текущего дизайна, должно быть более подходящим следовать за представлением, потому что состояние каждой модели изолировано, и все в модели следует своему собственному состоянию. С этой точки зрения действительно лучше следовать за представлением. В этом случае значение модели - модель представления.

Но таким образом, те бизнес-добавления, удаления, эффекты проверки и модификации, используемые моделью, могут присутствовать в каждой используемой модели, например:

Есть виды ABC, хозяйствующие субъекты XYZ, где:

A использует CRUD XY
B использует CRUD YZ
C использует CRUD XZ

Наша модель разработана так, чтобы следовать представлению ABC, и в ней должны быть некоторые эффекты избыточности. Например, Y существует в AB одновременно, и в коде может быть избыточность. С другой точки зрения, использование Y в AB само по себе не должно рассматривать повторное использование, и вызывающий процесс, который нужно повторно использовать, должен быть помещен на следующий уровень, то есть на обслуживание.

Таким образом, организационная структура становится:

  a
  b
  c
service
  x
  y
  z

И структура modelA:

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

Состав модели B:

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

Позже я напишу более бизнес-ориентированную демонстрацию и дам несколько предложений по использованию сценариев.

@xufei нужно руководство, как дядя

@xufei Можете ли вы поучиться на своем демо?Я беспокоюсь об этом в последнее время

Есть ли это в демо

Есть ли это в демо

Я думаю, что разумнее иметь и бизнес-модель, и модель представления.Например, у текущего пользователя может быть пользовательская модель для глобальной обработки.
Если другие компоненты включают информацию о текущем пользователе, просто подключитесь к модели пользователя напрямую.Это зависит от потребностей бизнеса

@ liSong5713 Список пользователей щелкнул в списке сведений о пользователях, сведения о пользователе щелкнули в управлении ключами, должны ли они быть помещены в ту же модель пользователя

@lwbGH Это зависит от обязанностей вашей модели. Модель пользователя может быть основной и часто используемой информацией о текущем авторизованном пользователе. Если вы хотите изменить подробную информацию пользователя, такую ​​как журнал операций пользователя, эта информация может быть полностью отличается от модели. Я думаю, что разделение модели заключается в небольшом:
Степень разделения состояния компонентов уровня , если простая страница соответствует модели уровня страницы, она будет сложной.

Конечно, его также можно выделить в пространстве имен, но в настоящее время пространство имен будет напрямую использоваться как имя состояния (специальные символы, такие как . , использовать нельзя)
. Не может использоваться в качестве ключа, вы можете использовать _. В настоящее время мы ограничены в пространстве имен. Модели можно разделить на модули по представлению и бизнесу, но пространство имен ограничено "имя_папки".