Dva: モデルのネスト(モジュール化)を実装するにはどうすればよいですか?

作成日 2017年02月17日  ·  14コメント  ·  ソース: dvajs/dva

モジュール性に対する強い需要があり、

第1レベルのモデルしかない場合は、モジュール化に適さないモデルが多数存在する可能性があります。

モデルのモジュール化を実現する方法がわかりませんか?

faq question

最も参考になるコメント

この質問は大まかに理解されています。昨日話し合いました。主にモデルの意味についてです。ビューに従うことと事業体に従うことの2つの傾向があります。

現在の設計の観点からは、各モデルの状態が分離されており、モデル内のすべてが独自の状態に従うため、ビューに従う方が適切であるはずです。この観点からは、ビューに従う方が確かに優れています。この場合、モデルの意味はビューモデルです。

ただし、このように、モデルで使用されるビジネスの追加、削除、チェック、および変更の効果は、使用されるすべてのモデルに存在する可能性があります。たとえば、次のようになります。

ビュー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);
    }
  }
}

後で、よりビジネス指向のデモを作成し、シナリオの使用に関するいくつかの提案をします。

全てのコメント14件

ビジネスはこんな感じ、
たとえば、アプリには比較的独立した5つの製品があり、各製品には比較的独立したモデルがあります。

この場合、モデルの1つのレイヤーのみが非常に窮屈になります

もちろん、名前空間でも区別できますが、現在、名前空間は状態名として直接使用されます( .などの特別な記号は使用できません)

モデルの1つのレイヤーだけが非常に窮屈になります

理解できませんでした

@codering

ドキュメントを見ると、モデルには物理的に1つのレイヤーしかありません。モデルが多数ある場合、同じ名前の名前空間の競合が発生する可能性があります(特に大規模なプロジェクトの場合、一部のモデルは同じセマンティクスを持ちます)。今回は、名前空間上にある必要があるかもしれません。、モジュール間の区別として主にプレフィックスを追加します。

それで、より良いモデルのネストまたはモジュール化スキームがあるかどうかを尋ねたいと思いますか?

状態の奥深くに入れ子にすることはお勧めしませんが、それでも入れ子にすると複雑になり、デザインに問題があるように感じます。
質問がわかりません。簡単なデモをお願いします。

この質問は大まかに理解されています。昨日話し合いました。主にモデルの意味についてです。ビューに従うことと事業体に従うことの2つの傾向があります。

現在の設計の観点からは、各モデルの状態が分離されており、モデル内のすべてが独自の状態に従うため、ビューに従う方が適切であるはずです。この観点からは、ビューに従う方が確かに優れています。この場合、モデルの意味はビューモデルです。

ただし、このように、モデルで使用されるビジネスの追加、削除、チェック、および変更の効果は、使用されるすべてのモデルに存在する可能性があります。たとえば、次のようになります。

ビュー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これは、モデルの責任によって異なります。ユーザーモデルは、現在ログインしているユーザーの基本的で一般的に使用される情報です。ユーザーの操作のログなど、ユーザーの詳細情報を変更する場合、この情報は次のようになります。モデルとは完全に異なります。モデルの分割は少しあると思います。
レベルコンポーネントの状態の共有の程度、単純なページがページレベルのモデルに対応する場合、それは複雑になります

もちろん、名前空間でも区別できますが、現在、名前空間は状態名として直接使用されます( .などの特別な記号は使用できません)
。キーとして使用することはできません。_を使用できます。現在、名前空間に制約があります。モデルはビューとビジネスによってモジュールに分割できますが、名前空間は「folder_filename」によって制約されます。
image

このページは役に立ちましたか?
0 / 5 - 0 評価