ค่าของ MVVM ในแอปพลิเคชันทางธุรกิจ (และการใช้แนวทางปฏิบัติในการพัฒนาปัจจุบัน)


9

หลังจาก 2 ปีฉันยังคงดิ้นรนกับ MVVM เป็นวิธีปฏิบัติในการผลิตซอฟต์แวร์ที่ใช้งานได้ ในบางกรณีมันยอดเยี่ยมมาก ฉันทำแอพพลิเคชั่นแบบมัลติเธรดที่ควบคุมแอสเซมบลีไลน์เล็ก ๆ ซึ่งน่าจะเป็น nightmere โดยปราศจากแนวคิด MVVM สิ่งที่เป็นนามธรรมจากสายการประกอบกายภาพเกือบจะเป็นเกมง่ายๆ

อย่างไรก็ตามอาชีพของฉันส่วนใหญ่หมุนรอบแอปพลิเคชันทางธุรกิจภายใน - การทำให้เป็นทางการและการเพิ่มประสิทธิภาพการดำเนินงานของธุรกิจ ในแอพดังกล่าวโดยทั่วไปมักจะมีนักธุรกิจที่ทำงานเกี่ยวกับ CRUD และการดำเนินงานแบบผสม ใน LOBs โมเดลการดูของฉันจะเป็นคอลเล็กชั่นที่เรียบง่ายของฟังก์ชั่นห่อหุ้มบรรทัดเดียวของวิธีการเรียนธุรกิจและท้ายที่สุดก็จบลงด้วยการทำให้งานง่ายที่สุดเช่นแสดงกล่องข้อความหรือเปิดหน้าต่าง ไม่มีใครอื่นพบว่ามันแปลกหรือเปล่าเมื่อผู้คนเข้าสู่ "การฉีดของผู้พึ่งพา" และ "ผู้ให้บริการการส่งข้อความ" เป็นเวลานานสำหรับการแสดงหน้าต่าง มีคำถามอื่นอีกกี่คำถามในกองล้นที่ขอคำแนะนำสำหรับงานที่ง่ายมากใน winforms

อย่าเข้าใจฉันผิด - ฉันได้รับ MVVM และวิธีที่จะมีค่ามากสำหรับทีมขนาดใหญ่ที่พัฒนาแพคเกจซอฟต์แวร์แบบห่อหุ้มและวางตลาดในแนวนอน การทดสอบหน่วยการดูรุ่นสามารถบันทึกล้านโดยหลีกเลี่ยงข้อผิดพลาด RTM ที่ไม่ดีและนักพัฒนา UI เฉพาะสามารถให้ประสบการณ์มากมาย แต่เมื่อค่าใช้จ่ายในการปรับใช้ใหม่มีน้อยและธุรกิจทั้งหมดใส่ใจที่จะจ่ายเป็นซอฟต์แวร์ที่ใช้งานง่ายทำไมฉันจึงควรใช้หน่วยเวลาในการทดสอบ "wrapper" vm แบบง่าย ๆ เมื่อตรรกะทางธุรกิจของฉันถูกทดสอบแล้ว? เวลาเท่าไหร่ในธุรกิจที่จะทำให้ฉันได้ใช้เวลากับอนิเมชั่นน่ารักและโครงร่างสี? มีอะไรเหลือสำหรับผู้พัฒนารุ่นน้องที่ต้องทำ (ติดตามข้อบกพร่องในฟังก์ชันการบันทึกที่เคยดูที่ "Save_Click"

เป็นที่ยอมรับฉันชอบ databinding ของ WPF เพื่อใช้ประโยชน์จากมันฉันตั้งบริบทข้อมูลไปที่หน้าต่างตัวเองซึ่งมีการเข้าถึงชั้นธุรกิจเช่นเดียวกับคุณสมบัติที่สังเกตได้อื่น ๆ ใช่ฉันทำลาย "กฎ" ของ MVVM เกือบทุกครั้งด้วยการทำเช่นนั้น แต่อย่างน้อยฉันก็มีรหัสเหตุการณ์ที่ใช้งานง่ายซึ่งอ่านได้ง่ายและฉันก็จะได้รับประโยชน์จากการบันทึกและตรวจสอบความถูกต้องใหม่ ปัญหาเกิดขึ้นกับนักออกแบบ - ซึ่งฉันไม่ได้ใช้ทั้งหมด แต่หวังว่าจะได้รับการบูรณาการที่ดีขึ้นในปี 2012 - นักออกแบบแสดงคุณสมบัติหลายร้อยแห่งที่หน้าต่างและคลาสพื้นฐานมี

สำหรับผู้ที่สามารถเชื่อมโยงคุณสามารถชี้ให้ฉันเห็นถึงแหล่งข้อมูลหนังสือหรือแม้กระทั่งการเปลี่ยนแปลงในมุมมองที่ทำให้กลืนได้ง่ายขึ้น ฉันจะให้ MVVM อีกครั้ง แต่ครั้งสุดท้ายที่ฉันรู้สึกโง่ที่ต้องกังวลเกี่ยวกับการฉีดพึ่งพาเพื่อแสดงกล่องข้อความจาก VM ฉันไม่มีความตั้งใจในการทดสอบหน่วย แม้ว่าฉันจะทำการทดสอบหน่วยเราจะได้รับคุณภาพที่มากขึ้นจากการทดสอบการซื้อขายตามเวลาสำหรับข้อผิดพลาดในการรวบรวมเวลาของแอพพลิเคชั่น

ฉันรู้ว่าคำตอบเดียวคืออยู่ใน winforms แต่ในฐานะหนึ่งในผู้สนับสนุนคนสุดท้ายของ WebForms (ฉันมีคำวิจารณ์เกี่ยวกับแนวโน้มของการพัฒนาเว็บไซต์ที่เหมือนกัน) ฉันรู้สึกเหมือนไดโนเสาร์เล็กน้อยเหมือนตอนที่ฉันสืบเชื้อสายมาไม่มี WebForms เหลืออยู่ในแทร็คการรับรองของ Microsoft การก้าวไปข้างหน้าเป็นเพียงตัวเลือกเดียวแม้ว่าฉันจะไม่ชอบก็ตาม


1
แม้ว่าฉันจะไม่สนับสนุนก็ตาม แต่ก็ยังคงเป็นไปได้ที่จะเขียนแอปพลิเคชัน WPF WinForms-style พร้อมกับเหตุการณ์และโค้ดไว้เบื้องหลัง สำหรับแอปที่ใช้ง่ายเพียงครั้งเดียวไม่ใช่เรื่องใหญ่ มันมากับสิ่งที่คุณให้คุณค่าและสิ่งที่ให้คุณค่ากับธุรกิจ ฉันเป็นแฟนตัวยงของ TDD และ MVVM แต่ถ้ามันไม่ให้คุณค่าจริง ๆ อย่าทำอย่างนั้น มันไม่ใช่ศาสนา เพียงจำไว้ว่ารหัสมักจะใช้เวลานานกว่าที่เราคิด
Matt H

"ไม่มีใครอื่นพบว่ามันแปลกเมื่อคนเข้าไปใน discriptions ยาวของ 'การฉีดพึ่งพา' และ 'ผู้ให้บริการการส่งข้อความ' สำหรับหน้าต่างแสดงการโทร Dialog ที่ได้รับรอบมานานหลายทศวรรษ?" ฉันพบว่ามันน่ารำคาญ แต่การเรียงลำดับของบุคคลที่เข้ามาเกี่ยวข้องทั้งหมด (ความเสียหายที่เกิดขึ้นกับการทำสิ่งใด ๆ ) เป็นส่วนหนึ่งของสาขาเสมอและน่าเสียดายที่อาจเป็นเช่นนั้นเสมอ กลยุทธ์ที่ดีที่สุดคือการเพิกเฉย / เสียสมาธิมากที่สุด
user1172763

คำตอบ:


10

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

เว็บฟอร์มนั้นเหมือนกันยกเว้นมันจะทำให้เกิดความยุ่งยากเพิ่มเติมเกี่ยวกับการเป็นนามธรรมที่ไร้รัฐผ่านระบบไร้รัฐ (เว็บ) ตามที่ Rob Conery กล่าวไว้:

WebForms เป็นเรื่องโกหก มันเป็นนามธรรมที่ถูกห่อหุ้มด้วยการหลอกลวงที่ปกคลุมไปด้วยซอสโกหกที่นำเสนอบนจานที่เต็มไปด้วยความเพลิดเพลินและมืออันว่องไว ไม่มีอะไรที่คุณทำกับเว็บฟอร์มที่เกี่ยวข้องกับเว็บคุณปล่อยให้มันทำงานให้คุณได้

สิ่งนี้จากคนที่เขียน mapper เชิงสัมพันธ์เชิงวัตถุที่ทำงานได้อย่างสมบูรณ์โดยใช้dynamicคีย์เวิร์ดใน C # และมีโค้ดเพียงสี่ร้อยบรรทัด เมื่อเขาพูดอย่างมีอำนาจเกี่ยวกับบางสิ่งบางอย่างฉันฟัง

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

ฉันมีวิธีการคงที่ที่ฉันสามารถส่งแบบฟอร์มและคอลเลกชันของคู่ของคีย์ / ค่าและมันจะ (ใช้การสะท้อน) จับคู่คีย์กับฟิลด์ในแบบฟอร์มโดยอัตโนมัติและเติมแบบฟอร์มด้วยค่าของคอลเลกชัน ฉันยังสามารถย้อนกลับได้รับการรวบรวมคู่ Key / Value จากเขตข้อมูลของแบบฟอร์ม ทั้งหมดนั้นคือโค้ดประมาณยี่สิบบรรทัด แต่จ่ายเองทุกครั้งที่ใช้เพราะฉันไม่ต้องเขียนคำสั่งกำหนดเองสี่สิบแบบสำหรับการควบคุมสี่สิบบนแบบฟอร์ม

ฉันสามารถใช้รายการคีย์ / ค่าและเรียงลำดับเป็น XML ช่วยให้ฉันคงอยู่กับไฟล์ ฉันมีรูปแบบอื่น ๆ ที่ฉันสามารถมอบDTOแบบดั้งเดิมและแมปฟิลด์ของมันกับแบบฟอร์ม สิ่งนี้จะไม่เกิดขึ้นจริงในรูปแบบ "ก้อนหินขนาดใหญ่" ของ Winforms มันเกือบจะเป็นเรื่องเล็กน้อยเมื่อมีการใช้การแยกตัวที่เพียงพอ

เสียงนี้คุ้นเคยหรือไม่? มันควรจะ; มันเป็นรูปแบบการผูกข้อมูลของคนจน

เป็นที่ยอมรับฉันชอบ databinding ของ WPF เพื่อใช้ประโยชน์จากมันฉันตั้งบริบทข้อมูลไปที่หน้าต่างตัวเองซึ่งมีการเข้าถึงชั้นธุรกิจเช่นเดียวกับคุณสมบัติที่สังเกตได้อื่น ๆ

ดีสำหรับคุณ. ไม่จำเป็นต้องเป็นไปตามมาตรฐาน MVVM แต่จำไว้ว่ารูปแบบเช่น MVVM ถูกสร้างขึ้นเพื่อช่วยให้นักพัฒนาสร้างระบบขนาดใหญ่ หากคุณเพียงต้องการแสดงข้อความโต้ตอบคุณอาจไม่ต้องการระบบประปาทั้งหมด

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

พิจารณาไลบรารี่ jQuery ของ John Resig: มันคือแก่นแท้ของการออกแบบที่เชื่อมโยงกันและซ่อนรายละเอียดแปลก ๆ มากมายเกี่ยวกับDOMและการเปลี่ยนแปลงในวิธีที่เบราว์เซอร์จัดการ มันง่ายกว่าไหมที่จะเขียน Javascript สองสามบรรทัด? บางครั้ง แต่ข้อดีของการเขียนรหัส jQuery ใน API ที่สม่ำเสมอและสม่ำเสมอทำให้ง่ายสำหรับบุคคลต่อไปที่จะเข้าใจสิ่งที่คุณทำและรักษารหัสนั้นถ้าจำเป็น

ประสบการณ์จริงของฉันกับโมเดล "แอปพลิเคชันขนาดใหญ่" กำลังใช้ ASP.NET MVC ASP.NET คือ ASP.NET MVC เนื่องจาก Winforms คือ WPF เมื่อฉันทำงานใน ASP.NET ฉันมักจะดิ้นรนเพื่อทำตามความประสงค์ของฉัน ASP.NET MVC โค้งเข้าหาคุณ มันเป็นความสุขที่จะใช้; มันสร้างโครงสร้างของระบบที่ชัดเจนและเป็นระเบียบและให้คุณควบคุมแอปพลิเคชันและมาร์กอัปของคุณได้อย่างเต็มที่ คุณสามารถใช้ Javascript, jQuery และ CSS ได้อย่างอิสระและ ASP.NET MVC ไม่ได้อยู่ในแนวทางของคุณ

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

อ่านเพิ่มเติม
คุณควรเรียนรู้ MVC โดย Rob Conery


ขอบคุณสำหรับการตอบสนองอย่างรอบคอบจากลูกใหญ่ของโคลน - ฉันรู้สึกอย่างนั้นในสมัยของงูเห่าคลาสสิคและสปาเก็ตตี้รหัส การออกแบบ 3 ชั้นที่มี vb6 / mts แก้ไขเรื่องนั้นได้อย่างมากและจากนั้นการเปิดตัวของ. net ก็รวมเข้าด้วยกัน แต่ตอนนี้หากรู้สึกว่าผลตอบแทนจากรูปแบบเพิ่มเติมนั้นลดน้อยลงอย่างรวดเร็ว - เช่นการใช้จ่าย $ 1M เพื่อใช้เวลา. 1 วินาทีในการปิดไตรมาสไมล์ของคุณ "ฉันผลักรหัสทุกบิตที่ฉันสามารถออกไปสู่การชุมนุมแยกกัน" - คุณไม่พบหรือไม่ว่านี่จะให้ประสบการณ์การพัฒนาที่แตกหักอย่างไม่น่าเชื่อ - กระโดดจากไฟล์หนึ่งไปยังอีกไฟล์หนึ่งเพื่ออ่านสองบรรทัดตลอดเวลา
b_levitt

3
don't you find that this gives an incredibly fractured development experience - constantly jumping from file to file to read two lines?- ไม่มันตรงกันข้าม การประกอบเข้าด้วยกันเช่นนี้ทำให้คุณเป็นอิสระในการมุ่งเน้นไปที่แต่ละชั้นเรียนและวิธีการตามเงื่อนไขของตัวเองเป็นกล่องดำเล็ก ๆ ของตัวเอง นั่นเป็นเรื่องยากมากที่จะทำกับลูกโคลนขนาดใหญ่ MVC ทำงานบนหลักการเดียวกัน: ตัวควบคุมบางรุ่นไขมันไม่มีรหัสในมุมมองเว้นแต่จำเป็นจริงๆ
Robert Harvey

3
Yagni ใช้เฉพาะเมื่อคุณเขียนรหัสด้วยตัวเอง หากคุณกำลังเขียนไลบรารีทั่วไปที่ต้องตอบสนองผู้ชมจำนวนมากที่มีความต้องการที่หลากหลายคุณจะต้องใช้มัน
Robert Harvey

1
ฉันไม่มีอะไรกับวงจรชีวิตของ ASP.NET โดยวิธี; ฉันเคยเห็นคนใช้มันเพื่อผลที่ยอดเยี่ยม ฉันเพิ่งพบว่ามันตอบโต้ได้ง่ายนั่นคือทั้งหมด ASP.NET MVC ไม่ได้บังคับให้คุณทำการพัฒนาฝั่งไคลเอ็นต์หากคุณไม่ต้องการ คุณสามารถใช้มุมมอง "โง่" และทำงานได้อย่างสมบูรณ์แบบ น่าสังเกต: สิ่งต่าง ๆ มากมายสามารถสร้างรหัสได้ (เหมือนกับฟอร์ม Windows) ดังนั้นจึงไม่เหมือนกับที่คุณเขียนโค้ดทั้งหมดด้วยตัวเอง ฉันเข้าใจว่านี่เป็นความจริงที่น้อยกว่ากับ WPF ที่คุณต้องจัดการกับ XAML และฉันคิดว่ามีที่ว่างสำหรับการปรับปรุงที่นั่น
Robert Harvey

2
dozens of lines of plumbing to replace Window.Show- นั่นเป็นเรื่องเล็กน้อยที่ทำให้เข้าใจผิด ถ้าหน้าต่างต้องการข้อมูลมันจะมีระบบประปาบางอย่างที่จะนำข้อมูลนั้นไปไว้ในส่วนควบคุมของหน้าต่างและในทางกลับกัน คุณสามารถเขียนโค้ดซ้ำ ๆ ซ้ำไปซ้ำมาสำหรับทุก ๆ รูปแบบที่คุณสร้างหรือใช้รูปแบบของโซลูชันทั่วไปเช่นการผูกข้อมูล
Robert Harvey
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.