Dva: Bagaimana cara menerapkan Model nesting (modularization)?

Bisnis itu seperti ini,
Misalnya, ada 5 produk yang relatif independen dalam aplikasi, dan setiap produk memiliki model yang relatif independen.

Dalam hal ini, hanya satu lapisan model yang akan sangat sempit

Tentu saja bisa juga dibedakan pada namespace, tetapi saat ini namespace akan langsung digunakan sebagai nama negara (simbol khusus seperti . tidak dapat digunakan)

Hanya satu lapisan model akan sangat sempit

Tidak mengerti

@codering

Melihat dokumen, model secara fisik hanya memiliki satu lapisan. Jika ada banyak model, kemungkinan akan ada konflik namespace dengan nama yang sama (terutama untuk proyek besar, beberapa model memiliki semantik yang sama). kali ini, mereka mungkin harus berada di namespace., Secara dominan menambahkan awalan sebagai pembeda antar modul.

Jadi saya ingin bertanya apakah ada model bersarang atau skema modularisasi yang lebih baik?

Tidak disarankan membuat nest terlalu dalam di negara bagian. Jika model masih bersarang, akan lebih rumit karena terasa ada masalah dengan desain.
Saya tidak mengerti pertanyaannya, dapatkah Anda memberi saya demo sederhana?

Pertanyaan ini secara kasar dipahami. Kemarin kita membahasnya. Ini terutama tentang arti model. Ada dua kecenderungan: mengikuti pandangan dan mengikuti badan usaha.

Dari sudut pandang desain saat ini, seharusnya lebih sesuai untuk mengikuti pandangan, karena status masing-masing model terisolasi, dan semua yang ada dalam model mengikuti keadaannya sendiri.Dari perspektif ini, memang lebih baik mengikuti pandangan. Dalam hal ini yang dimaksud dengan model adalah model tampilan.

Tetapi dengan cara ini, penambahan, penghapusan, pemeriksaan, dan efek modifikasi yang digunakan oleh model tersebut mungkin ada di setiap model yang digunakan, misalnya:

Ada pandangan ABC, badan usaha XYZ, dimana:

A menggunakan CRUD dari XY
B menggunakan CRUD YZ
C menggunakan CRUD XZ

Model kami dirancang untuk mengikuti tampilan ABC, dan harus ada beberapa efek redundansi di dalamnya. Misalnya, Y ada di AB pada saat yang sama, dan mungkin ada redundansi dalam kode. Dari sudut pandang lain, penggunaan Y di AB itu sendiri tidak boleh mempertimbangkan penggunaan kembali, dan proses pemanggilan yang akan digunakan kembali harus ditempatkan di tingkat berikutnya, yaitu layanan.

Dengan demikian, struktur organisasi menjadi:

  a
  b
  c
service
  x
  y
  z

Dan struktur model A:

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

Struktur modelB:

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

Nanti, saya akan menulis demo yang lebih berorientasi bisnis, dan memberikan beberapa saran untuk penggunaan skenario

@xufei membutuhkan bimbingan seperti Paman

@xufei Bisakah Anda belajar dari demo Anda?Saya khawatir tentang ini baru-baru ini

Apakah demo

Apakah demo

Saya rasa lebih masuk akal untuk memiliki model bisnis dan model tampilan. Misalnya, pengguna saat ini dapat memiliki model pengguna untuk pemrosesan global.
Jika komponen lain melibatkan informasi pengguna saat ini, cukup sambungkan ke model pengguna secara langsung.Itu tergantung pada kebutuhan bisnis

@ liSong5713 Daftar pengguna mengklik daftar detail pengguna, detail pengguna mengklik manajemen kunci apakah ini harus ditempatkan dalam model pengguna yang sama

@lwbGH Ini tergantung pada tanggung jawab model Anda. Model pengguna dapat menjadi informasi dasar dan umum digunakan dari pengguna yang saat ini masuk. Jika Anda ingin mengubah informasi rinci pengguna, seperti log operasi pengguna, informasi ini dapat benar-benar berbeda dari model. Menurut saya, pembagian model terletak sedikit:
Tingkat berbagi status komponen tingkat , jika halaman sederhana sesuai dengan model tingkat halaman, itu akan menjadi rumit

Tentu saja bisa juga dibedakan pada namespace, tetapi saat ini namespace akan langsung digunakan sebagai nama negara (simbol khusus seperti . tidak dapat digunakan)
. Tidak dapat digunakan sebagai kunci, Anda dapat menggunakan _. Saat ini, kami dibatasi dalam namespace. Model dapat dibagi menjadi modul berdasarkan tampilan dan bisnis, tetapi namespace dibatasi oleh "nama folder_file".