Windows 8 için kurumsal masaüstü uygulamaları nasıl tasarlanır

Sanırım Windows 8 için tüketici uygulaması geliştirme beklentilerini anladım. WinRT'nin üstünde yeni bir Metro tabanlı kullanıcı arayüzü oluşturun, Marketplace aracılığıyla müşterinize dağıtın ve herkes kazanır. Yeterince basit görünüyor. Ne yazık ki, bu işte değilim.

Büyük bir işletme için şirket içi, iş kolu uygulamaları üzerinde çalışıyorum. Web veya ClickOnce aracılığıyla kullanıcılarımıza kolayca dağıtılabilen zengin UI'ler oluşturmak için şu anda WPF ve Silverlight gibi .NET teknolojilerini kullanıyoruz. Uygulamalar çok fazla baş ağrısı olmadan WinXP ve Win7'yi destekleyebilir ve geliştiricilerimiz çok sağlam bir UI teknolojisi olan XAML'yi kullanabilirler.

WPF ve Silverlight'ın bu noktada şüpheli gelecekleri var gibi görünüyor, bu yüzden bunlara yatırım yapmaya devam etmek biraz endişe verici. Ancak bir Metro kullanıcı arayüzü kurumsal uygulamalar için uygun görünmüyor ve WinRT API, kurumsal uygulamaların yapması gereken "tipik" şeyler açısından oldukça sınırlayıcı.

Şu anda WinXP ve Win7'ye dağıtılan XAML tabanlı uygulamalarımı nasıl tasarlamalıyım, böylece Win8'de desteklenebilir ve geliştirilebilirler?

Bu sorunun amaçları için, HTML5 tarafından ASP.NET'in üstünde sağlanan özelliklerin oluşturmak istediğim uygulamalar için yeterli olmadığını varsayalım. Bazı uygulamalar için HTML5 kullanabileceğimi anlıyorum, ancak bu yeterli olmadığında ne yapmam gerektiğini anlamaya çalışıyorum.

Edit # 1: Bu @Emmad Kareem'in yorumuna yanıt olarak. Silverlight / WPF'nin kısa vadede (2-5 yıl) geçerli olduğunu kabul ediyorum. Ancak, ürettiğimiz uygulamaların potansiyel olarak çok uzun ömürleri vardır (10-20 + yıl). Bu nedenle, belirli bir teknoloji için uzun vadede hayatta kalmak bizim için bir endişe kaynağıdır. Ayrıca, bu teknolojiler topluluk tarafından "ölü" olarak kabul edilirse, Silverlight / WPF geliştirmeyle ilgilenen geliştiricileri bulmanın gittikçe daha zor olacağına dair bazı endişelerimiz var. Sadece seçeneklerimi anlamak ve gözlerim açıkken karar vermek istiyorum.

Endişelenmeyi bırakmayı ve MS-Stack'i sevmeyi nasıl öğrendim

VB6 uygulamalarını yine de Windows 8'de çalıştırabilirsiniz . İyi ya da kötü için geriye dönük uyumluluk MS ekosisteminde her zaman bir trend olmuştur. WPF / Silveright gibi teknolojilerin hayatta kalması konusunda endişelenmemeli ve hatta bu konu için formlar kazanmamalısınız.

Öte yandan, uzun vadeli bir proje için asla en yeni, en tatlı teknolojiye sahip olamayacağınızı kabul etmelisiniz.

Aslında kendinize bir teknoloji seçimi hakkında sormanız gereken sorular şunlardır:

• Ekibim bu teknolojiyle üretken olacak kadar rahat mı?
• Ekibim bu teknolojiyi kullanmaktan mutlu mu?
• Bu teknoloji için insanları işe alabilir miyim?

Bu, çoğunlukla pazarlama nedenleriyle ortaya çıkan eğilimleri değil, seçiminizi yönlendirmesi gereken bu soruların cevaplarının birleşimidir.

Sürekli değişen teknolojinin bu teması hakkında daha fazla bilgi için Joel Spolsky'nin “Ateş ve Hareket” bölümünü okumalısınız :

Tökezleyen şirketler, Microsoft'un gelecekteki yönünü anlamak için çay yapraklarını okumak için çok fazla zaman harcayan şirketler. İnsanlar .NET için endişeleniyor ve tüm mimarilerini .NET için yeniden yazmaya karar veriyorlar çünkü yapmak zorunda olduklarını düşünüyorlar. Microsoft size ateş ediyor ve sadece ilerleyebilmeleri için ateşi koruyor ve yapamıyorsunuz, çünkü oyun böyle oynanıyor Bubby. Hailstorm'u destekleyecek misin? SABUN? RDF? Müşterilerinizin ihtiyaç duyduğu veya birisinin size ateş açtığı ve yanıt vermek zorunda olduğunuzu düşündüğünüz için mi destekliyorsunuz? Büyük şirketlerin satış ekipleri kapak yangınını anlıyor.

Ve bu neredeyse on yıl önce yazılmıştı.

Mimarlık ve Teknoloji

Mimari ve Teknolojiler iki ayrı şey ve seçimdir:

• Sen yapabilirsin Win ile MVC .
• WVF / Silverlight ile MVVM yapabilirsiniz .
• ASP.NET ile MVC yapabilirsiniz .
• MVC ve MVVM de dahil olmak üzere WINRT ile bildiğimiz kadarıyla istediğinizi yapabilirsiniz .
• F # ile işlevsel hale gelebilirsiniz . Neden olmasın ? Mantıklı olacağı alanlar var.
• Hepsini karıştırabilir, ortak bir sisteme farklı giriş noktalarına sahip olabilirsiniz , sonra çok karmaşık hale geldiğinden alay edilebilir , vb.

Tüm bu teknolojilerle hizmetleri, kaynakları, üçüncü taraf denetimlerini, ORM'leri vb. Kullanabilirsiniz, belki de belki de bir sonraki teknolojilerle.

Tüm bu teknolojilerle MVC'yi birçok şekilde bükebilir ve bükebilirsiniz: Bağlama veya değil mi? görünüm arkasında kod ya da değil? Kontrolör mü değil mi? ViewModel her zaman mı yoksa sadece gerektiğinde mi? Belirli bir teknoloji kapsamında bile bir tasarım deseni uygulamanın birçok yolu vardır.

Bu, projeniz ve ekibiniz hakkında ileri düzeyde bilgi sahibi olmadan sizi bunlardan birine zorlamak için gerçek dışı olacaktır. Yalnızca kişisel tercihlere dayanır ve "teknolojim sizinkinden daha iyidir" hesaplamasına katlanır.

Dürüst ve nesnel olarak önerilebilecek tek şey, zamanın testine dayanacak bir mimari oluşturmak için uygulayabileceğiniz en iyi uygulamaları kullanmaktır ve belki de belki de en azından gelecekteki bilinmeyen bir teknolojiye sahip parçalarda taşınabilir veya yeniden kullanılabilir . Ve bu yükseltilebilirlik / taşınabilirlik, mimarinizin ana amacı bile olmamalıdır.

Mimarinizin ve seçtiğiniz teknolojinin temel amacı, patronunuza / müşterinize gerçekçi gereksinimlerini karşılayan bir ürün sunmaktır.

MVC (ve küçük kardeşi MVVM), 1979'dan beri OOP dil arenasında ve ötesinde sağlam mimariye temel oluşturduğunu kanıtladı . Ancak 10 yıllık bir projede hangi teknolojinin kullanılacağını seçmek kararınız olarak kalmalıdır.

MVVM hakkındaki kitabımda ele alacağım bir şey, yeniden kullanılabilir bir çekirdek uygulama oluşturmak için kalıbın nasıl kullanılacağıdır. Hedeflediğiniz çeşitli platformlar için (web, silverlight, telefon, WPF veya WinRT gibi) yerel bir kullanıcı arayüzü oluşturmalısınız. Ancak, çoğunlukla, bir kullanıcı arayüzünü bir ViewModel'in arkasındaki mantık sürüşünü kapsülleyebilirsiniz.

Eriştiğiniz tüm hizmetler, platformlar arasında az çok taşınabilir olan bir arabirimin (Cephe kalıbı) arkasına sarılmalıdır. Arayüz, ön taraftaki istemci API'nizle eşleşmeli ve arka taraftaki kaydırılan hizmetin API'sına çevrilmelidir.

Bu strateji, yalnızca yeni bir kullanıcı arayüzünün üzerine yerleştirilmesini gerektiren sağlam bir temel çerçeve oluşturmanıza yardımcı olur. Görüş modelinizin kaslar olduğunu düşünün, hizmetleriniz iskeleti (ve organları) yapar. WPF / Silverlight / WinRT cildi oluşturur.

Aslında, kitabımda çok erken belirttiğim bir şey, MVVM'nin göründüğü kadar yeni olmaması. Dolphin Smalltalk, MMVC olarak adlandırdıkları benzer bir desene sahipti (iki M, Uygulama Modeli ve Alan Modeli idi). Bugün kullandığımız ViewModel, MMVC'nin Uygulama Modeli ve Denetleyicisinin sadece bir kombinasyonudur. Aslında birçok geliştirici, ViewModel'i bazen iki bileşene ayırmanın mantıklı olduğunu buluyor (denetleyici birden çok VM'yi gezinmek ve düzenlemek için kullanılıyor, böylece VM diğer bileşenlerden habersiz kalabilir.)

XAML'ın sağlam olduğunu söylüyorsunuz, ancak WPF'nin şüpheli bir geleceği olduğunu söylüyorsunuz. Bir şey eksik olmadıkça, WPF XAML kullanıyor ve ikisinin ayrıldığını görmüyorum. Henüz muhtemelen diğer bazı temel teknolojisi kullanılarak WPF hakkında eksik bazı haber var mı, yoksa Microsoft hakkında daha da muhtemelen binanın dikkate başka yapı UI'ler yeni yolu? Bunun dışında, WPF'nin herhangi bir yere gittiğinden şüpheliyim, ancak MS ilk kez kodumuzun tekne yüklerini eskimiş olmasa ...

Zengin bir UI uygulamasına ihtiyacınız varsa ve HTML5 bunu kesmezse ve kuruluş Windows işletim sistemine bağlıysanız, WPF'nin şu anda en son / en büyük olduğu için kesinlikle en iyi seçim olduğunu düşünüyorum ...

Bunu benim almam, uygulamalarınızın uygulama detaylarına çok fazla odaklanmamanız gerektiğidir. Daha büyük bir resme bakarsanız, teknoloji bağımlılıklarınızı izole edebilirsiniz. İzolatiyle, örneğin xaml / wpf / silverlight'a bağımlılık, ui bileşenini / teknolojisini yeni nesil bir teknoloji ile değiştirebilmenizi ve böylece 20 yıl içinde bile sürekliliği garanti etmenizi sağlar. Bu aynı zamanda sistem bileşenlerinizin ayrılmasına ve böylesi bir değiştirme işlemini gerçekleştirmenin etkisine de yardımcı olacaktır. (Burada, süreklilik sağlamak için bir sonraki nesil platformda devam etmesini sağlamak için bir çözüm bulmanın uygun olduğunu varsayıyorum)

Bu teknoloji bağımlılıklarından izolasyon sağlamanın başka bir yolu da sanallaştırmayı sağlamaktır. Uygulamalarınızı bir vm'de çalıştırabileceğiniz bir şekilde yaparsanız, bunu 20 yıl içinde yapabilirsiniz!