Dva: كيف يتم تطبيق نموذج التداخل (النمذجة)؟

العمل مثل هذا ،
على سبيل المثال ، هناك 5 منتجات مستقلة نسبيًا في التطبيق ، ولكل منتج نموذج مستقل نسبيًا.

في هذه الحالة ، ستكون طبقة واحدة فقط من النموذج ضيقة للغاية

بالطبع ، يمكن أيضًا تمييزه في مساحة الاسم ، ولكن حاليًا سيتم استخدام مساحة الاسم مباشرة كاسم الحالة (لا يمكن استخدام الرموز الخاصة مثل . )

ستكون طبقة واحدة فقط من النموذج ضيقة للغاية

لم أفهم

تضمين التغريدة

بالنظر إلى المستند ، فإن النموذج يحتوي على طبقة واحدة فقط ماديًا. إذا كان هناك عدد كبير من النماذج ، فمن المحتمل أن يكون هناك تعارض في مساحة الاسم التي تحمل نفس الاسم (خاصة بالنسبة للمشاريع الكبيرة ، تحتوي بعض النماذج على نفس الدلالات). في هذه المرة ، قد يتعين عليهم أن يكونوا في مساحة الاسم. ، أضف البادئة بشكل سائد كتمييز بين الوحدات.

لذا أود أن أسأل ما إذا كان هناك نموذج تداخل أو مخطط أفضل؟

لا يُنصح بالتداخل في مكان عميق جدًا في الحالة. إذا كنت لا تزال تتداخل مع النموذج ، فسيكون الأمر أكثر تعقيدًا. ويشعر أن هناك مشكلة في التصميم.
لا أفهم السؤال ، هل يمكنك أن تعطيني عرضًا توضيحيًا بسيطًا؟

هذا السؤال مفهوم تقريبًا ، ناقشناه بالأمس ، وهو يتعلق بشكل أساسي بمعنى النموذج ، وهناك اتجاهان: متابعة وجهة النظر واتباع كيان الأعمال.

من وجهة نظر التصميم الحالية ، يجب أن يكون من الأنسب اتباع وجهة النظر ، لأن حالة كل نموذج معزولة ، وكل شيء في النموذج يتبع حالته الخاصة. ومن هذا المنظور ، من الأفضل بالفعل اتباع وجهة النظر. هذا في هذه الحالة ، فإن معنى النموذج هو عرض النموذج.

ولكن بهذه الطريقة ، قد توجد تأثيرات الأعمال المضافة والحذف والتحقق والتعديل المستخدمة بواسطة النموذج في كل نموذج مستخدم ، على سبيل المثال:

هناك طرق عرض ABC ، ​​كيانات الأعمال XYZ ، حيث:

يستخدم الخام XY
يستخدم B CRUD لـ YZ
يستخدم C CRUD الخاص بـ XZ

تم تصميم نموذجنا ليتبع طريقة عرض ABC ، ​​ويجب أن يكون هناك بعض تأثيرات التكرار فيه. على سبيل المثال ، يوجد Y في AB في نفس الوقت ، وقد يكون هناك تكرار في الكود. من وجهة نظر أخرى ، يجب ألا يأخذ استخدام Y في AB في الاعتبار إعادة الاستخدام ، ويجب وضع عملية الاستدعاء التي سيتم إعادة استخدامها في المستوى التالي ، أي الخدمة.

وهكذا يصبح الهيكل التنظيمي:

  a
  b
  c
service
  x
  y
  z

وهيكل النموذج أ:

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

هيكل النموذج ب:

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

لاحقًا ، سأكتب عرضًا توضيحيًا أكثر توجهاً نحو الأعمال ، وأقدم بعض الاقتراحات لاستخدام السيناريوهات

xufei يحتاج إلى توجيه مثل العم

xufei هل يمكنك التعلم من العرض التوضيحي الخاص بك؟أنا قلق بشأن هذا مؤخرًا

لاxufei التجريبي لديها ذلك؟

لاxufei التجريبي لديها ذلك؟

أعتقد أنه من المعقول أن يكون لديك كل من نموذج الأعمال ونموذج العرض ، على سبيل المثال ، يمكن أن يكون لدى المستخدم الحالي نموذج مستخدم للمعالجة العالمية.
إذا كانت المكونات الأخرى تتضمن معلومات المستخدم الحالية ، فما عليك سوى الاتصال بنموذج المستخدم مباشرة.ذلك يعتمد على احتياجات العمل

تم النقر على قائمة مستخدم

lwbGH هذا يعتمد على مسؤوليات النموذج الخاص بك. يمكن أن يكون نموذج المستخدم هو المعلومات الأساسية
درجة مشاركة حالة مكونات المستوى ، إذا كانت صفحة بسيطة تتوافق مع نموذج على مستوى الصفحة ، فستكون معقدة

بالطبع ، يمكن أيضًا تمييزه في مساحة الاسم ، ولكن حاليًا سيتم استخدام مساحة الاسم مباشرة كاسم الحالة (لا يمكن استخدام الرموز الخاصة مثل . )
. لا يمكن استخدامه كمفتاح ، يمكنك استخدام _. حاليًا ، نحن مقيدون في مساحة الاسم. يمكن تقسيم النماذج إلى وحدات حسب العرض والعمل ، ولكن مساحة الاسم مقيدة بـ "اسم ملف_الملف".