MVVM หรือ MVC ต้องการใช้คลาสชุดเดียวกันสำหรับ WPF และ ASP.NET


11

ฉันเป็นมือใหม่ในแง่ของรูปแบบการออกแบบ ฉันเพิ่งเริ่มเรียนรู้ MVC เมื่อฉันได้ยินเสียงกระหึ่มใหม่ MVVM

ฉันต้องการเรียนรู้ข้อมูลเชิงลึกของทั้งสองสิ่งนี้โดยการออกแบบคลังโฆษณาเก่าและแอปพลิเคชันใบแจ้งหนี้ที่ฉันพัฒนาขึ้นสำหรับลูกค้า ฉันต้องการเขียนทั้งแอปพลิเคชัน WPF ที่ใช้ Windows และเวอร์ชันที่ใช้เว็บ ฉันต้องการใช้คลาสชุดเดียวกันถ้าเป็นไปได้ถ้าไม่ใช่อย่างน้อยก็มีการดัดแปลงเล็กน้อย

ฉันอ่านบทความสองสามข้อ แต่ฉันไม่ได้ติดตามสถาปัตยกรรมและแนวคิดระดับสูงของ. NET 3.5 และ 4 ที่กล่าวถึง ฉันต้องการที่จะย้ายทีละขั้นตอนโดยการออกแบบเฉพาะสิ่งที่ฉันต้องการในโครงการในชีวิตจริงของฉัน

มีการอ้างอิง MVVM ทีละขั้นตอนง่าย ๆ หรือไม่? MVVM เป็น super-set หรือ sub-set ของ MVC หรือไม่? รูปแบบใดที่ทันสมัยและฉันควรเลือกรูปแบบใดสำหรับแอพพลิเคชั่นของ Windows & Web?

มีคลาสบางคลาสที่ฉันไม่จำเป็นต้องเชื่อมต่อกับมุมมอง ในกรณีนี้การออกแบบคลาสเดียวกันในแบบ MVVM จะพิสูจน์ว่าเป็นแรงงานเสริม

คำตอบ:


11

มีการอ้างอิง MVVM ทีละขั้นตอนง่าย ๆ หรือไม่?

ใช่แล้ว ลองดูที่นี่

MVVM เป็น super-set หรือ sub-set ของ MVC หรือไม่?

MVVM เป็นของตระกูล MVC ดังนั้นถ้าคุณสามารถพูดได้มันเป็นส่วนย่อย เป็นตัวแปรในการแยก UI จากตรรกะทางธุรกิจที่อยู่ด้านล่าง ฉันจะอธิบายว่ามันเป็นพี่น้องของ MVC ตั้งแต่ยุคแรก ๆ ของคน OOP ได้ค้นหาวิธีที่จะแยก UI จากตรรกะของพวกเขา MVC เป็นแม่แบบแรกที่วิวัฒนาการ มันค่อนข้างง่าย แต่คนส่วนใหญ่ไม่ได้ทำให้ถูกต้อง มุมมองเป็นเพียงผู้สังเกตการณ์ของโมเดลและเรียกใช้เมื่อจำเป็น คอนโทรลเลอร์เป็นเพียงกลยุทธ์สำหรับมุมมองในการสื่อสารกับโมเดลตัวอย่างเช่นเมื่อคุณต้องการพฤติกรรมที่แลกเปลี่ยนได้ (เช่น ReadonlyController, AdminController) MVC ประสบความสำเร็จอย่างมากและเป็นแนวปฏิบัติที่ดีที่จะนำไปใช้

MVVM เป็นชนิดเฉพาะของรูปแบบ MVP ตามที่อธิบายมาร์ตินฟาวเลอร์ MVP พยายามที่จะทำให้มุมมองเป็นใบ้ที่สุดเท่าที่จะทำได้ (ในขณะที่ยังคงรับข้อมูลจากผู้ใช้ ฯลฯ ) ซึ่งจะช่วยเพิ่มความสามารถในการทดสอบ มันมีจุดมุ่งหมายเพื่อให้เป็นนามธรรมของมุมมองและการมีปฏิสัมพันธ์กับตรรกะที่จะนำเสนอ ผู้นำเสนอสื่อสารกับโมเดล / ตรรกะทางธุรกิจเท่านั้นและอัพเดตมุมมอง Martin Fowler อธิบาย MVVM ค่อนข้างมากในรูปแบบการนำเสนอของเขา

มุมมองจะถูกแยกออกอย่างสมบูรณ์ใน ViewModel เมื่อViewความต้องการของทรัพย์สินViewModelความต้องการที่จะมีเช่นกัน มัน (ViewModel) มีความหมายว่าเป็นอิสระอย่างสมบูรณ์ของเทคโนโลยี UI พื้นฐานซึ่งเป็นนามธรรม ในการสื่อสารระหว่าง View และ ViewModel จำเป็นต้องใช้รูปแบบการซิงโครไนซ์ (เช่น Observer) นี่ไม่ใช่เรื่องง่ายที่จะประสบความสำเร็จในระบบเว็บ MVVM แตกต่างจาก MVP เนื่องจากมุมมองไม่ได้ผูกกับแบบจำลอง / ตรรกะทางธุรกิจของคุณอีกต่อไป แต่ไปยัง ViewModel แทน

รูปแบบใดที่ทันสมัยและฉันควรเลือกรูปแบบใดสำหรับแอพพลิเคชั่นของ Windows & Web?

รูปแบบการนำเสนอ (เหมือน MVVM) ในทางทฤษฎีควรเป็นอิสระอย่างสมบูรณ์จากเทคโนโลยี UI ที่ใช้งานอยู่ อย่างไรก็ตามต้องครอบคลุมด้านการประสานข้อมูล สามารถทำได้อย่างง่ายดายโดยการผูกกับคำสั่งและคุณสมบัติด้วย WPF ที่กาวประสานอยู่แล้ว ด้วย ASP.NET นี่คือเรื่องราวที่แตกต่าง อย่างไรก็ตามมีบทความเกี่ยวกับ CodeProjectซึ่งใช้รูปแบบการนำเสนอที่มีเทคโนโลยี Windows UI ทั้งหมด ได้ดู


4

เนื่องจากปัญหาวงจรชีวิตและความต้องการที่จะรักษาสถานะระหว่างการโพสต์หน้าคุณจะพบว่ามันยากมากที่จะใช้ 100% ของรหัส UI ที่ไม่มีระหว่างเว็บและ WPF Asp.net ไม่มีการเชื่อมโยงข้อมูลที่มีประสิทธิภาพที่จำเป็นสำหรับ MVVM นอกจากนี้ยังมีตรรกะจำนวนมากที่ต้องทำงานใน jscript ทุกวันนี้เนื่องจากผู้คนคาดหวังว่า UI จะอัปเดตตนเองโดยไม่จำเป็นต้องมี postback

หากคุณสามารถใช้ SilverLight ชีวิตของคุณก็จะซับซ้อนน้อยลง :-)

เช่นเดียวกันคุณสามารถโฮสต์เว็บเบราว์เซอร์ในแอพ WPF ของคุณสำหรับบิตทั่วไปของ UI ได้หรือไม่


ฉันจะได้รับประโยชน์อะไรจาก SilverLight
RPK

1
@PRK, Silverlight ส่วนใหญ่จะให้คุณทำทุกอย่างที่ WPF ทำและถ้าคุณสามารถให้ผู้ใช้ "เว็บ" ของคุณติดตั้งได้มันจะช่วยให้คุณสร้างโซลูชันที่เข้าถึง var web และ "รู้สึก" เหมือนเว็บแอป
เอียน

4

ความตั้งใจของคุณที่จะใช้คลาสเดียวกันสำหรับ ASP.Net และ WPF based UI นั้นไม่ได้มีประโยชน์อะไรมาก databinding และการใช้ javascript บนเว็บนั้นแตกต่างจาก WPF มาก ตัวเลือกเดียวที่ฉันสามารถคิดเป็นMVP มีมุมมองที่สมบูรณ์แบบพาสซีฟ ในทางทฤษฎีคุณสามารถมีผู้นำเสนอเดียวกับที่เติมหน้าเว็บและ WPF
ในทางปฏิบัติฉันจะพัฒนาสถาปัตยกรรมที่กฎเกณฑ์ทางธุรกิจส่วนใหญ่อยู่ในเลเยอร์บริการเว็บและชั้นนำเสนอที่แตกต่างกันสองระดับโดยมีกฏทางธุรกิจเล็กน้อยที่สุดเท่าที่จะเป็นไปได้ซึ่งพูดคุยกับเว็บเซอร์วิสนี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.