Bagaimana merancang aplikasi desktop perusahaan untuk Windows 8

Saya pikir saya memiliki pemahaman tentang harapan pengembangan aplikasi konsumen untuk Windows 8. Buat UI berbasis Metro baru di atas WinRT, sebarkan ke pelanggan Anda melalui Marketplace, dan semua orang menang. Tampak cukup sederhana. Sayangnya, saya tidak dalam bisnis itu.

Saya bekerja pada aplikasi internal, lini bisnis untuk perusahaan besar. Kami saat ini menggunakan teknologi .NET seperti WPF dan Silverlight untuk membuat UI kaya yang dapat dengan mudah digunakan untuk pengguna kami melalui web atau ClickOnce. Aplikasi dapat mendukung WinXP dan Win7 tanpa terlalu banyak sakit kepala, dan pengembang kami dapat menggunakan XAML yang merupakan teknologi UI yang sangat solid.

Sepertinya WPF dan Silverlight memiliki masa depan yang dipertanyakan pada saat ini, jadi agak mengkhawatirkan untuk terus berinvestasi pada mereka. Tetapi Metro UI tampaknya tidak sesuai untuk aplikasi perusahaan, dan API WinRT cukup membatasi sehubungan dengan hal-hal "khas" yang harus dilakukan aplikasi perusahaan.

Bagaimana saya harus merancang aplikasi berbasis XAML saya, yang saat ini sedang digunakan untuk WinXP dan Win7, sehingga aplikasi tersebut dapat didukung dan dikembangkan pada Win8?

Asumsikan untuk keperluan pertanyaan ini bahwa fitur yang disediakan oleh HTML5 di atas ASP.NET tidak memadai untuk aplikasi yang ingin saya buat. Saya mengerti bahwa saya dapat menggunakan HTML5 untuk beberapa aplikasi, tetapi saya mencoba mencari tahu apa yang harus saya lakukan ketika itu tidak cukup.

Sunting # 1: Ini sebagai tanggapan terhadap komentar @Emmad Kareem. Saya setuju bahwa Silverlight / WPF layak dalam jangka pendek (2-5 tahun). Namun, aplikasi yang kami hasilkan memiliki masa hidup yang berpotensi sangat lama (10-20 + tahun). Jadi kemampuan bertahan dalam jangka panjang untuk teknologi tertentu menjadi perhatian kami. Juga, kami memiliki kekhawatiran bahwa akan semakin sulit untuk menemukan pengembang yang tertarik pada pengembangan Silverlight / WPF jika teknologi tersebut dianggap "mati" oleh masyarakat. Saya hanya ingin memahami pilihan saya dan membuat keputusan dengan mata terbuka.

Bagaimana Saya Belajar untuk Berhenti Khawatir dan Menyukai MS-Stack

Anda masih dapat menjalankan aplikasi VB6 di windows 8 . Kompatibilitas retro baik atau buruk selalu menjadi tren dalam ekosistem MS. Anda tidak perlu khawatir tentang kelangsungan hidup teknologi seperti WPF / Silveright, dan bahkan winforms dalam hal ini.

Di sisi lain, Anda harus menerima bahwa untuk proyek jangka panjang, Anda tidak akan pernah memiliki teknologi terbaru yang paling keren.

Sebenarnya pertanyaan yang harus Anda tanyakan pada diri sendiri tentang pilihan teknologi adalah:

• Apakah tim saya cukup nyaman dengan teknologi itu untuk menjadi produktif?
• Apakah tim saya senang menggunakan teknologi itu?
• Bisakah saya merekrut orang untuk teknologi itu?

Itulah kombinasi dari jawaban untuk pertanyaan ini yang seharusnya mengarahkan pilihan Anda, dan bukan tren yang dipalsukan terutama karena alasan pemasaran.

Untuk informasi lebih lanjut tentang tematik teknologi yang terus berubah ini, Anda harus membaca "Fire And Motion" Oleh Joel Spolsky :

Perusahaan yang tersandung adalah orang-orang yang menghabiskan terlalu banyak waktu membaca daun teh untuk mengetahui arah masa depan Microsoft. Orang-orang khawatir tentang .NET dan memutuskan untuk menulis ulang seluruh arsitektur mereka untuk .NET karena mereka pikir mereka harus melakukannya. Microsoft menembaki Anda, dan itu hanya menutupi sehingga mereka dapat bergerak maju dan Anda tidak bisa, karena ini adalah cara permainan dimainkan, Bubby. Apakah Anda akan mendukung Hailstorm? SABUN MANDI? RDF? Apakah Anda mendukungnya karena pelanggan Anda membutuhkannya, atau karena seseorang menembaki Anda dan Anda merasa harus merespons? Tim penjualan dari perusahaan besar memahami api unggun.

Dan itu ditulis hampir sepuluh tahun yang lalu.

Arsitektur dan Teknologi

Arsitektur dan Teknologi adalah dua hal dan pilihan yang terpisah untuk dilakukan:

• Anda dapat melakukan MVC dengan winforms .
• Anda dapat melakukan MVVM dengan WPF / Silverlight .
• Anda dapat melakukan MVC dengan ASP.NET .
• Anda dapat melakukan apa pun yang Anda inginkan, termasuk MVC dan MVVM, dengan WINRT sejauh yang kami tahu .
• Anda bisa berfungsi dengan F # . Kenapa tidak ? Ada domain di mana itu masuk akal.
• Anda dapat mencampur semuanya, untuk memiliki titik masuk yang berbeda ke sistem umum, kemudian diejek karena terlalu rumit , dll.

Anda dapat menggunakan layanan, sumber daya, kontrol pihak ketiga, ORM, dll. Dengan semua teknologi ini, dan mungkin, atau mungkin tidak, dengan yang berikutnya.

Anda dapat memutar dan menekuk MVC dalam banyak cara dengan semua teknologi itu: Mengikat atau tidak? kode di belakang tampilan atau tidak? Kontroler atau tidak? ViewModel setiap saat atau hanya saat dibutuhkan? Ada begitu banyak cara untuk menerapkan pola desain, bahkan dalam lingkup satu teknologi tertentu.

Itu tidak realistis untuk memaksa Anda menjadi salah satu dari mereka tanpa pengetahuan lanjutan tentang proyek dan tim Anda. Itu hanya akan didasarkan pada preferensi pribadi, dan akan berakhir pada pertikaian "teknologi saya lebih baik dari Anda".

Satu-satunya hal yang dapat disarankan secara jujur ​​dan obyektif adalah menggunakan praktik terbaik yang dapat Anda terapkan untuk membuat arsitektur yang akan bertahan dalam ujian waktu, dan mungkin, benar-benar mungkin akan portabel atau digunakan kembali setidaknya di bagian-bagian dengan teknologi yang tidak diketahui di masa depan. . Dan upgrade / portabilitas seharusnya tidak menjadi tujuan utama arsitektur Anda.

Tujuan utama arsitektur Anda dan teknologi yang dipilih adalah untuk memberikan produk kepada atasan / pelanggan Anda yang memenuhi persyaratan realistisnya.

MVC (dan itu adalah adiknya MVVM) terbukti semakin menjadi dasar untuk arsitektur yang kuat sejak 1979 di arena bahasa OOP dan seterusnya. Tetapi memilih teknologi spesifik apa yang harus digunakan dalam proyek 10 tahun harus tetap menjadi keputusan Anda.

Satu hal yang akan saya bahas dalam buku saya tentang MVVM adalah bagaimana memanfaatkan pola untuk membuat aplikasi inti yang dapat digunakan kembali. Anda harus membuat UI asli untuk berbagai platform yang Anda targetkan (baik itu web, silverlight, telepon, WPF, atau WinRT). Tetapi untuk sebagian besar, Anda dapat merangkum logika mengemudi UI di belakang ViewModel.

Setiap layanan yang Anda akses harus dibungkus dengan antarmuka (pola Fasad) yang lebih atau kurang portabel antar platform. Antarmuka harus memetakan ke API klien Anda di bagian depan dan menerjemahkan ke API layanan yang dibungkus di bagian belakang.

Strategi ini membantu Anda membuat kerangka inti yang solid yang hanya membutuhkan UI baru untuk dilapis di atasnya. Anggap saja sebagai Model Tampilan Anda sebagai otot, layanan Anda membuat kerangka (dan organ). WPF / Silverlight / WinRT membentuk kulit.

Bahkan, satu hal yang saya tunjukkan sangat awal dalam buku saya adalah bahwa MVVM tidak seperti yang baru. Dolphin Smalltalk memiliki pola yang sama yang mereka sebut MMVC (dua M adalah Model Aplikasi dan Model Domain). ViewModel yang kami gunakan saat ini hanyalah kombinasi dari Model Aplikasi dan Pengontrol dari MMVC. Bahkan banyak pengembang menemukan bahwa kadang-kadang memisahkan ViewModel menjadi dua komponen itu masuk akal (controller digunakan untuk navigasi dan mengatur beberapa VM sehingga VM dapat tetap tidak menyadari komponen lainnya).

Anda mengatakan XAML solid tetapi kemudian mengatakan WPF memiliki masa depan yang dipertanyakan. Kecuali saya kehilangan sesuatu, WPF menggunakan XAML dan saya tidak melihat keduanya terpisah. Apakah ada beberapa berita yang saya lewatkan tentang WPF mungkin menggunakan beberapa teknologi basis lain, atau tentang Microsoft bahkan mungkin mempertimbangkan membangun cara baru lain untuk membangun UI? Di luar itu, saya ragu WPF akan kemana-mana, tetapi itu bukan pertama kalinya MS telah mengirimkan banyak sekali kode kapal kami ...

Jika Anda memerlukan aplikasi UI yang kaya dan HTML5 tidak akan memotongnya, dan Anda org berkomitmen untuk windows OS, saya pikir WPF adalah pilihan terbaik karena ini adalah yang terbaru / terhebat saat ini, tentu di atas winforms ...

Menurut saya ini adalah Anda tidak boleh terlalu fokus pada detail implementasi aplikasi Anda. Jika Anda melihat gambar yang lebih besar, Anda dapat mengisolasi ketergantungan teknologi Anda. Dengan mengisolasi ketergantungan pada misalnya xaml / wpf / silverlight Anda memastikan bahwa Anda dapat mengganti komponen ui / teknologi dengan teknologi generasi berikutnya dan karenanya menjamin kelangsungan bahkan dalam waktu 20 tahun. Ini juga akan membantu memisahkan komponen sistem Anda dan mengalahkan dampak harus melakukan penggantian seperti itu. (Dalam hal ini saya membuat asumsi bahwa untuk memberikan kontinuitas tidak apa-apa untuk mengotak-atik solusi agar dapat berjalan pada platform generasi berikutnya)

Cara lain untuk menyediakan isolasi dari ketergantungan teknologi ini adalah memungkinkan virtualisasi. Jika Anda membuat aplikasi Anda sedemikian rupa sehingga Anda dapat menjalankannya dalam vm, Anda akan dapat melakukannya dalam waktu 20 tahun!