يجب أن أستمر في العمل كائنات منفصلة عن واجهة المستخدم في برنامج الأغذية العالمي?

Question

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

Answer 1

والتوجيه من فرق منتج مايكروسوفت (على سبيل المثال، وهذا ما فريق مزيج يستخدم) هو العمارة الموديل عرض-ViewModel، وهو البديل من نمط MVC الشعبية. وهناك نقطة انطلاق جيدة http://blogs.msdn.com /johngossman/archive/2005/10/08/478683.aspx . وهناك أيضا مقالات جيدة الدكتور WPF حول هذا الموضوع.

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

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

Answer 2

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

Answer 3

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

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

Answer 4

ولا يجري المعلم WPF، لا أستطيع أن أكون متأكدا، ولكن السبب المعتاد لفصل M الخاص بك، V وC وحتى تتمكن من اختبار جهاز تحكم مستقل للنظر، وعلى العكس من ذلك.

لا شيء يمنعك، بطبيعة الحال، ولكن يجب أن يكون هناك الكثير أكثر قابلة للاختبار (أي وحدة الاختبارات) اذا كان منفصل. نمط MVP، التي عادة ما تكون تلك التي تروج MS، هو أكثر الموجهة نحو مقدم (أي شكل WPF الخاص بك) وجود المزيد من السيطرة، و thats غرامة جدا ....

Answer 5

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

وهنا عينة من تجربتي:

<اقتباس فقرة>   

ولقد عملت مع WPF قليلا، على   مشروع صغير نسبيا، حيث   تم تعريف طبقة رجال الأعمال بالفعل،   ونحن بحاجة فقط لإنشاء مستخدم   واجهه المستخدم. وبطبيعة الحال، واجهة   كان يعرف انها قواعد والأشياء الخاصة   أنه كان يعمل مع ول   تم تعريف التطبيق فقط ل   UX الذي اخترناه لخلق منطقتنا   أشياء محددة، ومعظمها من خلال توسيع   DependencyObject (أساسا لأغراض Data Binding).

     

وبعض الناس قد يقولون أنه غير موافق   استخدام كائنات التبعية لأنها   لا تكون للتسلسل (في الواقع هم   هي - إلى XAML) فانها تجلب   التبعية لبرنامج الأغذية العالمي (ل   مساحة System.Windows)، وبعض   الحجج الأخرى. أيضا،   دعم DependencyObjects الآخرين   خيارات، مثل خصائص المرفقة   و الاعتماد خصائص . الآخرين   قد ترغب في استخدام على سبيل المثال    INotifyPropertyChanged إذا كان   من المنطقي، والبعض الآخر قد يقول أن   كل من هذه الأنماط لا تنتمي في   طبقة أخرى من واجهة المستخدم.   (إذا كنت تريد معرفة المزيد هناك   بعض جيدة WPF ربط البيانات   المواد في مكتبة MSDN،   بما في ذلك أفضل الممارسات ل   برفومنس واجهة المستخدم)

وانه نوع من سوء أن مايكروسوفت اختارت لإضافة بعض الأشياء الجيدة إلى مساحة الاسم System.Windows، بدلا من ذلك، على سبيل المثال، إلى System.ComponentModel حيث في رأيي أنها قد تكون أكثر فائدة (من خلال توفير كل هذه الأنماط الهامة لا إلا أن برنامج الأغذية العالمي ولكن إلى .NET Framework).

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

<اقتباس فقرة>   

في النهاية، كل شيء يعتمد عليك، على غرار البرمجة والقرارات المعمارية ومعرفتك لهذه التكنولوجيا.

     

وإذا كان يبدو أكثر طبيعية للقيام بذلك بطريقة ما، من قبل الكتاب، والتفكير why you should وwhy should you not قبل اتخاذ أي قرار!