จะเลือกไม่ใช้เฟรมเวิร์ก (Caliburn.Micro ฯลฯ ) ในแอปพลิเคชัน MVVM ที่กำหนดได้อย่างไร

28

ฉันเคยเริ่มโครงการ MVVM / WPF ซึ่งสร้างและปรับใช้ในที่สุดและเพื่อที่ฉันศึกษา Caliburn.Micro MVVM Framework จำนวนมาก ความจริงก็คือ: ฉันลงเอยด้วยการไม่ใช้ Caliburn.Micro สำหรับสิ่งนั้นและลงเอยด้วยการนำแนวคิด MVVM มาใช้ด้วยตัวเอง (โดยเฉพาะแค่ViewModelBaseและRoutedCommandคลาส)

ตอนนี้ฉันได้รับมอบหมายให้ทำโครงการขนาดใหญ่กว่าในบรรทัดเดียวกัน: "แอปพลิเคชันเดสก์ท็อปออฟไลน์ไคลเอนต์สำหรับผู้ใช้ที่มีผู้ใช้หลายคน" ดังนั้นจะพูดและฉันตัดสินใจใช้ Caliburn.Micro และนั่นคือสิ่งที่ "ปัญหา" ของฉันเริ่มต้นขึ้น

ฉันได้อ่านในโพสต์บล็อกที่มีชื่อเสียงชื่อเรื่องว่า "ถ้าคุณใช้ MVVM คุณต้องมีกรอบ" นั่น:

"พยายามที่จะทำสิ่งที่ต้องการโดยไม่ต้อง MVVM กรอบเป็นจำนวนมากของการทำงาน. ตันของรหัสที่ซ้ำกัน reinventing ล้อและฝึกอบรมคนที่จะคิดแตกต่างกัน

อย่างน้อยด้วยเฟรมเวิร์กที่คุณหลีกเลี่ยงรหัสที่ซ้ำกันและหวังว่าจะไม่ต้องบูรณาการล้อ - ช่วยให้คุณสามารถมุ่งเน้นไปที่การฝึกอบรมผู้คน ส่วนการอบรมขึ้นใหม่นั้นไม่สามารถหลีกเลี่ยงได้โดยทั่วไป แต่เฟรมเวิร์กจัดเตรียมรหัสการประปาและโครงสร้างทำให้กระบวนการง่ายขึ้น "

ฉันจะเห็นด้วยกับการอ่านครั้งแรก แต่ประสบการณ์จริงของฉันกับ Caliburn.Micro (CM) ในแอปพลิเคชันจริงของฉันคือการ cluelessness และ disorientation นั่นคือกรอบงานไม่ได้ทำให้กระบวนการง่ายขึ้นเลยตรงกันข้าม อ่านตัวอย่างที่เคยทำซ้ำให้โดยร็อบไอเซนเบิร์กในเอกสารค่อนข้าง (เกินไป) อย่างไม่เป็นทางการและพยายามที่จะรูปแบบการใช้สรุปจากตัวอย่างที่ซับซ้อนให้และการเรียนและอินเตอร์เฟซทางอ้อมอย่างเต็มที่ความสัมพันธ์ของพวกเขาสิ่งที่ดูเหมือนจะถูกออกแบบมาเพื่อการทำงานตามบน ผลข้างเคียงดูเหมือนเป็นไปไม่ได้อย่างมนุษย์ปุถุชนถ้าคุณไม่ได้เป็นอัจฉริยะตามฤดูกาล (ขออภัยในความโวยวาย แต่ฉันคิดว่าคุณรู้ว่าฉันหมายถึงอะไร)

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

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

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

frameworks wpf mvvm

— heltonbiker
แหล่งที่มา

1

ส่วนตัวฉันเลือกและเลือกรายการจากแต่ละเฟรมเวิร์กเพื่อใช้สำหรับพฤติกรรมที่เฉพาะเจาะจงและฉันไม่สนใจส่วนที่เหลือ ตัวอย่างเช่นฉันชอบใช้ Microsoft PRISM EventAggregatorสำหรับการส่งข้อความและNotificationObjectสำหรับ ViewModelBase และ MVVM Light RelayCommandสำหรับคำสั่ง สิ่งสำคัญคือการระบุปัญหาที่กรอบจะแก้ให้คุณและใช้วิธีแก้ปัญหาเหล่านั้นเท่านั้น อย่ารู้สึกว่าคุณถูกบังคับให้ใช้ไลบรารีเฟรมเวิร์กทั้งหมด

— Rachel

@ ราเชลฉันวางแผนที่จะใช้วิธีนี้กับ Caliburn.Micro แต่ไม่สามารถหาการRelayCommandใช้งานได้ (เพราะมัน "ผูก" กับวิธีโดยตรงโดยวิธีการประชุมแทนที่จะผูกพันกับคุณสมบัติ ICommand)

— heltonbiker

ฉันไม่เคยใช้กรอบ Caliburn เพราะฉันไม่ชอบความใกล้ชิดที่จะผูก Views กับเลเยอร์ Model / ViewModel ในกรณีของคุณฉันไม่เห็นเหตุผลใด ๆ ที่คุณไม่สามารถใช้ a RelayCommandจากไลบรารีอื่นถ้าสิ่งที่ Caliburn Micro ใช้ไม่ได้ผลสำหรับคุณ

— Rachel

@Rachel เกี่ยวกับ "[caliburn] เชื่อมโยงมุมมองกับเลเยอร์ MVM อย่างไร" คุณหมายถึงอะไร? อะไรคือวิธี "ไม่คาลิเบอร์" ในการผูกเลเยอร์เหล่านั้นด้วยวิธี MVVM ที่ดีกว่าและมากขึ้น? (ฉันถามด้วยความจริงใจเพราะฉันยังไม่รู้)

— heltonbiker

สุจริตฉันไม่เคยใช้ Caliburn Micro ดังนั้นฉันรู้สึกว่าฉันเป็นผู้ตัดสินที่ไม่ดีต่อกรอบ ฉันจำได้ว่าได้รับความประทับใจว่ามุมมองนั้นถูกสร้างขึ้นเป็นครั้งแรกและมีหน้าที่รับผิดชอบในการตัดสินใจเลือกวัตถุที่ไม่ใช้โค้ดซึ่งเป็นแง่มุมหนึ่งที่ฉันไม่ชอบเพราะฉันไม่ชอบการพัฒนา View-First อีกอย่างก็คือการเชื่อมโยงอัตโนมัติที่อาศัยวิธีที่คุณตั้งชื่อคอมโพเนนต์ XAML เนื่องจากฉันคิดว่ามันเชื่อมโยง UI กับเลเยอร์ธุรกิจมากเกินไป ฉันเคยได้ยินสิ่งที่ดีเกี่ยวกับกรอบแม้ว่าและจะไม่แนะนำให้หลีกเลี่ยงเพียงแค่ความเห็นของฉัน ลองด้วยตัวคุณเองและดูว่าคุณชอบมัน :)

— ราเชล

16

ฉันลองใช้ CaliburnMicro และ MVVMLight แล้วและเมื่อใช้ Caliburn ฉันรู้สึกว่าคุณรู้สึกอย่างแท้จริงแน่นอนว่ามันรู้สึกขลังจริง ๆ ที่สามารถผูกคุณสมบัติการควบคุมโดยใช้ชื่อ = "PropertyName" แทน Text Text = "{Bind PropertyName}" แต่ใน ในที่สุดคาลิเบอร์ก็ลงเอยด้วยการลงมือทำสิ่งมหัศจรรย์นี้เมื่อมีอะไรผิดพลาดมันยากที่จะดีบั๊กทำให้สิ่งเลวร้ายลง

แต่เมื่อใช้ MVVMLight มันบางเมื่อคุณใช้มันคุณอาจรู้ว่ามันเกือบ 100% เหมือน MVVM Framework ของคุณพร้อมกับคุณสมบัติบางอย่างที่โรยลงไป

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

— KIRIE
แหล่งที่มา

คุณคิดว่าอย่างน้อยฉันควรลองใช้ MVVMLight เป็น "การรักษา" จาก "Caliburn.Micro disorientation" หรือไม่? แน่นอนฉันจะดูว่าเป็นอย่างนั้นหรือเปล่า

— heltonbiker

@ Heltonbiker แน่นอนไปเลย มันง่ายกว่ามากอย่างน้อยควรให้หลักที่ดีใน MVVM Framework

— kirie

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

— ม้วน

10

สิ่งสำคัญคือต้องตระหนักว่า MVVM คืออะไร ไม่ใช่ฟังก์ชันการแชร์ที่คุณไม่ต้องนำมาใช้ใหม่ (แยกวิเคราะห์ไฟล์ JPEG หรือเชื่อมต่อกับเซิร์ฟเวอร์ฐานข้อมูล SQL ที่กำหนด) เป็นรูปแบบ - รูปแบบสำหรับวิธีที่ผู้ใช้อาจเลือกใช้ GUI ที่มีรูปแบบหลากหลาย ดังนั้นหากการนำรูปแบบของคุณไปใช้นั้นเรียบง่ายและตรงไปตรงมาฉันไม่คิดว่าคุณต้องรู้สึกอับอายในการใช้มันมากกว่ากรอบงาน

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

— ไมเคิล
แหล่งที่มา

2

นอกเหนือจากนั้น MVVM ตามที่ Microsoft เสนอ (นอกกรอบ WPF) ยังขาดอยู่มาก น่าผิดหวังมากสำหรับโปรแกรมเมอร์ที่คิดว่าตัวเองเป็นนักพัฒนามืออาชีพ สตริงมายากลข้อยกเว้นที่คลุมเครือในรันไทม์สิ่งพื้นฐานส่วนใหญ่เช่นการผูกกลุ่ม radiobuttons กับ enum ดูเหมือนstackoverflow.com/q/397556/168719 - เฟรมเวิร์กสามารถทำอะไรได้บ้าง พวกเขามีทั้งสะท้อนระดับของความซับซ้อนนี้หรือพยายามที่จะให้เป็นนามธรรมหนาจริงๆมากกว่านั้น

— คอนราด Morawski

2

@ KonradMorawski WPF ด้วยตัวเองไม่ใช่ MVVM; คุณสามารถทำโค้ดด้านหลังด้วย WPF แต่นั่นไม่ใช่ MVVM ดังนั้นหากคุณต้องการทำ WPF และ MVVM คุณจะต้องใช้เฟรมเวิร์ก MVVM หรือนำไปใช้งานด้วยตนเอง

— Andy

1

@ แน่นอน แต่มันก็ปลอดภัยที่จะบอกว่า WPF นั้นมีไว้สำหรับ MMVM ฉันหมายถึงฟังก์ชั่น MVVM ที่มาพร้อมกับ WPF ฉันรู้ว่าคุณยังสามารถทำโค้ดด้านหลังได้

— Konrad Morawski

@KonradMorawski คุณสามารถใช้ WPF กับ MVVM และพวกเขาสร้างมันขึ้นมาโดยคำนึงถึงความเป็นไปได้ แต่ก็ไม่มีฟังก์ชั่นเฉพาะ MVVM ที่สร้างขึ้นใน WPF เช่นเดียวกับคุณสามารถใช้ MVP กับ WinForms ได้ แต่ WinForms ไม่ได้เสนออะไรเป็นพิเศษในการใช้รูปแบบนั้นขึ้นอยู่กับคุณ

— Andy

3

@ บางทีเราอาจจะเถียงมากกว่าคำจำกัดความในขณะนี้ สิ่งที่ฉันหมายถึงคือ "กาว" ซึ่งทำให้ MVVM เป็นไปได้อยู่ที่นั่นแล้ว - การผูกข้อมูลใน XAML DataContextฯลฯ

— Konrad Morawski

7

ประสบการณ์ครั้งแรกของฉันกับ WPF ใช้ Caliburn.Micro ดังนั้นนี่อาจจะค่อนข้างแตกต่างจากนักพัฒนาส่วนใหญ่ ฉันได้พบทั้ง WPF และ Caliburn.Micro เป็นเส้นโค้งการเรียนรู้ที่ค่อนข้างสูงซึ่งมาจาก WinForms อย่างไรก็ตามหลังจากประสบการณ์บางอย่างกับทั้งสองฉันพบว่าพวกเขามีความสุขที่จะใช้เป็นคู่ ขณะนี้ทำงานในองค์กรอื่นที่ไม่ได้ใช้ Caliburn.Micro ฉันพบว่ามีรหัสประปาซ้ำซ้อนจำนวนมากซึ่งทำให้ codebase ค่อนข้างป่องและซับซ้อนเกินความจำเป็น

ฉันยอมรับอย่างแน่นอนว่ามีบาง gotchas กับ Caliburn.Micro ซึ่งสามารถทำให้การดีบักมีความซับซ้อนได้ แต่เมื่อมีประสบการณ์พวกเขาก็มีโอกาสน้อยกว่าที่จะเจ็บปวดอีกครั้ง ความเร็วในการพัฒนาที่เพิ่มขึ้นรหัสที่สะอาดและเอนลงและกรอบโดยรวมที่สนับสนุน MVVM ที่ดีกว่านั้นคุ้มค่าสำหรับฉัน

Caliburn.Micro ยังไม่ทำให้ WPF ของสต็อกเป็นโมฆะ - มันเพิ่งสร้างขึ้นมาด้านบนซึ่งหมายความว่าคุณยังคงสามารถใช้คุณสมบัติ WPF ได้ถ้าคุณชอบและใช้ Caliburn สักสองสามบิตถ้าคุณชอบ สิ่งนี้คล้ายกับที่ TypeScript และ JavaScript อยู่ร่วมกันในใจของฉัน

แน่นอนที่สุดฉันจะใช้ Caliburn.Micro ในโครงการ WPF ใหม่ใด ๆ ที่ฉันทำงานในอนาคตหากได้รับโอกาส

— รอสส์
แหล่งที่มา

3

ขอบคุณสำหรับคำตอบ. สองปีต่อมาฉันพบว่า "ยอมรับ" เฟรมเวิร์กเหล่านี้ได้ง่ายขึ้นมากหลังจากทำความเข้าใจแนวคิดของ Dependency Injection Containers ซึ่งฉันได้เรียนรู้จากหนังสือ "DI in .NET" ของ Mark Seeman ที่ยอดเยี่ยม

— heltonbiker

1

สำหรับใครก็ตามที่มาถึงที่นี่ด้วยความหงุดหงิดกับ Caliburn.Micro ให้ดูที่เฟรมเวิร์กนี้: Stylet

มันได้แรงบันดาลใจจาก Caliburn.Micro ยกเว้นมันจะลบเวทมนต์มากมายที่ทำให้คุณสับสนเกี่ยวกับสิ่งที่เกิดขึ้น นอกจากนี้เอกสารจะถูกเขียนด้วยภาษาที่ชัดเจนกว่าโดยไม่คิดว่าคุณต้องการลุยศัพท์แสงทางเทคนิค ดีกว่ามากสำหรับผู้เริ่มต้น

นอกจากนี้ Stylet ยังใช้แนวทาง ViewModel-First Caliburn.Micro และเฟรมเวิร์กอื่น ๆ มากมายใช้แนวทาง View-First ซึ่งมาพร้อมกับปัญหาบางอย่างที่น่าอึดอัดใจ หากคุณใช้หลักการของ SOLID และรหัสที่มีลวดลายได้ดีแล้วคุณก็น่าจะหาวิธีที่เป็นธรรมชาติมากขึ้นเนื่องจากใช้มุมมองที่ตรรกะของคุณควรขับเคลื่อนระบบไม่ใช่มุมมอง

— JamesHoux
แหล่งที่มา