Maui: قد لا يكون MVU كما تعتقد

شكرًا aspnetde ، أتمنى أن تنضم إلينا ونحن نعمل على تنفيذ هذه الفكرة على مدار الـ 18 شهرًا القادمة أو نحو ذلك. بالنظر إلى تاريخك مع MVU ، أتوقع أن يكون لديك الكثير للمساهمة.

أعتقد أنه من السابق لأوانه القول أن .NET MAUI هي MVU أو ليست كذلك لأننا لم نقم ببنائها بعد . :)

نعم ، لدينا نموذج أولي. نعم ، إنها مستوحاة من تجربة المذنب. ونعم ، نحن نعلم أن هناك قلقًا من أن ما أظهرناه حتى الآن لا يتطابق مع تعريف الجميع لـ MVU.

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

كيف تتوقع رؤية C # MVU في .NET MAUI؟

ما هي ميزات اللغة الجديدة التي تراها مطلوبة ، إن وجدت؟

هل يمكن / يجب أن نفكر في دمج Fabulous و / أو ما هي الأنماط التي من المنطقي جعلها مشتركة بين C # و F # ، وما الذي يجب أن يكون مختلفًا؟

كيف تتوقع رؤية C # MVU في .NET MAUI؟

هل سمعت من قبل أي شخص يقول C # MVC أو C # MVVM؟ _Model-View-Update_ ويعرف أيضًا باسم Elm Architecture_ هو نمط معماري محدد جيدًا ، وليس تطبيقًا يعتمد على اللغة.

ما هي ميزات اللغة الجديدة التي تراها مطلوبة ، إن وجدت؟

• بينما تساعد أنواع الاتحاد في تبسيط تعريف الرسائل بشكل كبير ، يمكن القيام بذلك من خلال واجهات / فئات مجردة وفئة فرعية لكل رسالة ، على الرغم من أن ذلك يتطلب المزيد من التعليمات البرمجية المعيارية للكتابة.
• من أجل معالجة الرسائل ، تكون مطابقة النمط مفيدة إذا لم تكن مطلوبة. أعتقد أن الحالة الحالية لتعبيرات التبديل C # جيدة بالفعل بما يكفي لذلك ، حيث سيكون شكل الرسائل بسيطًا.
• أخيرًا وليس آخرًا ، أهم ميزة أراها هي الثبات افتراضيًا ومقارنات المساواة الهيكلية الممكنة. بقدر ما أتذكر الاقتراح الحالي للسجلات في C # 9 (ويعرف أيضًا باسم فئات البيانات) ، فإن هؤلاء سيوفرون ذلك بالضبط.

لذا فإن C # 9 ، بينما لا تزال صاخبة أكثر من F # ، من الجيد الانتقال من وجهة نظري الحالية.

هل يمكن / يجب أن نفكر في دمج Fabulous و / أو ما هي الأنماط التي من المنطقي جعلها مشتركة بين C # و F # ، وما الذي يجب أن يكون مختلفًا؟

كما هو مكتوب أعلاه ، لا ينبغي أن يكون هناك أي شيء خاص بلغة معينة في النهج العام لأن MVU نفسه هو مجرد أسلوب معماري أو نموذج تطبيق كما تسميه.

قدمتTimLariviere بعض المقترحات للمضي قدمًا في Fabulous مؤخرًا ، والتي تتضمن أيضًا أفكارًا حول SwiftUI-like DSL. قد ترغب في إلقاء نظرة و / أو المشاركة هناك أيضًا.

بالمناسبة: لقد أجريت مقارنة 1: 1 بين XF + C # + MVVM و XF + F # + MVU العام الماضي ، يمكن العثور على النتائج هنا - بما في ذلك شفرة المصدر.

أعتقد أنه من السابق لأوانه القول أن .NET MAUI هي MVU أو ليست كذلك

لا يتعلق الأمر بما إذا كان MAUI سيكون MVU في النهاية. يتعلق الأمر بالعينة الموجودة في مدونة الإعلانات التي أثارت بالفعل الكثير من الارتباك في المجتمع. يجب أن أفترض أساسًا أن المؤلفين لم يبحثوا حقًا في MVU حتى الآن. الحديث عن "C # MVU" لا يجعل هذا أفضل.

أتفق مع aspnetde و @ forki ، المشكلة هنا تكمن في التواصل.

أعتقد أن لا أحد منا يجادل بإسقاط أو تغيير C # DSL المستوحى من المذنب لـ MAUI / XF ، ولكن حتى لو أخذنا ما تم إنجازه به حتى الآن ، فلا يزال هذا يستخدم مفهوم الربط الأساسي الذي يعد جزءًا من نمط MVVM .

هذا شيء كنت أطلبه مرارًا وتكرارًا في التواصل المباشر وبعيدًا عن المشكلات ، ربما يكون من الجيد أن يقرأ كل شخص مشارك أنماطًا مختلفة مثل MVVM و MVU.

ومع ذلك ، هناك طريقة لتطبيق MVU على رأس MVVM ، لكن يبقى السؤال ما هي المشكلة التي ستحلها.

هل سمعت من قبل أي شخص يقول C # MVC أو C # MVVM؟

نعم ، أفهم أنه من الغريب قول C # أو XAML متبوعًا بنمط معماري مثل MVVM أو MVU. من بين المجتمع الأوسع للمطورين الذين تحدثت معهم ، هناك حاجة لتوضيح أنه يمكنك الاستفادة من أي عدد من التركيبات في مشروعك. ليس القصد من ذلك القول أن "C # MVVM" يختلف معماريًا عن "XAML MVVM" ، لكن الدمج ممكن وبالتالي فإن تجربة المطور ككل مختلفة قليلاً.

اعتقدت أن هذا الخيط قد يناقش كيف ستبدو MVU في .NET MAUI ، ولكن ربما تكون المناقشة الأكثر إنتاجية هنا هي كيف نتحدث عن تجارب مطور متعددة وأنماط معمارية داخل منتج واحد؟

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

يتعلق الأمر بالعينة الموجودة في مدونة الإعلانات التي أثارت بالفعل الكثير من الارتباك في المجتمع.

كانت هذه مساهمتي في المدونة وأعتذر عن الارتباك الذي أحدثته لك. لقد أخطأت في تقدير ذلك من خلال إضافة روابط إلى مدونة Elm و aspnetde التي كنا

يجب أن أفترض أساسًا أن المؤلفين لم يبحثوا حقًا في MVU حتى الآن.

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

يبقى السؤال ما هي المشكلة التي ستحلها.

dersia ، المشكلة العامة التي يتعين حلها هي منح المطورين الاختيار. إذا كنت تسأل ما الذي يحله MVU فوق MVVM ، فليس لدي أدنى فكرة - هذا ليس شيئًا يُطلب منك أو شيئًا نحاول القيام به.

إن إعادة البناء كما هو مقترح في # 28 و # 66 يتعلق جزئيًا بفصل ربط البيانات والأشياء المحددة لـ MVVM عن تطبيقات العارض ، بحيث إذا اخترت MVU ، فلن تأخذ ميزات إضافية مستخدمة في MVVM.

لم أتوقع مقدار الوزن الذي سيتحمله مقتطف الشفرة

لكن هذا هو اللحم ، أليس كذلك؟ وأنا آسف أنها لا تتطابق مع التسمية.

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

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

لست متأكدًا مما تبقى لأضيفه من جانبي. أعتقد أنني عبرت عن موقفي بصوت عالٍ وواضح :-). إذا كنت تنوي تنفيذ MVU ، فسوف تدفع نحو باب مفتوح. إذا كان هذا هو ما يمكن افتراضه من خلال النظر إلى المقتطف في منشور الإعلان ومستودع Comet ، فلا تتردد في القيام بذلك - ولكن _يرجى_ التوقف عن تسميته MVU.

شكرا.

كما ذكر دون في هذا الموضوع :-) - CC: dsyme

لا أفهم سبب تسمية هذا بـ MVU ، في حين أنه ليس كذلك. قد يكون نموذجًا رائعًا ويعمل بشكل رائع هنا - لماذا لا نأتي بمصطلح مناسب يناسب النموذج ولا يخلط بينه وبين؟

aspnetde ماذا بقي من جانبك؟ أفترض الكثير :).
قرأت بعض أجزاء من أطروحتك. يجب أن أقول أنني أحببت ذلك. قرأت أيضًا كتابًا من Don Syme عن F #. أنا أحب البرمجة الوظيفية. من تجربتي موجز ، لكن يصعب فهمه (فهم). تعد سهولة القراءة جزءًا مهمًا جدًا من دورة حياة التطوير. يتم إنفاق الكثير من الوقت في الواقع على قراءة التعليمات البرمجية. والعودية هي الكتابة فقط. يمكنك كتابتها مرة واحدة ، ولكن لا أحد تقريبًا يمكنه قراءتها (على غرار regexp).
في الماضي ، جربت Redux with Angular أثناء وقت إعداد النماذج الأولية / البحث في الشركة. هل هو نهج نصف الميش؟ لقد كانت تجربة قيمة. تعلمت أنه يجب علي الحرص على عدم تغيير الحالة ، ونتيجة لذلك لن أضطر إلى تذكر المجموعة بأكملها ، حيث يمكن أن تتغير الحالة بالضبط فجأة.
أنا أفهم فوائد الثبات ، لكنني رأيت عرضًا تقديميًا مع إريك ميجر الذي مزق رأسًا على شكل دبدوب فجأة ، ليبين لنا أن العالم الحقيقي قابل للتغيير.

إذن ما أود أن أشير إليه: أليس تفكيرنا الطبيعي ضد هذه النماذج؟ ما هي خبرتك؟

لدي الكثير من الخبرة مع XAML / C # / MVVM ، لذلك أتساءل لماذا يعتبر Don Syme XAML غير ضروري.
من واقع خبرتي ، فإنه يساعد على فصل الاهتمامات (واجهة المستخدم ، والعرض التقديمي ، والأعمال التجارية ، وما إلى ذلك المنطق). لست متأكدًا حقًا مما إذا كانت DSLs (علامات C #) و MVU تساعد في تحسين جودة الكود على المدى الطويل. المطورين غير المتمرسين / غير المهتمين سيخلطون بين المسؤوليات. أحتاج أيضًا إلى مزيد من الخبرة مع نمط MVU ، لفهمه بشكل صحيح ، لكنك جربت كلا النموذجين وهو مفيد جدًا للمجتمع بأكمله.
يرجى المشاركة بقدر ما تستطيع. شكراaspnetde!

شكرًا جزيلاً لكم (جميعًا) على تفهمكم

davidortinau ربما كان هناك سوء فهم هنا ، أنا

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

أعتقد أننا ما زلنا في مرحلة لا يزال بإمكاننا العودة إليها وإصلاحها. لنفعل ذلك بشكل صحيح ، أسوأ شيء يمكن أن يحدث هو أن مجتمع XF / Maui يفهم MVU على أنه شيء آخر غير بقية العالم.

ومع ذلك ، فأنا من أشد المعجبين بـ MVU وأحب أيضًا MVVM ، وأعتقد أن أسلوب MVVM الطليق (ليس لدي اسم أفضل بعد) كما هو الحال في Comet وما تم تقديمه حتى الآن رائع ويساعد الكثير من المطورين وسأدعمه ، أعتقد أنه يجب علينا إصلاح التسمية.

تحرير: تسربت الاتصالات المفقودة من المسابقة.

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

tomasfabian هذا خطأ.

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

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

isaacabraham ربما أنت على حق ، وأنا أعتذر عن ذلك. انها غلطتي. أعلم أن تسمية الأشياء أمر مهم ، ولكن من ناحية أخرى عنوان المشكلة هو "MVU قد لا يكون كما تعتقد". لذلك نأمل أن يكون موضوعًا أكثر شمولاً من تسمية الأشياء.
شكرا لك توماس

tomasfabian ، سأكون سعيدًا جدًا للدردشة معك حول إيجابيات وسلبيات MVU أو FP أو أي شيء حقيقي أو وهمي 😊 فقط لا تعتقد أن هذا هو المنتدى المناسب لذلك.

تضمين التغريدة
بقدر ما ستكون ميزات اللغة والتغييرات المعمارية مفيدة ، آمل أن أتمكن من المساهمة ببعض الاقتراحات:

* الكلمة الرئيسية new والضوضاء النحوية الأخرى.
على عكس Dart أو Kotlin ، من المحتمل أن تكون C # عالقة مع كلمة رئيسية مطلوبة new إلى الأبد ، لأن جعلها اختيارية هو تغيير فاصل واقتراح غير شائع حتى كتوجيه اختيار لكل ملف. لذا بدلاً من ذلك ، ربما فئة ثابتة رسمية (ومحتفظ بها) (أو فئة ثابتة لكل مساحة اسم عرض MAUI) تحتوي على طرق ثابتة تقوم فقط بلف المنشئات وتهيئة أي خصائص للتهيئة فقط ، إن وجدت ، على الأقل لمجموعة أساسية من عرض الكائنات MAUI. ثم يمكننا وضع التوجيه using static في الجزء العلوي من ملفات .cs الخاصة برمز العرض ثم استدعاء الطرق بدون الضوضاء النحوية new . سيؤدي ذلك إلى تقليل الفوضى والضوضاء لوظائف عرض C # قليلاً. بالطبع يمكن إنشاء أغلفة مُنشئ الطريقة الثابتة تلقائيًا بواسطة المجتمع (لقد فعلت شيئًا مشابهًا لـ Xamarin ، نماذج لاستخدامها مع CSharpForMarkup) ، ولكن سيكون من الجيد أن يكون لديك مجموعة داخل الصندوق تتم صيانتها بواسطة مشروع MAUI.

بالإضافة إلى ذلك ، فإن أي مقترحات لغة C # من شأنها أن تساعد في تقليل الفوضى النحوية أو الضوضاء في أشجار التعبير الكبيرة (كما هو شائع في وظائف عرض MVU / Comet / CSharpForMarkup) ستساعد بشكل كبير. لقد قطعت C # 9 شوطًا طويلاً في هذا الصدد لتحسين أجزاء M و U من MVU لكن الجزء V لا يزال من الحكمة في بناء جملة نقاط الألم.

* خصائص التمديد *
أعرف أن اقتراح "extension-every" قيد الانتظار في الوقت الحالي ، ولكن هناك شيء واحد يمكن أن يكون مفيدًا لـ MVVM-with-C # -markup (مثل CSharpForMarkup مع Xamarin.Forms) ، وهو خصائص الامتداد. باستخدام CSharpForMarkup ، يجب تنفيذ كل مساعد باستخدام طريقة الامتداد ، ولكن في بعض الحالات ، قد تبدو خاصية الامتداد (التي يمكن استخدامها في مُهيئ الكائن) أفضل كثيرًا:

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

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

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

يبدو أن MAUI تقدم الآن هاتين القطعتين الأساسيتين ، وهو أمر رائع! ومع ذلك ، يبدو على الأقل على المستوى السطحي مرتبطًا بشكل وثيق بطريقة إدارة الحالة التي قد يقولها البعض في مجتمع MVU أقرب إلى MVVM من MVU أو بنيات واجهة مستخدم "وظيفية" مماثلة. أعتقد أن ما أفضّله هو الاحتفاظ بالقطعتين الأساسيتين اللتين ذكرتهما أعلاه (رسم بياني لجسم عرض خفيف الوزن ومحرك اختلاف فعال) ، وتزوجها بنظام مكون منخفض المستوى يمكن وضع MVU أو Comet فوقه بكفاءة ، وفقًا للمطور. خيار. ربما هذا هو الهدف بالفعل ، ولا أراه؟ إذا كان الأمر كذلك ، فأنا أرغب في رؤية المزيد من النقاش حول ذلك مع بعض الأمثلة الأساسية على الأقل.

aspnetde لماذا حذفت

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

من واقع خبرتي ، يساعد [MVVM] في فصل الاهتمامات (واجهة المستخدم والعرض التقديمي والأعمال وما إلى ذلك من منطق)

نعم إنها كذلك. لقد قمت ببعض التجارب الجيدة مع تطبيقات Xamarin.iOS الكبيرة و Xamarin.Android التي تم إنشاؤها باستخدام MvvmCross. على الرغم من أنني أفضل المكتبات على الأطر اليوم ، أعتقد أن كل هذه المشاريع (بعضها مع ستة أرقام LOC) كانت ناجحة ، من الناحية الفنية وكذلك من منظور الأعمال.

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

أليس تفكيرنا الطبيعي ضد هذه النماذج ([MVU])؟ ما هي خبرتك؟

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

لست متأكدًا حقًا مما إذا كانت DSLs (علامات C #) و MVU تساعد في تحسين جودة الكود على المدى الطويل.

في حين أن كلا من MVU و MVVM لهما مزايا مختلفة ، فإن كلاهما لهما أيضًا عيوب مختلفة.

على الرغم من اعتبار مشاريع MVVM الخاصة بنا ناجحة ، فقدنا أنا وفريقي بعض الشعر بسبب تصحيحها. في أحد المشاريع على وجه الخصوص ، بدأنا نعاني من التعقيد الناجم عن نقص الخبرة من أعضاء الفريق الجدد ، وسوء الفهم - كما أشرت بالفعل. أعتقد أن هذا أقل احتمالًا في MVU عند تطبيقه بشكل صارم ، لأنه يحدد حدود كيفية عمل الأشياء بشكل ضيق للغاية ، بحيث يكون من الصعب تقريبًا الخروج من ذلك وبناء الأشياء بطريقة خاطئة ، من العكس.

بالنسبة لـ MVU أرى مشكلتين رئيسيتين. أولاً: التحجيم. يدافع الكثيرون عن برنامج واحد. أنا متشكك هنا (وأعتقد أن البرامج / الوحدات المتعددة ستكون طريقة أفضل). ثانيًا: في الوقت الحالي ، يوجد شيء مثل رائع فوق Xamarin. إنها طبقة تجريد أعلى طبقة تجريد أعلى طبقة تجريد أعلى iOS / Android. هذا قدر هائل من التعقيد. لذا فأنت لا تتعامل فقط مع الأخطاء التي لا تحل ولا يهتم بها أحد ، ولكنها أيضًا مهمة شاقة وغير سارة إلى حد ما لتحديث طبقة تجريد واحدة (رائعة) عندما تتغير الأخرى (Xamarin.Forms).

هذا هو المكان الذي أرى فيه فرصة كبيرة لـ MAUI. أود بصراحة أن أرى المشرفين الرائعين يتعاونون مع Microsoft هنا. وآمل حقًا ألا تفسدها Microsoft ، كما فعلت أجزاء أخرى من المؤسسة في الماضي.

توماس

عندما كنت أقرأ الإعلان الرسمي في ذلك اليوم ، فوجئت بما تم تقديمه هناك كـ MVU:

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

بقدر ما أشعر بالقلق ، هذا ليس MVU . لقد كتبت بالفعل بعض الأفكار حول سبب اعتقادي بذلك هنا .

دون سيم، الذي، كما فهمت، قضى عدة أشهر من 2018 على تنفيذ MVU على رأس Xamarin.Forms وبناء ما أصبح لاحقا رائع ، هو قليلا أكثر دبلوماسية ، ولكن بيت القصيد هو نفسه.

إذن ، ما هي وجهة نظري؟

• أرغب في تنفيذ النمط المعماري الحقيقي ، بغض النظر عما إذا كان في C # أو F #. قد يكون الوصول إلى الأشخاص الذين يقفون وراء Fabulous بداية هنا.
• إذا لم تكن مهتمًا بذلك ولكن لديك رؤية واضحة حول البناء فوق ما هو متاح اليوم كمكتبة Comet ، فالرجاء التفكير في استخدام اسم أكثر ملاءمة لهذا "نموذج التطبيق". اخترع شيئًا جديدًا. سمها MSMVU. ايا كان. لكن لا تبيع التفاح بالبرتقال.

هتافات!

لماذا يسمونه MSMVU؟ كان المذنب MVU ، وسيظل كذلك. وماوي هو MVU.

أعتقد أنه من السابق لأوانه القول أن .NET MAUI هي MVU أو ليست كذلك

لا يتعلق الأمر بما إذا كان MAUI سيكون MVU في النهاية. يتعلق الأمر بالعينة الموجودة في مدونة الإعلانات التي أثارت بالفعل الكثير من الارتباك في المجتمع. يجب أن أفترض أساسًا أن المؤلفين لم يبحثوا حقًا في MVU حتى الآن. الحديث عن "C # MVU" لا يجعل هذا أفضل.

لا يسبب أي لبس على الإطلاق. هو فقط أن بعض الناس لا يستطيعون التعامل معها من خلال رؤية C # تقوم بعمل MVU.

لما يستحقه ، فإن SwiftUI (التي يأخذ منها Comet معظم إلهامها) تميل إلى تسمية نمطها MVVM ، على الرغم من عدم وجود إرشادات صريحة.
لم أجد أي ذكر لـ MVU بالرغم من ذلك.

TimLariviere https://github.com/Clancey/Comet#key -concepts
أطلق المذنب عليه اسم MVU وفقد بالفعل نقطة حلقة الرسالة التي لدينا في التعريفات القديمة لـ MVU

لما يستحقه ، فإن SwiftUI (التي يأخذ منها Comet معظم إلهامها) تميل إلى تسمية نمطها MVVM ، على الرغم من عدم وجود إرشادات صريحة.

ليس من الخطأ حتى النظر إلى المثال في بداية هذا المنشور هنا: https://nalexn.github.io/clean-architecture-swiftui/

لم أجد أي ذكر لـ MVU بالرغم من ذلك.

يناقشها نفس المنشور باختصار أيضًا (كمزيج من SwiftUI + Redux = TEA). على الرغم من أنه يأخذ منعطفًا غريبًا إلى "العمارة النظيفة" 😄

منذ أن ذكرت هنا ، سأقول فقط بعض الأشياء.

• أعتقد أن MAUI رائعة وأعتقد أن التعرف على MVU كعمارة يمكن أن يكون مفيدًا للناس لفهم MAUI.

• من السهل التعلق بالكلمات ، وربما ينبغي علينا جميعًا أن نأخذ استراحة ونحاول ألا نقلق بشأنها في هذه المرحلة ، نظرًا لوجود متسع من الوقت لضبط الكلمات المستخدمة وأعتقد أن الرسالة حول المصطلحات الدقيقة كانت سمع. أنا شخصياً أعتقد أن Elm قد أثبت أن الاستخدام غير المشروط وغير المشروط لـ "MVU" يعني الرسائل الصريحة والتحديث الصريح والنماذج الوظيفية وإعادة حساب العرض الوظيفي والتحديث التفاضلي. ولكن هناك العديد من الاختلافات في MVU و MAUI هي نقطة واحدة في هذا الطيف (الذي يغطي كل الطريق إلى MVVM كنوع من نظام معالجة الرسائل المتزايدة يدويًا مع حالة ضمنية منتشرة قابلة للتغيير). يعد اتصال SwiftUI مثيرًا للاهتمام من هذا المنظور.

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

تضمين التغريدة
أعتقد أن المصطلح المناسب لهندسة المذنب / MAUI هو تباين في تدفق البيانات أحادي الاتجاه (أو UDF) ، ولكن ليس MVU لأن MVU هو في حد ذاته تباين محدد جدًا لـ UDF. من المؤكد أن MAUI / Comet مؤهل كإطار عمل UDF (كما هو الحال مع SwiftUI) ، لكنه غير مؤهل كإطار عمل MVU. هناك العديد من الاختلافات في UDF بما في ذلك MVU و Flux و Redux و React وما إلى ذلك ... ولكن من سوء الفهم استدعاء Comet MVU عندما لا يكون على الإطلاق MVU.

على عكس MVU ، فإن النموذج قابل للتغيير ، ويتم تغييره بواسطة التعليمات البرمجية في وظيفة العرض. ثم يتم ملاحظة الطفرات ، وتتفاعل الآراء مع تلك الطفرات بإعادة التقديم. لا يزال الأمر أحادي الاتجاه لأن العروض لا تتغير ، ولكن لا توجد وظيفة تحديث ولا رسائل ولا إرسال رسائل - وبالتالي ، لا توجد MVU. إنه أقرب إلى تباين أحادي الاتجاه لـ MVVM.

JeroMiya شكرا لك ، هل لديك مرجع لتلك المصطلحات؟

dsyme ليس لدي مرجع محدد لها ، لكنني بدأت أولاً سماع المصطلح المستخدم في الأيام الأولى من React ، وتحديداً في إشارة إلى React نفسها وبعض الأنماط المبكرة التي ظهرت مثل Redux و Flux. أتذكر مقالة وصفت عددًا من متغيرات UDF (غالبًا في مساحة React) ، لكن لا يمكنني العثور عليها الآن.

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

إنه ليس مفهومًا جديدًا بالطبع - حتى قبل رد فعل معظم أطر الويب من جانب الخادم مثل Asp.Net MVC و Rails وحتى PHP تعتبر من الناحية الفنية أحادية الاتجاه. لم يكن الأمر شائعًا في أطر عمل SPA السائدة وأطر عمل واجهة المستخدم من جانب العميل قبل ظهور React.

dsyme ليس لدي مرجع محدد لها ، لكنني بدأت أولاً سماع المصطلح المستخدم في الأيام الأولى من React ، وتحديداً في إشارة إلى React نفسها وبعض الأنماط المبكرة التي ظهرت مثل Redux و Flux. أتذكر مقالة وصفت عددًا من متغيرات UDF (غالبًا في مساحة React) ، لكن لا يمكنني العثور عليها الآن.

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

إنه ليس مفهومًا جديدًا بالطبع - حتى قبل رد فعل معظم أطر الويب من جانب الخادم مثل Asp.Net MVC و Rails وحتى PHP تعتبر من الناحية الفنية أحادية الاتجاه. لم يكن الأمر شائعًا في أطر عمل SPA السائدة وأطر عمل واجهة المستخدم من جانب العميل قبل ظهور React.

JeroMiya شكرًا على هذا ، هذا هو بالضبط كيف أفهم MVU.
أود أن أقول حتى أن أحد أقدم التطبيقات ولا يزال يستخدم بشكل رئيسي والذي يستخدم وأمثلة MVU في أفضل أشكاله هو MS Excel.

dsyme عند قراءة تعليقاتك أشعر بأنك تشير إلى MAUI كمصطلح للبنية التي تمت مناقشتها (CSharpForMarkup with MVVM).
من فضلك وضح لي أن هذا ليس ما تفهمه أن يكون MAUI أو إذا كان كذلك.
من وجهة نظري ، فإن MAUI هو مجرد إطار تطبيق MS التالي ليحل محل XF في وقت ما في المستقبل.

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

dersia شكرا لك! مجرد ملاحظة من تجربتي الخاصة مع CSharpForMarkup: إنه مستوى أقل قليلاً من MVVM - أكثر من مجموعة من طرق الإضافة والأدوات المساعدة لجعل ترميز C # أكثر بساطة وإطلالة أجمل. يمكنك بالتأكيد تنفيذ نمط MVVM باستخدامه لأنه يحتوي على مساعدين لجعل ارتباطات ViewModel أسهل ولكن ما انتهى بي الأمر هو تنفيذ كل منطق وجهة نظري في Redux بدلاً من ViewModels. كنت بحاجة فقط لإضافة بعض طرق الامتداد لربط خصائص العرض بمحددات الحالة ، والتي هي فقط Func<StateType, ChildStateType> قمت بالمرور إلى مشغلي Select و DistinctUntilChanged في متجر Redux State ، وهو Observable<StateType> . لا يوجد تدفق بيانات أحادي الاتجاه تمامًا ولكن لم يكن لدي طريقة ناضجة للقيام باختلاف شجرة كائن واجهة المستخدم وعرض وظائف مثل Fabulous الآن.

منذ بعض الوقت ، حاولت شرطة REST دفعها في حناجرنا التي لا ينبغي لنا جميعًا أن نطلق عليها REST. لا يزال الجميع يسمونه REST اليوم وما زلنا جميعًا على قيد الحياة وبصحة جيدة. 😉

bitbonk ، تخلى مجتمع REST عن هذا المصطلح لأنه أصبح عديم الفائدة أكثر من أي وقت مضى حيث تم إلقاء المزيد والمزيد من الأشياء في هذا المزيج. يستخدمون الآن "الوسائط التشعبية" للإشارة إلى نقل الحالة التمثيلية. REST ، اليوم ، تعني حقًا "ليس SOAP" أو "JSON عبر HTTP" ، ولم ينجح أي منهما في إيصال فكرته الأساسية. يأمل المعلقون هنا في تجنب نفس المصير لـ MVU.

davidortinautomasfabian، ليس لدي حتى الآن لرؤية مثال على MVU في ماوي. سأحاول عمل مثال الليلة. لقد فعلت شيئًا مشابهًا لـ WinForms هنا . أفترض أنه لا ينبغي أن يكون صعبًا جدًا.

JeroMiya شكرا لك ، هل لديك مرجع لتلك المصطلحات؟

dsyme ، أعتقد أنه نشأ مع React Flux ، لكنهم أشاروا إلى TIHan عندما تم تقديمه لأول مرة.

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirectional-data-flow

هذه هي محاولتي في مثال C #. ليس لدي MAUI متاحًا لتجربة هذا كمثال حقيقي. لا توجد معاينة ، أليس كذلك؟ على أي حال ، هذه ترجمة تقريبية للفكرة.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

لقد جربت مرة واحدة

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

أوافق تمامًا على أن MAUI MVU ليست MVU النموذجية ولها تأثير كبير من SwiftUI. كان مؤلفها الرئيسي كلانسي هيميسليف قد أوضح ذلك في جميع جلساته تقريبًا. نعلم جميعًا أن Redux يتأثر بشدة بـ MVU ، وكذلك SwiftUI و Flutter والعديد من الأطر الأخرى. لا أحد منهم نقي MVU.

لكنني متأكد من أننا نتفق جميعًا على أن أقرب نمط معماري لجميع هذه الأطر هو MVU. هذا هو السبب الذي يجعل الناس يشيرون إليه. وتذكر أننا نتحدث عن عنوان مدونة لإطار عمل سيتم إصداره بعد عام ونصف من الآن.

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

لكنني متأكد من أننا نتفق جميعًا على أن أقرب نمط معماري لجميع هذه الأطر هو MVU. هذا هو السبب الذي يجعل الناس يشيرون إليه.

الكلاب والخيول والقطط والشمبانزي كلها قريبة جدًا من بعضها البعض. من الآن فصاعدًا سأشير إليهم جميعًا بالقطط.

:) حسنًا ، ليس عليك ذلك. لكن دعني أخبرك بشيء: القطط والنمور والفهود وما إلى ذلك تسمى القطط. وأنا سعيد لأنك طرحته. Coz هذا هو الحال بالضبط هنا.

aspnetde : توماس ، مع كل ما قيل. أود أن أقول إن مدونة MVU الأصلية الخاصة بك هي واحدة من أفضل المقالات التي تشرح المفهوم بشكل واضح ودقيق للغاية. لقد تعلمت القليل منه. شكرا لك

@ libin85 هناك بالضبط المشكلة. لقد بدأت في تعداد الأشياء الموجودة بالفعل في فئة واحدة وتجاهلت الأشياء التي ليست كذلك. بوضع عينة MAUI في فئة MVU ، فإنك تضع أساسًا الشمبانزي في فئة القطط.

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

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

أوافق على أن الاسم يحتوي على تفاصيل صغيرة لا ينبغي أن يصرف الانتباه عن الجوانب الأكثر أهمية. ومع ذلك ، فإن السبب وراء طرحه هو أنني شخصياً لا أرى MAUI كجهد مجتمعي حيث سيؤدي الفطرة السليمة في النهاية إلى حل متفق عليه بشكل عام. إنه أحد منتجات Microsoft حيث يتم اتخاذ القرارات النهائية خلف الأبواب المغلقة. أنا هنا في كابكتي كعميل لأثير مخاوفي.

لكنني متأكد من أننا نتفق جميعًا على أن أقرب نمط معماري لجميع هذه الأطر هو MVU.

@ libin85 لا أوافق ، هذا هو أقرب نمط معماري. MVU عبارة عن مجموعة من القيود ضد ما يبدو عمومًا مثل MVP أو مقدم عرض النموذج. MVVM مشابه ، يتخذ اتجاهًا مختلفًا في أن مقدم العرض هو ViewModel مع روابط البيانات. MVP نفسه هو شكل مقيد من MVC. أعتقد أنه من الآمن أن نقول إن هؤلاء جميعًا من نسل MVC وحتى MVP ، لكن القول بأن MVU ينطبق على SwiftUI و Flux وما إلى ذلك هو جعل MVU مصطلحًا لا معنى له.

أوافق على أن الاسم يحتوي على تفاصيل صغيرة لا ينبغي أن يصرف الانتباه عن الجوانب الأكثر أهمية.

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

لما يستحق ، أعتقد أن MAUI "MVU" بديل جيد لخيار MVVM. تمامًا كما هو الحال مع REST ، لا يتعين عليك فعل الشيء التعريفي لجعل شيء مفيدًا وجيدًا. فقط من فضلك لا تفسد الاسم ببدائل تنحرف بوضوح عن النمط المحدد والمُحدد جيدًا. بعد كل شيء ، سيكون MVU _ أيضًا_ بديلاً جيدًا لخيارات MVVM و Comet.

لما يستحق ، أعتقد أن MAUI "MVU" بديل جيد لخيار MVVM. تمامًا كما هو الحال مع REST ، لا يتعين عليك فعل الشيء التعريفي لجعل شيء مفيد وجيد ، فقط من فضلك لا تشوش الاسم ببدائل تنحرف بوضوح عن تعريفه.

شكر كامل.

لماذا يسمونه MSMVU؟ كان المذنب MVU ، وسيظل كذلك. وماوي هو MVU.

@ saint4eva يتم "تسويقها" على أنها MVU.

أوافق على أن الاسم يحتوي على تفاصيل صغيرة لا ينبغي أن يصرف الانتباه عن الجوانب الأكثر أهمية.

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

لما يستحق ، أعتقد أن MAUI "MVU" بديل جيد لخيار MVVM. تمامًا كما هو الحال مع REST ، لا يتعين عليك فعل الشيء التعريفي لجعل شيء مفيدًا وجيدًا. فقط من فضلك لا تفسد الاسم ببدائل تنحرف بوضوح عن النمط المحدد والمُحدد جيدًا. بعد كل شيء ، سيكون MVU _ أيضًا_ بديلاً جيدًا لخيارات MVVM و Comet.

أتفق مع معظم ما قلته ، لكنني أعتقد أن "Maui MVU" لا يزال سيئًا ومربكًا. ربما أختار "Maui MVP" أو MVC. يعمل كلاهما وهو أقرب إلى ما يتم تقديمه في منشور المدونة من MVU.

تحرير الإضافة:
أنا حتى لست متأكدًا من مكان وجود النسخة المقترحة. أعني أن المنطق في MVVM يعيش في ViewModel ، مع MVU فإنه يعيش ضمن وظيفة التحديث ومع MVP يعيش في مقدم العرض ومع MVC يعيش في وحدة التحكم.

هل سيكون هناك منظر يعيش فيه كل شيء؟ أم أنها تعيش جميعًا في فئة معينة تم تسميتها بواسطة نموذج المجال ما يخدم الرؤية والمنطق والنموذج؟ هل من المفترض أن تكون النماذج فئات (أنواع) أو سجلات منفصلة؟

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

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

على سبيل المثال ، إذا كان T في State<T> عبارة عن فئة تشبه ViewModel ، وقمت بإضافة مجموعة منفصلة من فئات نماذج البيانات ، فإن ما ستنتهي به هو شيء مثل MVVM مع وجهة نظر أحادية الاتجاه.

من ناحية أخرى ، إذا أضفت نظام إدارة حالة يشبه Redux وقمت بتوصيل نموذج حالة Redux كـ T في State<T> ، فإن ما ينتهي بك الأمر هو شيء قريب جدًا من MVU ، على الرغم من أنها ليست متكاملة تمامًا مثل MVU التقليدية مثل Elm / Fabulous. ربما يمكنك إخفاء عروض MAUI خلف إطار عمل MVU ، كما يفعل Fabulous مع Xamarin.Forms؟

لست متأكدًا من كيفية تنفيذ نمط MVC أو MVP على MAUI. كمرور أولي تقريبي ، أفكر ربما إذا قمت بإنشاء فصل دراسي منفصل يعرض "الإجراءات" لوظيفة العرض. على سبيل المثال ، لنفترض أن لديك مربع حوار تأكيد MAUI ، وأن فئة "وحدة التحكم" الخاصة بك بها طريقة "ClickOK" وطريقة "ClickCancel". سيعمل عرض MAUI على إعادة توجيه أحداث النقر من العرض إلى وحدة التحكم ، والتي من شأنها إما إنشاء نموذج جديد أو تغيير النموذج الحالي.

JeroMiya أوافق ، بالتأكيد استخدام نمط Redux يمكن أن يجعله أقرب إلى MVU ويحافظ على العمارة أقل بكثير. أنا مستخدم سعيد لـ React-Redux و React-Hooks و ReactiveX ومؤخرًا لتطبيقات Blazor: القلب: Fluxor : القلب mrpmorris قد يساهم في هذه المحادثة.

هذه هي محاولتي في مثال C #. ليس لدي MAUI متاحًا لتجربة هذا كمثال حقيقي. لا توجد معاينة ، أليس كذلك؟ على أي حال ، هذه ترجمة تقريبية للفكرة.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

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

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

markmccaigue فيما يتعلق بالأداء: غالبًا ما تأتي أنظمة MVU مع عرض افتراضي (أو DOM الظاهري في حالة html) ومحرك مختلف. لذلك بعد اختلاف DOM مع DOM الظاهري ، يحتاج إطار العمل فقط إلى تطبيق تصحيح على DOM. عادة ما يكون هذا فعالًا للغاية ، خاصةً إذا كنت تعمل مع هياكل بيانات غير قابلة للتغيير.

مرحبا!!

سأغلق هذه المسألة الآن .. أود أن أجعل هذا مناقشة ولكن جيثب لا تريد أن تجعل ذلك يعمل: - /

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