วิธีออกแบบแอปพลิเคชันระดับองค์กรเดสก์ท็อปสำหรับ Windows 8

ฉันคิดว่าฉันมีความเข้าใจในความคาดหวังของการพัฒนาแอปพลิเคชันผู้บริโภคสำหรับ Windows 8 สร้าง UI แบบใหม่บนเมโทรบน WinRT ปรับใช้กับลูกค้าของคุณผ่านทาง Marketplace และทุกคนชนะ ดูเหมือนง่ายพอ น่าเสียดายที่ฉันไม่ได้อยู่ในธุรกิจนั้น

ฉันทำงานกับแอปพลิเคชันภายในสายงานธุรกิจสำหรับองค์กรขนาดใหญ่ ขณะนี้เราใช้เทคโนโลยี. NET เช่น WPF และ Silverlight เพื่อสร้าง UIs ที่หลากหลายซึ่งสามารถปรับใช้กับผู้ใช้ของเราผ่านทางเว็บหรือ ClickOnce ได้อย่างง่ายดาย แอปพลิเคชันสามารถรองรับ WinXP และ Win7 ได้โดยไม่ต้องปวดหัวมากนักและนักพัฒนาของเราจะใช้ XAML ซึ่งเป็นเทคโนโลยี UI ที่แข็งแกร่งมาก

ดูเหมือนว่า WPF และ Silverlight จะมีข้อสงสัยในอนาคต ณ จุดนี้ดังนั้นจึงเป็นเรื่องน่ากังวลที่จะลงทุนในหุ้นเหล่านี้ต่อไป แต่ Metro UI ดูเหมือนจะไม่เหมาะสมสำหรับแอปพลิเคชันระดับองค์กรและ WinRT API ค่อนข้าง จำกัด เกี่ยวกับสิ่งที่ "ทั่วไป" ที่แอปพลิเคชันระดับองค์กรต้องทำ

ฉันจะออกแบบสถาปัตยกรรมแอปพลิเคชั่นที่ใช้ XAML ของฉันซึ่งกำลังปรับใช้กับ WinXP และ Win7 ได้อย่างไรเพื่อให้พวกเขาสามารถสนับสนุนและพัฒนาบน Win8 ได้

สมมติว่าสำหรับวัตถุประสงค์ของคำถามนี้ว่าคุณลักษณะที่มีให้โดย HTML5 ที่ด้านบนของ ASP.NET นั้นไม่เพียงพอสำหรับแอปพลิเคชันที่ฉันต้องการสร้าง ฉันเข้าใจว่าฉันสามารถใช้ HTML5 สำหรับบางแอปพลิเคชันได้ แต่ฉันพยายามหาว่าฉันควรทำอย่างไรเมื่อนั่นยังไม่เพียงพอ

แก้ไข # 1: นี่คือการตอบสนองต่อความคิดเห็นของ @Emmad Kareem ฉันยอมรับว่า Silverlight / WPF มีศักยภาพในระยะสั้น (2-5 ปี) อย่างไรก็ตามแอปพลิเคชันที่เราผลิตนั้นมีอายุการใช้งานยาวนานมาก (10-20 ปีขึ้นไป) ความอยู่รอดในระยะยาวสำหรับเทคโนโลยีที่กำหนดจึงเป็นสิ่งที่เรากังวล นอกจากนี้เรามีข้อกังวลว่าจะพบนักพัฒนาที่สนใจการพัฒนา Silverlight / WPF มากขึ้นเรื่อย ๆ หากเทคโนโลยีเหล่านั้นถูกพิจารณาว่าเป็น "ตาย" โดยชุมชน ฉันแค่ต้องการที่จะเข้าใจตัวเลือกของฉันและตัดสินใจด้วยตาของฉันเปิด

ฉันเรียนรู้ที่จะหยุดกังวลและรัก MS-Stack ได้อย่างไร

คุณยังสามารถเรียกใช้แอป VB6 บน windows 8ได้ ความเข้ากันได้ย้อนยุคสำหรับดีหรือไม่ดีเป็นแนวโน้มในระบบนิเวศ MS เสมอ คุณไม่ควรกังวลเกี่ยวกับความอยู่รอดของเทคโนโลยีเช่น WPF / Silveright และแม้แต่ winforms สำหรับเรื่องนั้น

ในอีกทางหนึ่งคุณต้องยอมรับว่าสำหรับโครงการระยะยาวคุณจะไม่เคยมีเทคโนโลยีใหม่ล่าสุดที่น่ารักที่สุด

ในความเป็นจริงคำถามที่คุณควรถามตัวเองเกี่ยวกับการเลือกเทคโนโลยีคือ:

• ทีมของฉันสะดวกสบายพอที่จะใช้เทคโนโลยีนั้นให้เกิดประโยชน์หรือไม่?
• ทีมของฉันยินดีที่จะใช้เทคโนโลยีนั้นหรือไม่?
• ฉันสามารถรับคนจากเทคโนโลยีนั้นได้หรือไม่?

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

หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับเทคโนโลยีที่เปลี่ยนแปลงตลอดเวลาคุณควรอ่าน"Fire And Motion"โดย Joel Spolsky :

บริษัท ที่สะดุดคือ บริษัท ที่ใช้เวลามากเกินไปในการอ่านใบชาเพื่อหาทิศทางในอนาคตของ Microsoft ผู้คนกังวลเกี่ยวกับ. NET และตัดสินใจที่จะเขียนทั้งสถาปัตยกรรมของพวกเขาสำหรับ. NET เพราะพวกเขาคิดว่าพวกเขาต้อง Microsoft กำลังยิงคุณอยู่และมันเป็นเพียงการปิดไฟเพื่อให้พวกเขาสามารถก้าวไปข้างหน้าและคุณทำไม่ได้เพราะนี่คือวิธีการเล่นเกมของ Bubby คุณจะให้การสนับสนุน Hailstorm หรือไม่? สบู่? RDF? คุณสนับสนุนเพราะลูกค้าของคุณต้องการหรือเพราะมีคนยิงคุณและคุณรู้สึกว่าคุณต้องตอบหรือไม่ ทีมขายของ บริษัท ใหญ่เข้าใจเรื่องไฟไหม้

และนั่นก็ถูกเขียนขึ้นเกือบสิบปีที่แล้ว

สถาปัตยกรรมและเทคโนโลยี

สถาปัตยกรรมและเทคโนโลยีเป็นสองสิ่งและตัวเลือกที่ต้องทำ

• คุณสามารถทำMVC กับ winformsได้
• คุณสามารถทำเช่นMVVM กับ WPF
• คุณสามารถทำMVC ด้วย ASP.NET
• คุณสามารถทำสิ่งที่คุณต้องการรวมทั้ง MVC และ MVVM ด้วย WinRT เท่าที่เรารู้
• คุณสามารถไปทำงานกับF # ทำไมจะไม่ล่ะ ? มีโดเมนที่เหมาะสมแล้ว
• คุณสามารถผสมพวกเขาทั้งหมดเพื่อให้มีจุดเข้าใช้ที่แตกต่างกับระบบทั่วไปจากนั้นจะถูกเยาะเย้ยเพราะมันซับซ้อนเกินไปฯลฯ

คุณสามารถใช้บริการทรัพยากรการควบคุมของบุคคลที่สาม ORMs ฯลฯ ด้วยเทคโนโลยีทั้งหมดนี้และอาจจะหรืออาจจะไม่ใช้กับสิ่งต่อไปนี้

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

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

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

วัตถุประสงค์หลักของสถาปัตยกรรมและเทคโนโลยีที่เลือกของคุณคือการส่งมอบผลิตภัณฑ์ให้กับเจ้านาย / ลูกค้าของคุณที่ตรงกับความต้องการที่แท้จริงของเขา

MVC (และเป็นน้องชาย MVVM) พิสูจน์ให้มากขึ้นว่าเป็นพื้นฐานสำหรับสถาปัตยกรรมที่แข็งแกร่งมาตั้งแต่ปี 1979ในเวทีภาษา OOP และอีกมากมาย แต่การเลือกเทคโนโลยีเฉพาะที่ควรใช้ในโครงการระยะเวลา 10 ปีควรจะยังคงเป็นการตัดสินใจของคุณ

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

บริการใด ๆ ที่คุณเข้าถึงควรห่อหุ้มอินเตอร์เฟซ (รูปแบบซุ้ม) ที่พกพาได้มากหรือน้อยระหว่างแพลตฟอร์ม อินเทอร์เฟซควรแมปไปยังไคลเอนต์ API ของคุณที่ด้านหน้าและแปลเป็น API ของบริการที่ห่อไว้ที่ด้านหลัง

กลยุทธ์นี้ช่วยให้คุณสร้างเฟรมเวิร์กคอร์ที่มั่นคงซึ่งต้องการเพียงแค่ UI ใหม่ที่จะอยู่ด้านบนของมัน คิดว่าเป็นรูปแบบการดูของคุณเป็นกล้ามเนื้อบริการของคุณทำโครงกระดูก (และอวัยวะ) WPF / Silverlight / WinRT ก่อให้เกิดผิว

อันที่จริงสิ่งหนึ่งที่ฉันชี้ให้เห็นตั้งแต่ต้นในหนังสือของฉันคือ MVVM ไม่ใช่เรื่องใหม่อย่างที่คิด ดอลฟินสมอลทอล์คมีรูปแบบคล้ายคลึงกันซึ่งพวกเขาเรียกว่า MMVC (ทั้งสอง M คือแอปพลิเคชันโมเดลและโมเดลโดเมน) ViewModel ที่เราใช้ในวันนี้เป็นเพียงการผสมผสานระหว่าง Application Model และ Controller จาก MMVC ในความเป็นจริงนักพัฒนาหลายคนพบว่าบางครั้งการแยก ViewModel ออกเป็นสององค์ประกอบนั้นสมเหตุสมผล

คุณบอกว่า XAML นั้นแข็งแกร่ง แต่แล้วบอกว่า WPF มีอนาคตที่น่าสงสัย WPF ใช้ XAML และฉันไม่เห็นว่าทั้งสองถูกแยกจากกันเว้นแต่ว่าฉันขาดอะไรไป มีข่าวบางอย่างที่ฉันหายไปเกี่ยวกับ WPF อาจใช้เทคโนโลยีพื้นฐานอื่น ๆ หรือ Microsoft อาจพิจารณาสร้างอีกวิธีใหม่ในการสร้าง UIs นอกเหนือจากนั้นฉันสงสัยว่า WPF จะไปที่ใดก็ได้ แต่จะไม่เป็นครั้งแรกที่ MS ล้าสมัยจำนวนเรือบรรทุกรหัสของเรา ...

หากคุณต้องการแอป UI ที่สมบูรณ์และ HTML5 จะไม่ตัดมันและคุณก็มุ่งมั่นที่จะใช้ windows OS ฉันคิดว่า WPF เป็นตัวเลือกที่ดีที่สุดเนื่องจากเป็นรุ่นล่าสุด / ยิ่งใหญ่ที่สุดในตอนนี้แน่นอนมากกว่า winforms ...

สิ่งที่ฉันทำคือคุณไม่ควรให้ความสำคัญกับรายละเอียดการใช้งานแอปพลิเคชันของคุณมากเกินไป หากคุณดูภาพที่ใหญ่ขึ้นคุณสามารถแยกการพึ่งพาเทคโนโลยีของคุณ โดย isolatin การพึ่งพาเช่น xaml / wpf / silverlight ทำให้คุณมั่นใจได้ว่าคุณสามารถเปลี่ยนส่วนประกอบ / เทคโนโลยี ui ด้วยเทคโนโลยีรุ่นต่อไปและรับประกันความต่อเนื่องแม้ในเวลา 20 ปี สิ่งนี้จะช่วยแยกส่วนประกอบของระบบและช่วยลดผลกระทบจากการเปลี่ยนอุปกรณ์ดังกล่าว (ในที่นี้ฉันตั้งสมมติฐานว่าสำหรับการให้ความต่อเนื่องมันก็โอเคที่จะแก้ปัญหาเพื่อให้มันไปบนแพลตฟอร์มรุ่นต่อไป)

อีกวิธีหนึ่งในการแยกจากการพึ่งพาเทคโนโลยีเหล่านี้คือการเปิดใช้งานการจำลองเสมือน หากคุณสร้างแอปพลิเคชันของคุณในลักษณะที่คุณสามารถเรียกใช้ใน vm คุณจะสามารถทำได้ในเวลา 20 ปี!