คำถามติดแท็ก mvvm

Model View-Model ได้รับการพัฒนาโดย Microsoft เพื่อกำหนดเป้าหมายแพลตฟอร์มการพัฒนา UI ซึ่งรองรับการเขียนโปรแกรมที่ขับเคลื่อนด้วยเหตุการณ์โดยเฉพาะ Windows Presentation Foundation (WPF) และ Silverlight บนแพลตฟอร์ม. NET โดยใช้ภาษา XAML และ. NET ในหลายปีที่ผ่านมาเฟรมเวิร์ก Javascript จำนวนมากเช่น Angular, Knockout และ ExtJS ได้นำรูปแบบนี้มาใช้ เช่นเดียวกับรูปแบบซอฟต์แวร์ส่วนใหญ่ MVVM มีการใช้งานที่เหมาะสมและใช้ในทางที่ผิด การใช้ MVVM มีเงื่อนไขใดบ้าง เมื่อไรที่ไม่ควรทำ

47 wpf  mvvm  silverlight  angularjs  xaml 

ตัวอย่าง # 1: ฉันมีมุมมองที่แสดงในแอปพลิเคชัน MVVM ของฉัน (ลองใช้ Silverlight เพื่อจุดประสงค์ในการอภิปราย) และฉันคลิกที่ปุ่มที่ควรพาฉันไปที่หน้าใหม่ ตัวอย่าง # 2: มุมมองเดียวกันนั้นมีปุ่มอื่นที่เมื่อคลิกแล้วควรเปิดมุมมองรายละเอียดในหน้าต่างลูก (กล่องโต้ตอบ) เรารู้ว่าจะมีวัตถุคำสั่งที่เปิดเผยโดย ViewModel ของเราที่เชื่อมโยงกับปุ่มด้วยวิธีการที่ตอบสนองต่อการคลิกของผู้ใช้ แต่ถ้าเช่นนั้นจะเป็นอย่างไร เราจะดำเนินการให้เสร็จสมบูรณ์ได้อย่างไร? แม้ว่าเราใช้ NavigationService ที่เรียกว่าอะไรเราจะบอกอะไร เพื่อให้เฉพาะเจาะจงมากขึ้นในโมเดล View-first แบบดั้งเดิม (เช่นโครงร่างการนำทางตาม URL เช่นบนเว็บหรือเฟรมเวิร์กการนำทางในตัว SL) วัตถุคำสั่งจะต้องรู้ว่ามุมมองใดที่จะแสดงถัดไป ที่ดูเหมือนว่าจะข้ามเส้นเมื่อมันมาถึงการแยกความกังวลที่ส่งเสริมโดยรูปแบบ ในทางกลับกันถ้าปุ่มไม่ได้เชื่อมต่อกับวัตถุคำสั่งและทำตัวเหมือนไฮเปอร์ลิงก์กฎการนาวิเกตอาจถูกกำหนดในมาร์กอัป แต่เราต้องการให้ Views ควบคุมการไหลของแอปพลิเคชันและไม่ใช่การนำทางเป็นเพียงตรรกะทางธุรกิจประเภทอื่นหรือไม่ (ฉันสามารถพูดได้ว่าใช่ในบางกรณีและไม่ใช่ในคนอื่น ๆ ) สำหรับฉันการใช้ยูโทเปียของรูปแบบ MVVM (และฉันเคยได้ยินคนอื่นยอมรับสิ่งนี้) จะต้องมี ViewModel แบบมีสายในลักษณะที่แอปพลิเคชันสามารถเรียกใช้หัว (เช่นไม่มีมุมมอง) นี่เป็นพื้นที่ผิวสำหรับการทดสอบที่ใช้รหัสมากที่สุดและทำให้ Views เป็นสกินที่แท้จริงในแอปพลิเคชัน และ …

33 design-patterns  silverlight  mvvm 

ฉันเคยเริ่มโครงการ MVVM / WPF ซึ่งสร้างและปรับใช้ในที่สุดและเพื่อที่ฉันศึกษา Caliburn.Micro MVVM Framework จำนวนมาก ความจริงก็คือ: ฉันลงเอยด้วยการไม่ใช้ Caliburn.Micro สำหรับสิ่งนั้นและลงเอยด้วยการนำแนวคิด MVVM มาใช้ด้วยตัวเอง (โดยเฉพาะแค่ViewModelBaseและRoutedCommandคลาส) ตอนนี้ฉันได้รับมอบหมายให้ทำโครงการขนาดใหญ่กว่าในบรรทัดเดียวกัน: "แอปพลิเคชันเดสก์ท็อปออฟไลน์ไคลเอนต์สำหรับผู้ใช้ที่มีผู้ใช้หลายคน" ดังนั้นจะพูดและฉันตัดสินใจใช้ Caliburn.Micro และนั่นคือสิ่งที่ "ปัญหา" ของฉันเริ่มต้นขึ้น ฉันได้อ่านในโพสต์บล็อกที่มีชื่อเสียงชื่อเรื่องว่า "ถ้าคุณใช้ MVVM คุณต้องมีกรอบ" นั่น: "พยายามที่จะทำสิ่งที่ต้องการโดยไม่ต้อง MVVM กรอบเป็นจำนวนมากของการทำงาน. ตันของรหัสที่ซ้ำกัน reinventing ล้อและฝึกอบรมคนที่จะคิดแตกต่างกัน อย่างน้อยด้วยเฟรมเวิร์กที่คุณหลีกเลี่ยงรหัสที่ซ้ำกันและหวังว่าจะไม่ต้องบูรณาการล้อ - ช่วยให้คุณสามารถมุ่งเน้นไปที่การฝึกอบรมผู้คน ส่วนการอบรมขึ้นใหม่นั้นไม่สามารถหลีกเลี่ยงได้โดยทั่วไป แต่เฟรมเวิร์กจัดเตรียมรหัสการประปาและโครงสร้างทำให้กระบวนการง่ายขึ้น " ฉันจะเห็นด้วยกับการอ่านครั้งแรก แต่ประสบการณ์จริงของฉันกับ Caliburn.Micro (CM) ในแอปพลิเคชันจริงของฉันคือการ cluelessness และ disorientation นั่นคือกรอบงานไม่ได้ทำให้กระบวนการง่ายขึ้นเลยตรงกันข้าม อ่านตัวอย่างที่เคยทำซ้ำให้โดยร็อบไอเซนเบิร์กในเอกสารค่อนข้าง …

28 frameworks  wpf  mvvm 

ฉันเริ่มต้นโครงการด้วยสภาพแวดล้อมทางเทคนิคต่อไปนี้:. Net 4.0, Entity Framework 4.0, WPF พร้อมสถาปัตยกรรม MVVM ฉันเห็นตัวอย่างมากมายในเน็ตหนังสือบางเล่มเกี่ยวกับสภาพแวดล้อมนี้ ในตัวอย่างที่ผู้เขียนมีความคิดนี้: Viemodel จะมีตัวอย่างของคลาส Model (Entity Framework Entity เช่น Person) ผูกคอนโทรล WPF view เข้ากับคุณสมบัติของ Model ในขณะที่ผู้เขียนบางคนทำ: Viemodel จะเปิดเผยคุณสมบัติทั้งหมดของโมเดล เชื่อมโยงคอนโทรลมุมมอง WPF กับคุณสมบัติของ ViewModel แทนที่จะเชื่อมโยงกับโมเดลโดยตรง ดังนั้นเป็นความคิดที่ดีหรือไม่ที่จะให้มุมมองเชื่อมโยงคุณสมบัติจากแบบจำลองแทนที่จะเป็นมุมมองที่เปิดเผยตัวตน หรือจะเลือกอันไหนดีกว่ากัน?

21 .net  entity-framework  mvvm 

ฉันเริ่มเรียนรู้เกี่ยวกับ Redux และ React ในเว็บโลกและยิ่งฉันเรียนรู้มากเท่าไหร่ฉันก็ยิ่งรู้ว่าการจัดการสถานะเจ็บปวดในเดสก์ท็อปโลกด้วยสถาปัตยกรรมสไตล์ MVVM ของ WPF (โดยใช้ Caliburn โดยเฉพาะเพื่อผูกมัด Views ไปยัง ViewModels) Redux มีหลักการง่ายๆสองสามข้อที่บอกให้ทราบว่ารัฐควรจัดการอย่างไรการปรับปรุง UI การจัดการเหตุการณ์และการเปลี่ยนแปลงสถานะสามารถคาดการณ์ได้มากขึ้น หลักการคือ: แหล่งความจริงเดียว (สถานะที่ไม่แน่นอนทั้งหมดจะถูกเก็บไว้ในวัตถุที่ใช้ร่วมกันเดียว) สถานะเป็นแบบอ่านอย่างเดียว มันไม่สามารถแก้ไขได้โดยส่วนประกอบผ่านรหัสซึ่งมักจะเกิดขึ้นใน WPF สถานะสามารถแก้ไขได้โดยฟังก์ชันบริสุทธิ์เท่านั้น สถาปัตยกรรม MVVM ของ WPF ช่วยให้คุณสามารถสร้างมุมมองแบบโต้ตอบได้อย่างรวดเร็ว แต่การดีบักปัญหาเมื่อ viewmodels และเหตุการณ์ต่าง ๆ เปลี่ยนสถานะทั้งหมดเป็นฝันร้าย ตัวอย่างเช่นเหตุการณ์ที่ทำให้เกิดการเปลี่ยนแปลงมุมมองและพยายามตั้งค่าแท็บเริ่มต้น แต่ข้อมูลยังไม่เสร็จสิ้นการโหลดแบบอะซิงโครนัสจากเว็บเซอร์วิสดังนั้นแท็บจึงไม่มีอยู่ (ยัง) จึงไม่มีอะไรเกิดขึ้น ฉันใช้เวลาหลายชั่วโมงในการวาดไดอะแกรมเพื่อลองและทำความเข้าใจกับการโต้ตอบที่ซับซ้อนระหว่างองค์ประกอบ viewModels ที่เกี่ยวกับอินเตอร์ที่อัปเดตกัน ฉันเข้าใจว่า Redux ตั้งเป้าหมายที่จะแก้ปัญหาความไม่แน่นอนในเรื่องนี้ มีบางอย่างที่คล้ายกันหรือรูปแบบสถาปัตยกรรมที่เหมาะกับ WPF เพื่อช่วยจัดการสถานะให้ดีขึ้นหรือไม่? ฉันไม่แน่ใจว่าหลักการ Redux …

21 wpf  mvvm  state  redux 

ฉันกำลังทำงานกับแอปพลิเคชัน WPF ที่มีมุมมองที่ต้องการการแปลงค่าจำนวนมาก ในตอนแรกปรัชญาของฉัน (ได้รับแรงบันดาลใจจากการอภิปรายที่มีชีวิตชีวาใน XAML Disciples ) คือฉันควรสร้างแบบจำลองมุมมองอย่างเคร่งครัดเกี่ยวกับการสนับสนุนข้อกำหนดด้านข้อมูลของมุมมอง ซึ่งหมายความว่าการแปลงค่าใด ๆ ที่จำเป็นในการแปลงข้อมูลเป็นสิ่งที่มองเห็นได้แปรงขนาด ฯลฯ จะได้รับการจัดการกับตัวแปลงค่าและตัวแปลงค่าหลายค่า แนวคิดนี้ดูเหมือนจะค่อนข้างหรูหรา รูปแบบการดูและมุมมองทั้งสองจะมีจุดประสงค์ที่แตกต่างกันและแยกกันอย่างชัดเจน เส้นที่ชัดเจนจะถูกวาดระหว่าง "data" และ "look" หลังจากให้กลยุทธ์นี้ "ลองวิทยาลัยเก่า" ฉันมีข้อสงสัยว่าฉันต้องการพัฒนาวิธีนี้ต่อไปหรือไม่ ฉันกำลังพิจารณาการทิ้งตัวแปลงค่าและวางความรับผิดชอบสำหรับ (เกือบ) การแปลงค่าทั้งหมดให้อยู่ในมือของรูปแบบการดูอย่างจริงจัง ความเป็นจริงของการใช้ตัวแปลงมูลค่านั้นดูเหมือนจะไม่สามารถวัดได้ถึงมูลค่าที่ชัดเจนของข้อกังวลที่แยกออกจากกันอย่างหมดจด ปัญหาที่ใหญ่ที่สุดของฉันเกี่ยวกับตัวแปลงมูลค่าคือพวกเขาน่าเบื่อที่จะใช้ คุณต้องสร้างคลาสใหม่ใช้งานIValueConverterหรือIMultiValueConverterโยนค่าหรือค่าจากobjectประเภทที่ถูกต้องทดสอบสำหรับDependencyProperty.Unset(อย่างน้อยสำหรับตัวแปลงหลายค่า) เขียนตรรกะการแปลงลงทะเบียนตัวแปลงในพจนานุกรมทรัพยากร [ดูการปรับปรุงด้านล่าง ] และสุดท้ายเชื่อมต่อตัวแปลงโดยใช้ XAML ค่อนข้างละเอียด (ซึ่งจำเป็นต้องใช้สายอักขระเวทสำหรับทั้งการผูกและชื่อของตัวแปลง[ดูอัปเดตด้านล่าง]) กระบวนการตรวจแก้จุดบกพร่องนั้นไม่มีการปิคนิคเนื่องจากข้อความแสดงข้อผิดพลาดมักจะเป็นความลับโดยเฉพาะในโหมดการออกแบบ / Expression Blend ของ Visual Studio นี่ไม่ได้หมายความว่าทางเลือก - การสร้างตัวแบบมุมมองที่รับผิดชอบต่อการแปลงค่าทั้งหมด - เป็นการปรับปรุง นี่อาจเป็นเรื่องของหญ้าที่เป็นสีเขียวในอีกด้านหนึ่ง นอกจากการสูญเสียความกังวลที่แยกจากกันอย่างสง่างามแล้วคุณต้องเขียนคุณสมบัติที่ได้รับจำนวนมากและทำให้แน่ใจว่าคุณโทรไปอย่างจริงใจRaisePropertyChanged(() …

20 silverlight  wpf  mvvm  xaml 

ฉันต้องการความช่วยเหลือในการสร้างมุมมองแบบจำลองสำหรับสถานการณ์ต่อไปนี้: ข้อมูลที่ลึกและเป็นลำดับชั้น หลายมุมมองสำหรับชุดข้อมูลเดียวกัน แต่ละมุมมองเป็นมุมมองเดียวที่เปลี่ยนแปลงได้แบบไดนามิกตามการเลือกที่แอ็คทีฟ แสดงแท็บประเภทต่าง ๆ ในตัวควบคุมแท็บทั้งนี้ขึ้นอยู่กับมูลค่าของคุณสมบัติ คำถามของฉัน: ฉันควรสร้างการนำเสนอแบบจำลองมุมมองสำหรับแต่ละมุมมอง (VM1, VM2 ฯลฯ ) หรือไม่ 1. Yes: a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1) b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes) 2. No: a. Do I use a huge, single view …

18 wpf  mvvm 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ขณะนี้ฉันกำลังพยายามหา MVVM สำหรับ WPF - ไม่ได้หมายความว่าเอาหัวของฉันไปคิด แต่รอบ ๆ ถั่วและกลอนที่เกิดขึ้นจริงในการทำสิ่งใดก็ตาม สิ่งที่ฉันสังเกตเห็นคือกรอบมากมายและส่วนใหญ่ / โพสต์บล็อกทั้งหมดมาจาก 'วัย' ที่ผ่านมา นี่เป็นเพราะตอนนี้มันเป็นหมวกที่เก่าและนักเขียนบล็อกได้ย้ายไปสู่สิ่งที่ยิ่งใหญ่ต่อไปหรือเพียงเพราะพวกเขาได้พูดทุกอย่างที่จะพูด? ในคำอื่น ๆ มีบางสิ่งที่ฉันหายไปที่นี่?

18 wpf  mvvm 

ฉันขอโทษสำหรับคำถามยาว ๆ มันอ่านได้เล็กน้อยว่าเป็นคำโหยหวน แต่ฉันสัญญาว่ามันจะไม่! ฉันได้สรุปคำถามของฉันด้านล่าง ในโลกของ MVC สิ่งต่าง ๆ ตรงไปตรงมา รูปแบบมีสถานะมุมมองแสดงรูปแบบและตัวควบคุมทำสิ่งต่าง ๆ เพื่อ / กับรุ่น (โดยทั่วไป) ตัวควบคุมไม่มีสถานะ ในการทำสิ่งต่าง ๆ ที่คอนโทรลเลอร์มีการขึ้นต่อกันของบริการบนเว็บ, ที่เก็บ, ล็อต เมื่อคุณยกตัวอย่างคอนโทรลเลอร์ที่คุณสนใจเกี่ยวกับการจัดหาการพึ่งพาเหล่านั้นไม่มีอะไรอื่น เมื่อคุณเรียกใช้การกระทำ (เมธอดบนตัวควบคุม) คุณใช้การอ้างอิงเหล่านั้นเพื่อดึงหรืออัปเดตโมเดลหรือเรียกบริการโดเมนอื่น ๆ หากมีบริบทใด ๆ ให้พูดเช่นผู้ใช้บางคนต้องการดูรายละเอียดของรายการใดรายการหนึ่งคุณจะส่ง Id ของรายการนั้นเป็นพารามิเตอร์ไปยัง Action ไม่มีที่ใดในคอนโทรลเลอร์มีการอ้างอิงถึงสถานะใด ๆ จนถึงตอนนี้ดีมาก ป้อน MVVM ฉันรัก WPF ฉันรักการผูกข้อมูล ฉันรักเฟรมเวิร์กที่ทำให้การผูกข้อมูลกับ ViewModels ง่ายยิ่งขึ้น (โดยใช้ Caliburn Micro atm) ฉันรู้สึกว่าสิ่งต่าง ๆ …

17 c#  design  wpf  mvvm 

ฉันกำลังพยายามตั้งค่าโครงสร้างแอปพลิเคชันของฉันใน VS และฉันต้องการ "ลอง" และพิสูจน์ในอนาคตให้อยู่ในระดับที่เหมาะสม แอปพลิเคชั่นนี้จะเป็น WPF เขียนใหม่ของแอป Winform เก่าที่ไม่ได้ทำตามอนุสัญญา ไม่มีเลเยอร์เทียร์คำย่อ ฯลฯ ... มันเป็นแอพพลิเคชั่นสำหรับองค์กรขนาดใหญ่พอสมควร ฉันวางแผนที่จะใช้ Linq To SQL เป็นฐานข้อมูลของฉันและมักจะเป็น MS SQL นอกจากนี้ฉันมีชุดทักษะที่มีอยู่กับมัน ฉันต้องการติดตาม MVVM และ DDD ที่ดีที่สุดที่ฉันสามารถทำได้ แต่ฉันสับสนในโครงสร้างของแอปพลิเคชันของฉันเมื่อรวมสิ่งเหล่านี้ ให้ฉันลองและอธิบายด้วยตัวอย่างบางส่วน เมื่อฉันติดตาม MVVM โครงสร้างโฟลเดอร์ของฉันอาจมีลักษณะเช่นนี้: Views Models ViewModels Helpers แต่วิธีที่เหมาะกับ DDD แบบเลเยอร์เรียบง่ายที่โครงสร้างโครงการของฉันอาจมีลักษณะเช่นนี้: MyApp.UI MyApp.Domain MyApp.Data ฉันจะใส่Modelsใน Domain layer หรือฉันมี 3 รุ่นว่าPerson? สิ่งนี้นำไปสู่คำถามอื่นที่ฉันจะวางที่เก็บและการแมปของวัตถุ DB …

17 .net  wpf  mvvm  domain-driven-design  project-structure 

เรากำลังจะเขียนแอปพลิเคชั่น WPF แรกของเราและเริ่มคุ้นเคยกับรูปแบบ MVVM เราได้สร้างแอปพลิเคชั่น Winform จำนวนมากและมีสถาปัตยกรรมที่ประสบความสำเร็จมากสำหรับเรา เรามีปัญหาเล็กน้อยในการแปลสถาปัตยกรรมนั้นหรือกำหนดว่าสถาปัตยกรรมบางอย่างของเราเหมาะสมกับรูปแบบ MVVM หรือไม่ ในอดีตเรามี Gui (exe หลัก) ที่สื่อสารกับ dll BusinessLogic BusinessLogic สื่อสารกับ DAL dll ผ่านเว็บเซอร์วิสและ DAL โต้ตอบกับ DB DAL, BusinessLogic และ GUI ล้วนอ้างถึง BusinessObjects dll เดียวกัน การเปลี่ยนแปลงไปสู่ ​​MVVM นั้นค่อนข้างตรงไปตรงมา Gui ของเราจะยังคงมีมุมมอง BusinessOjbects ของเราจะยังคงมีรูปแบบและ DAL ของเราจะยังคงมีปฏิสัมพันธ์กับฐานข้อมูล (แม้ว่าเทคโนโลยีในการใช้พวกเขาอาจเปลี่ยนแปลง) สิ่งที่เราไม่แน่ใจคือองค์ประกอบ BusinessLogic ของเรา ในอดีตนี้จะให้ฟังก์ชั่นสำหรับ GUI เพื่อเรียกไปแล้วเติมการควบคุมในมุมมอง (เช่น. …

15 architecture  mvvm 

ฉันได้อ่านเกี่ยวกับ Model View Controller, Model View Presenter, Model View ViewModel เป็นต้นโดยทั่วไปแนวคิดพื้นฐานดูเหมือนจะเข้าใจง่าย: เก็บภาพที่สวยงามและความกล้าหาญทางวิทยาศาสตร์แยกจากกันและงมงายเป็น เป็นไปได้ ไม่ได้รับเนยถั่วลิสงในการออกแบบช็อคโกแลต; ฉันชอบมัน ปัญหาคือฉันยังคงคลุมเครือเล็กน้อยในส่วนที่สามนั่นคือ ... ไม่ใช่โมเดลหรือมุมมอง ทุกคนดูเหมือนจะมีความคิดของตัวเองว่าจะเรียกมันว่าอะไรควรทำอะไรเหมาะสมอะไรผิดปกติธรรมดา ... และฉันจะพยายามคิดออกเมื่อผู้นำเสนอกลายเป็น ViewModel และเมื่อมุมมองไม่ควร ' อย่าทำอย่างนั้นเพราะนั่นคืองานของผู้นำเสนอและ - ฉันเที่ยว แทนที่จะขอให้ใครบางคนอธิบายความแตกต่างระหว่างพวกเขา - เพราะมันทำมาแล้วครั้งแล้วครั้งเล่า (ฉันรู้ว่าฉันอ่านบทความมากกว่าที่ฉันสามารถนับได้) - ฉันอยากรู้อยากเห็นความคิดของ โปรแกรมเมอร์เพียงไม่กี่คนในแบบจำลองที่ฉันได้เดินด้วยกัน ที่กล่าวว่าสิ่งที่คุณจะจัดประเภทการออกแบบนี้และที่สำคัญกว่าคุณเห็นอะไรเกี่ยวกับเรื่องนี้ที่ชัดดูด? แน่นอนว่าฉันชอบที่จะได้ยินว่าฉันทำได้ดีถ้านี่คือการออกแบบที่มั่นคงอย่างแท้จริง แต่ฉันอยากได้รับคำแนะนำที่หนักแน่นมากกว่าการชม หมายเหตุ: ฉันจะใช้ "the Bridge" สำหรับส่วนที่สามอันลึกลับของ Model-View-? เพื่อหลีกเลี่ยงคำแนะนำจิตใต้สำนึกของสิ่งที่ "ควร" เป็น แบบ เป็นสิทธิของข้อมูล รับข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่ร้องขอจาก Bridge …

14 design-patterns  mvc  mvvm  mvp 

ฉันกำลังสร้างแอปพลิเคชัน WPF โดยใช้รูปแบบ MVVM ในตอนนี้ viewmodels ของฉันเรียกเลเยอร์บริการเพื่อเรียกคืนโมเดล (ความเกี่ยวข้องกับ viewmodel) และแปลงเป็น viewmodels ฉันใช้ตัวสร้างการฉีดเพื่อส่งผ่านบริการที่จำเป็นสำหรับโมเดลวิวเวอร์ มันทดสอบได้ง่ายและทำงานได้ดีสำหรับ viewmodels ที่มีการพึ่งพาน้อย แต่ทันทีที่ฉันพยายามสร้าง viewModels สำหรับรุ่นที่ซับซ้อนฉันมี Constructor ที่มีบริการมากมายแทรกอยู่ (หนึ่งเพื่อดึงการอ้างอิงแต่ละรายการและรายการค่าที่มีทั้งหมด เพื่อผูกกับ itemsSource เป็นต้น) ฉันสงสัยว่าจะจัดการกับบริการหลายอย่างเช่นนั้นได้อย่างไรและยังมีวิวเวอร์โมเดลที่ฉันสามารถทดสอบหน่วยได้อย่างง่ายดาย ฉันกำลังคิดถึงวิธีแก้ปัญหาบางอย่าง: การสร้างบริการแบบซิงเกิล (IServices) ที่มีบริการทั้งหมดที่มีอยู่เป็นส่วนต่อประสาน ตัวอย่าง: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve () ด้วยวิธีนี้ฉันไม่มีคอนสตรัคเตอร์ขนาดใหญ่ที่มีพารามิเตอร์บริการจำนวนมากในตัวพวกเขา การสร้างส่วนหน้าสำหรับบริการที่ใช้โดย viewModel และส่งผ่านออบเจ็กต์นี้ใน ctor ของ viewmodel ของฉัน แต่แล้วฉันจะต้องสร้างซุ้มสำหรับแต่ละมุมมองเชิงซ้อนของฉันและมันอาจจะค่อนข้างมาก ... คุณคิดว่าเป็นวิธีที่ "ถูกต้อง" ในการใช้งานสถาปัตยกรรมประเภทนี้?

14 architecture  dependency-injection  mvvm 

ในหนังสือของเขาที่ชื่อว่า 'Clean Architecture' ลุงบ๊อบบอกว่าผู้นำเสนอควรใส่ข้อมูลที่ได้รับมาในสิ่งที่เขาเรียกว่า 'ดูแบบจำลอง' นี่เป็นสิ่งเดียวกันกับ 'ViewModel' จากรูปแบบการออกแบบ Model-View-ViewModel (MVVM) หรือเป็น Data Transfer Object (DTO) แบบง่ายหรือไม่? ถ้าไม่ใช่ DTO แบบง่ายมันเกี่ยวข้องกับมุมมองอย่างไร มุมมองได้รับการปรับปรุงจากความสัมพันธ์ผ่านผู้สังเกตการณ์หรือไม่ ฉันเดาว่ามันเป็นเหมือน ViewModel จาก MVVM เพราะในบทที่ 23 ของหนังสือของเขา Robert Martin กล่าวว่า: [งานของผู้นำเสนอ] คือการยอมรับข้อมูลจากแอปพลิเคชันและจัดรูปแบบสำหรับงานนำเสนอเพื่อให้มุมมองสามารถย้ายไปที่หน้าจอได้ ตัวอย่างเช่นหากแอปพลิเคชันต้องการวันที่แสดงในเขตข้อมูลมันจะมอบวัตถุวันที่นำเสนอ ผู้นำเสนอจะจัดรูปแบบข้อมูลนั้นลงในสตริงที่เหมาะสมและวางไว้ในโครงสร้างข้อมูลอย่างง่ายที่เรียกว่ารุ่นมุมมองซึ่งมุมมองสามารถค้นหาได้ นี่ก็หมายความว่ามุมมองนั้นเชื่อมต่อกับ ViewModel แทนการรับฟังก์ชั่นอาร์กิวเมนต์เป็นตัวอย่าง อีกเหตุผลหนึ่งที่ฉันคิดว่านี่เป็นเพราะถ้าคุณดูที่ภาพผู้นำเสนอใช้โมเดลมุมมอง แต่ไม่ใช่มุมมอง ในขณะที่ผู้นำเสนอใช้ทั้งขอบเขตการส่งออกและข้อมูลการส่งออก DTO หากไม่ใช่ DTO หรือ ViewModel จาก MVVM โปรดอธิบายอย่างละเอียดว่ามันคืออะไร

13 architecture  mvvm  dto  plugin-architecture  view 

ในแอปพลิเคชัน WPF ของฉันฉันต้องการสร้างมุมมองใหม่ ฉันควรทำเช่นนั้น - ในViewModel or Model ? แอปพลิเคชั่นนี้เป็นเครื่องมือที่มีลักษณะคล้ายหน้าต่างเดียว (ง่ายมากสำหรับตอนนี้ด้วยปุ่ม "ส่ง" เดียว ในกรณีที่เลือกช่องทำเครื่องหมายหนึ่งหน้าต่างใหม่ที่ใช้ ViewModel เดียวกันควรปรากฏขึ้นเพื่อขอรายละเอียดเพิ่มเติมจากผู้ใช้ สำหรับจุดประสงค์ของคำถามนี้ลองพิจารณาเพียงวิธีเข้าหน้าต่างใหม่โดยไม่พิจารณาวิธีอื่นเช่นแสดง / ซ่อนแผง ในอุดมคติแล้วในมุมมองไม่ควรมีรหัสใด ๆ นอกจากนี้เนื่องจาก View ไม่ได้มีตรรกะใด ๆ ในนั้น VM จะต้องตรวจสอบก่อนว่าการสร้างมุมมองใหม่นั้นจำเป็นหรือไม่ - และเมื่อมีการสะท้อนความรับผิดชอบนี้กลับไปที่ View ซึ่งนำไปสู่การขยายโค้ด ในทางกลับกันการสร้างมุมมองใหม่ใน ViewModel ละเมิดหลักการที่ ViewModel ไม่ควรรู้เกี่ยวกับมุมมอง ดังนั้นจะเป็นการดีกว่าหรือที่จะสร้างมุมมองใหม่ใน View หรือ ViewModel?

11 c#  design  wpf  mvvm