MVP و UserControls و الاحتجاج

Question

أنا في وجود بعض المرح في محاولة للحصول على رأسي حول بعض MVP stuf, لأنها تتعلق عناصر تحكم المستخدم.أنا باستخدام .صافي WinForms (أو شيء قريب من ذلك) والإشراف تحكم نمط (أعتقد أنا :).

التحكم المستخدم هو نفسه جزء من MVP التطبيق (من وجهة نظر مقترن مقدم الخ).مقدم دائما بدأت أولا ، ويبدأ نموذج(s) ثم نظر(ع).عرض يبني واجهة المستخدم ، وهي جزء من التي سوف تكون جديدة UC التي هي عرض.

الآن (شكل) مقدم يحتاج إلى معرفته حول UC مقدم, لكن أعتقد أنه لا يعرف أي شيء عن كيفية عرض يتكون.شكل المذيع لا, على سبيل المثال, أعرف أن UC هو جزء من شكل ضوابط جمع, ولا ينبغي له.

وعلاوة على ذلك ، فإن تصميم خبرة لا ينبغي أن يتغير ؛ IOW dev يرى (شكل) يجب أن تكون قادرا على تحديد المستخدم التحكم من مربع الأدوات وإسقاط ذلك على شكل.

لذا على أسئلتي.أولا هي الافتراضات أعلاه صحيح ؟ مضلل إلى حد ما?عبث ؟ WTF تفكر ؟

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

أي أفكار أو اقتراحات أو تعليقات قبلت بكل سرور.

-- nwahmaet

Answer 1

مقدم ينبغي أن تكون من حيث الفكر "دولة مستقلة" في عرض الصف.وهذا يعني أنه هو المسؤول عن ضمان أن عرض عرض نموذج الدولة في المزامنة.السبب في أنني أحمل هذا الأمر لأن "نمط" من MVP غالبا ما يضيع في وجهة النظر العقائدية من كيف أشياء يجب أن تكون مفصولة.يبدو أن هذا هو أحد الأسباب مارتن فاولر قررت في محاولة توضيح المصطلحات حول MVP نمط.

بلدي يفضل نكهة MVP هو السلبي عرض, وجوابي هو أساس الخروج من ذلك.

انا تنفيذ المركب المستخدم ضوابط أشكال كثير من الأحيان باستخدام السلبي عرض نمط.هناك أساسا 3 تكوينات مختلفة:

1. واحد مقدم لجميع عناصر تحكم المستخدم في التسلسل الهرمي.لشد عرض باستخدام واجهة.
2. واحد مقدم لكل مستخدم التحكم في المركبة شجرة.كل من الوالدين مقدم هي المسؤولة عن إنشاء و تهيئة الأطفال العروض.عناصر تحكم المستخدم يتم إنشاؤها في وقت التصميم و هي قادرة على العمل بدون مقدم (مع أي عرض السلوك)
3. واحد مقدم لكل مستخدم التحكم في المركبة شجرة.جميع العروض هي المتباعدة من خلال أعلى مستوى تحكم فئة.تحكم الطبقة هي المسؤولة عن construcing مقدم ، الأسلاك ، وتنسيق الأحداث.

على الرغم من أن هذا هو الحل الأخير بالنسبة لي (بسبب تعقيدها), أعتقد أن الخيار الأخير هو الحل الذي تبحث عنه.

Answer 2

ولقد تم تشغيل ضد هذه المشكلة بالضبط لعدة أشهر في تطبيق أعمل على. استنتاج مفاده أن جئت مؤخرا جدا هو أنه قد يكون في كثير من الحالات من المستحيل تطبيق نمط MVP على المستويين نافذة والتحكم المستخدم، دون "كسر" النمط.

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

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

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

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

Answer 3

وأسئلتك هي عامة أن مجموعة متنوعة من برامج افتقدوا.

في هذه الحالة تخميني هو أنه يجب أن ننظر إلى نمط المراقب.

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

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

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