最近、マイクロソフトの技術スタックに多くの変更があり、開発者と****はどの技術に焦点を当てるべきか迷っています。 マイクロソフト自身は、Silverlightのような技術に公式に反対することを望んでおらず、それらが無名になることを好んでいますが、そうでなければ非常に混乱した状況になりかねません。この質問に対する答えを知りたければ、あまり知られていないドキュメント"をチェックしてください。.NETビジネスアプリケーション技術ガイド」は昨年初めに発表されたもので、マイクロソフトがどのような分野に取り組むつもりなのか、またどのような技術を避けるべきなのかについて、非常に深く掘り下げています。
以下の概要図は、マイクロソフトとその関連技術を探求するための良い出発点です。
SilverlightとFlashはできるだけ早く捨ててください！
WinForms や Web Forms のような古い .NET テクノロジにはまだ場所がありますが、Silverlightや Flash のような RIA コンテナは間違いなくアウトです。下の図5-15が示すように、マイクロソフトはSilverlight 5の計画された10年のライフサイクルを空しく待つことを望んでいません。彼らはすでに2015年末までにRIAコンテナを放棄する予定です。
一方、ローエンドのアプリは、HTML5の機能が進化し続けることを期待しています。開発者が特定の種類のテクノロジーに傾倒することはありませんが、このシフトについて注意しなければならないことがあります：
- ネイティブアプリに移行するのであれば、どのWindowsデバイスでも動作するように生まれたXAML/.NETをターゲットにすることで、すでに持っているスキルやコードさえも活用することができます。ポータブル・クラス・ライブラリを使えば、Silverlightを含む異なるプラットフォーム間でライブラリを共有することもできます。
- SilverlightとHTMLの相互運用性により、ハイブリッドアプリケーションへの段階的な移行も可能です。
モバイル
Windows 8 ストアには、同じようで異なる3つのオプションがあります。
Windows 8ストアアプリの場合、Microsoftはこれまで開発者に特定のテクノロジースタックを押し付けることに消極的でした。その方針は今も変わっていません。.NET/XAML、C++、JavaScript/HTML5の技術から選択する主な基準は、開発者がどの技術に最も精通しているかということです。
それに加えて、パフォーマンスの優位性からC++も挙げられました。3つのプラットフォームはすべて、Windows PhoneとWindows Desktopの間でコードとリソースを共有することができるため、再利用性は大きな懸念点ではありませんでした。
Windows Phoneのネイティブオプション
Windows Phoneの推奨技術は、.NETとC++です。繰り返しになりますが、C++のパフォーマンス上の利点に注意することは重要です。
Windows PhoneはPhoneGap/Apache Cordova互換性がありますが、この点については言及されていません。おそらくその理由は、小型デバイスでのPhoneGapのパフォーマンスが.NETやC++よりも劣っていると考えているからでしょう。Build 2013では、一般的なユーザビリティ、ビジュアルデザイン、OSとの深い統合といった他のトピック以上に、パフォーマンスが最も重要なトピックであったことは確かです。
モバイルウェブ：ウェブフォームを除き、すべて使用可能
すべてのモバイルデバイスで動作するWebベースのソリューションが必要な場合、いくつかの選択肢があります。ASP.NETのMVCとModernizer基本的な推奨であり、シングルページアプリケーション作成するために使用できます。MicrosoftのSPAに対する見解は、テクノロジーというよりもデザインパターンであり、MicrosoftはKnockoutBreezeクラスライブラリも強く推奨しています。
CRUD、LightSwitchアプリケーションを素早く組み立てる目的で掲載されました。このフレームワークは HTML レンダリングをほとんど制御できませんが、開発者がさまざまな画面サイズに対応するレイアウトを構築する必要がないため、作業負荷が軽減されます。
ASP.NET Web、モバイルWeb向けに提供される4番目のオプションです。Razor構文に基づいており、PHPや従来のASP.NETのようなスクリプト言語と同様の開発体験を開発者に提供します。
このガイドでは、古い ASP.NET レンダリングツールキットである Web Forms については触れていません。この技術はまだ活発に開発されており、理論的にはデバイス固有の HTML をレンダリングすることができますが、実際には Web Forms はその真の可能性を発揮していません。Web Forms がレンダリングする HTML と JavaScript は非効率的で、高度な機能に必要なview state状態は携帯電話のネットワーク接続をすぐに圧迫してしまいます。
サービス
ほとんどのアプリケーションは外部データの保存と処理に依存しているため、サーバーサイドの開発は依然として非常に重要な検討事項です。マイクロソフトは、現在6つの実行可能な技術オプションがあると考えています。
***ASP.NET Web API
Microsoftが提供する情報によると、新規プロジェクトのデフォルトの選択肢はASP.NET Web API、RESTスタイルに従ったサービスを開発したい場合や、「Akamai、Windows Azure CDN、Level3など」のインターネットキャッシングに対応する必要がある場合に使用できます。REST スタイルに従ったサービスを開発したい場合や、「Akamai、Windows Azure CDN、Level3 など」のインターネットキャッシングに対応する必要がある場合は、この技術を使用できます。
開発者は、Web APIを使用する際、ODataJSONに焦点を当てる必要があります。
第二の選択肢：WCF
WCFは、特定のトランスポート・プロトコルやメッセージ・フォーマットに縛られないため、Web APIよりも柔軟なオプションと考えられています。例えば、パフォーマンスを向上させるためにTCPや名前付きパイプ、バイナリメッセージを使用することができます。欠点は、特にJSONやその他の非SOAPベースのフォーマットでデータを公開したい場合、WCFはより使いにくいということです。
WCFは企業向けに設計されており、RPCスタイルの通信が基本です。大量指向のRESTスタイルのデザイン・パターンも使えますが、これはそのシナリオのための****アイテムではありません。
WCFとOData
主な取り組みがCRUDスタイルのサービスレイヤーであり、WCFテクノロジースタックを使用したい場合は、WCFデータサービスサービスが良い選択です。これは、ASP.NET Web APIとODataクラスライブラリを共有し、多くの場合、Entity Framework使用されます。
Workflow
Workflow、Windows Workflowと WCF の組み合わせです。このオプションを使用する唯一の理由は、サービスがすでに内部的にWindows Workflowを使用していることです。
SignalRを用いた双方向通信
.NETベースのクライアントだけを使用したい場合は、WCFは優れた双方向通信のための多くのオプションを提供します。しかし、.NETとウェブベースのクライアントの両方をサポートする機能を求めるのであれば、非常に良い選択です。
マイクロソフト社の情報によると、SignalRは数百万ユーザーまで拡張可能です。ウェブクライアントはWebSockets好んで使用しますが、必要に応じて長いポーリングなどの古いパターンに自動的に戻ることができます。
SignalRには、Webクライアントとローカルクライアントがサービスを共有できる.NETクライアント用のクラスライブラリあります。
LightSwitch，もう1つのODataプロバイダー
マイクロソフトのODataに対する愛情は、とても誇張されていて、表現するのが難しいほどです。これまで、WCF と Web API の OData を見てきましたが、それだけでは終わりません。LightSwitch は通常クライアントとして使用されますが、サーバーサイドの機能を使用してサービスレイヤーを迅速に生成することが可能です。
マイクロソフトは、LightSwitchはコーディングを必要としないと主張していますが、柔軟性が失われることも警告しています。
中小企業向けアプリケーションガイド
マイクロソフトは、中小企業向けのガイドを作成する際、以下の目的に沿っています：
- 完成までのスピードの向上と市場投入までの時間の短縮
- 生産性の向上とコスト削減
- 導入が簡単
- 市販製品とのコラボレーションと統合
- クラウド・コンピューティングの柔軟性とコスト削減の機会
平たく言えば、「より速く、より安く」ということです。マイクロソフトは、あなたがどのようなプレゼンテーションモデルを好むかによって、この具体的なガイドラインを提示しています。
中小企業向けWebアプリケーション
高速でカジュアルな CRUD スタイルのアプリケーションでは、Microsoft が推奨する *** プラットフォームは LightSwitch のままです。多くの人は、LightSwitchをアクセスに代わる多層アプリケーションと見なしていました。しかし、そのビジョンは薄れ、マイクロソフトは現在、アプリケーションを迅速に提供する必要があるIT部門向けのツールとして使用しているようです。
次はWeb Formsです。Web Forms はデータフォームのような豊富な機能を備えており、社内向けアプリケーションとしては今でも十分に機能します。
ASP.NET Web Pagesについても簡単に触れています。Webフォームが提供するレンダリングパワーがまだあなたのニーズを満たさないと思うなら、ASP.NET MVCをお勧めします。
Windowsデスクトップアプリケーションの構築
WPFとWinFormsのどちらかを選択する際には、考慮すべきいくつかの要素があります：
まず第一に難しいです。WinFormsは上級開発者でもWPFよりはるかに理解しやすいです。WinFormsは非常に単純なデータバインディングを使用し、伝統的なMVCまたはMVVPメカニズムを好みます。WPFの場合、ユーザーはMVVPパターンを正しく使用できるように、複雑なデータバインディングフレームワークを学ぶ必要があります。WPFをうまく使うには、リソース辞書、コンバータ、ICommands、XAMLテンプレートエンジンの知識も必要です。
一方、Windows PhoneやWindows 8 Storeもターゲットにする場合は、XAMLの使い方を学ぶ必要があり、その場合はWPFから始めると、プラットフォーム間でコードを共有できる可能性が高くなります。
WPFの柔軟なレンダリングエンジンは、一般的なWinFormsアプリケーションに比べてはるかに美しい外観をレンダリングします。もちろん、これには代償が伴います。WPFアプリケーションは通常、同じ条件下でWinFormsアプリケーションよりも遅く動作します。
LightSwitchデスクトップクライアントについて参考までに。デスクトップクライアントで使えるものを提供しているようには見えないので、選ぶ理由はあまりなさそうです。
クライアント・サーバー・モードは避けるべき
Microsoftが "クライアントサーバー "について語るとき、彼らは実際にデータベースと直接通信するアプリケーションを指しています。これはまだ非常に一般的なパターンであることは認識していますが、新しいプロジェクトでは、クライアントとデータベースの間にサービス層を作成し、3層設計を使用することを望んでいます。これにより、データベースへの直接アクセスよりもスケーラビリティが向上し、ファイアウォールやその他の障害を回避する方法も提供されます。さらに、データベースドライバが利用できないプラットフォームへのアプリケーションの移植も可能になります。
「近代化」 - Windowsデスクトップの放棄
Microsoftは、デスクトップアプリケーションを「近代化」する方法について多くのアドバイスを提供しています。以下のアドバイスの多くは、アプリケーションを他のプラットフォームに移行するための準備に関するものですが、Windowsデスクトップを手放す予定がない場合でも、これらのガイドラインは役に立つでしょう。推奨事項を以下にまとめます：
- Model-View-Viewモデル設計パターンの使用：Microsoft Client Platformでは、MVVMパターンを使用してアプリケーションを簡単に構築できます。このパターンを使用すると、プレゼンテーションと状態や動作を分離し、デバイス間で簡単に共有できる、クリーンで保守性の高いコードを作成できます。
- ポータブル ライブラリを使用したクライアント側ロジック: .NET ポータブル ライブラリを使用すると、デスクトップ、Windows ストア アプリ、Windows Phone アプリなど、複数のプラットフォームでバイナリを共有できます。.NETポータブルクラスライブラリを使用してクライアントサイドロジックを実装すると、複数のプラットフォームでの複数のエクスペリエンスの作成が大幅に簡素化されます。
- ユーザーエクスペリエンスの向上：エンドユーザーが今日必要としているコンセプトは、デスクトッププラットフォーム***のための.NETのイノベーションを使用して実現できます。XAML設計におけるモダンUIの使用、アニメーションの慎重な使用、.NET非同期プログラミングの広範な実装を通じて、「高速で流動的」、「基本に忠実」、「2倍の労力」といった設計原則を既存のデスクトップアプリケーションに適用できます。.NET非同期プログラミングは、既存のデスクトップアプリケーションに適用できます。
- ビジネスロジックをサーバーに移す：2層アプリケーションは新しいデバイスに拡張するのが困難です。推奨されるアプローチは、ビジネスロジックを非常に明確なサービスに分離し、それらのサービスを他のデバイスで再利用することです。
- クラウドへのスケーリング：ビジネスロジックをクライアントから切り離したら、Windows Azureが提供する複数のソリューションの助けを借りて、クラウドに移行することができます。このロジックをクラウド・サービスに変換することで、既存のソリューションの弾力性と拡張性を大幅に向上させ、複数のデバイスを受け入れる準備が整います。
AndroidiOSプラットフォーム.NET
マイクロソフトは、多くのパートナーと協力し、ユーザーの近代化を支援しています。ここでは、各パートナーについて説明します：
- WinForms 、Windows、Windows Phone、iOS、AndroidデバイスをターゲットとしたアプリケーションでC#コードを共有できるクロスプラットフォーム開発ツールです。Xamarinを使用すると、デバイス間でクライアント側のロジックコードを再利用しながら、基盤となるAPIにアクセスし、カスタマイズされたビューを作成することができます。
- ITR-Mobility WPFMonoCrossは 、C#を使用して主要なモバイルプラットフォーム上で動作するエンタープライズモバイルアプリケーションを構築できるソリューションを提供します。抽象的なUIや企業データの同期などのサービスを提供し、複数のデバイスにまたがるビジネスプロセスを可能にします。
- Art in Soft社のXamarin、レガシーアプリケーションを最新のプラットフォームに移行するためのソリューションとサービスを提供しています。そのアプローチは、既存のソースコードをランタイムのない新しいコードに変換することです。
- for Windows Applications は、開発者に豊富なツールキットを提供し、LOB Windows アプリケーションの動員や、中央サーバーで実行し Citrix Receiver を使用して任意のモバイルデバイスからアクセスできるタッチフレンドリーなアプリケーションの新規作成を支援します。
余談：マイクロソフトがXamarinとMonoCrossを積極的にプッシュしているという事実は、マイクロソフトがMonoのメーカーを訴えるつもりだという噂を最終的に一掃するはずです。
大規模でビジネスクリティカルなアプリケーションへのガイド
大企業とそのビジネスクリティカルなアプリケーションにとって、もはや焦点はコストと生産性ではなく、複雑性の管理とサービス品質です。以下のガイドラインは、データ駆動型アプリケーションや CRUD スタイルのアプリケーションを対象としたものではありません。これらのガイドラインは、相互接続された部分が多く、独立したサブシステムが多数存在するシステムに適用されます。
エンタープライズWebアプリケーション
マイクロソフトのスタンスは明確で、重要なウェブサイトはASP.NET MVCを使うべきだと考えています。唯一のアーキテクチャ上の問題は、シングルページアプリケーションデザインパターンを使うかどうかです。
WebフォームやWebページなど、他のWeb技術の使用は推奨されません。MVCのような制御やテストができないため、利用できるサービスの質が制限されるからです。
エンタープライズ・デスクトップ・アプリケーション
このシナリオでは、C++と追加されています。マイクロソフトは、Microsoft Officeと比較できるような大規模で長期的なプロジェクトにはC++を推奨しています。ここでの前提は、AutoCADとPaint.NETは規模が違うということです。
エンタープライズWindowsストア/Windows Phone
このシナリオに対するマイクロソフトのアドバイスは、Emerging App Patternsのセクションで述べたものと似ていますが、それ以上のものではありません。このような態度はユーザーに大きな自信を与えるものではありませんが、プラットフォームを完全に放棄するものでもありません。
パターンとプラクティス
マイクロソフトはこのガイド***の中で、製品についての議論を続ける代わりに、パターンとプラクティスについて20ページほど費やしています。
コントロールの逆転
マイクロソフトはこのセクションで、ポートフォリオ・ルーティングを好むのか、サービス指向を好むのかを明確にしていません。そのため、ユーザーはこの2つについて混乱したままです。
境界のコンテキストと複雑性の管理
複雑さをコントロールするために、マイクロソフトは「バウンダリーコンテキスト」という概念について数ページを費やしています。Eric Evansによると、基本的な考え方は、アプリケーションをより小さな部分に分割し、その間の共有を制限することです。以下の例では、異なるバックエンドと共通のUIを使用する4つの別々のスタックがあります。
このセクションのMicrosoftのアドバイスは非常に理にかなっています。ミッションクリティカルと判断されたバウンダリコンテキストには、より高価なコマンドを使用し、クエリによる職務分掌やドメイン駆動型の設計パターンを使用し、完全に自動化されたテストを行うことができます。一方、補助的なバウンダリコンテキストでは、軽量のCRUDスタイルのアーキテクチャを使用できます。もちろん、レガシーコードは独自のリポジトリを持ち、そこで隔離され、徐々に置き換えられていきます。
コミュニケーションと保護
バインドされたコンテキスト間で情報を共有したい場合、Microsoftは可能な限り非同期メッセージの使用を推奨します。これにより、各部分が独立して動作するようになり、1つの部分に障害が発生しても、他の部分には影響しません。単純なシナリオでは、名前付きパイプとMicrosoftメッセージキューが簡単なオプションですが、より複雑なシステムではサービスバスが必要です。Microsoftは、Windows Server Service Bus、Windows Azure Service Bus、NServiceBusについて言及していますが、どれが好ましいかは述べていません。
バウンダリコンテキストによって公開されるすべてのサービスは、ガードレイヤーによって保護されるべきです。パラメータがパブリック関数を保護するためにチェックされなければならないように、境界コンテキストのためのガード層は、不正なメッセージから基礎となるデータストアを保存します。このレイヤーは受信メッセージを検証し、必要なすべての変換を実行し、不正なデータが処理され保存されることを保証します。しかし、頻繁に変更されるビジネスルールが多数ある複雑なシナリオでは、MicrosoftはBizTalkのようなルールエンジンと統合プラットフォームを使用することを推奨します。
レガシーコードへの対応
レガシーコードに対処するための****ステップは、レガシーコード用のアピアランスレイヤーを作成することです。このアピアランス・レイヤーは、永続的でスケーラブルなキャッシュのような最新のテクニックを使い、古いコードで使われていたパターンをすべて隠す必要があります。時間の経過とともにレガシーコードは置き換えられ、アピアランスレイヤーは新しいサービスレイヤーにリダイレクトされます。
結論
マイクロソフトは、ブラウザ側のSilverlightと.NET Remotingを除いて、すべての.NETネイティブ、ウェブ、コミュニケーションフレームワークの使用を推奨しています。また、シナリオによってはC++やJavaScriptも推奨しています。VB 6やレガシーASPのような古いプラットフォームについてはまったく言及されていないため、これらの技術をまだ使用している企業は、できるだけ早く新しいものに移行する必要があります。
- Cocos2d-xクロスプラットフォームゲーム開発入門基礎講座
- モバイルアプリケーションのためのUXデザイン 上級コース
- ゼロから学ぶiOS開発 - UIマルチビュー
