MicrosoftStackが依然として実行可能な選択肢である8つの理由

公開: 2022-03-11

10年前のMicrosoft開発者にとって人生は素晴らしかった。企業は、開発プロジェクトに100％マイクロソフトを採用することに満足していました。フロントエンドにASP.NET、バックエンドに.NET中間層、SQL Serverを使用すると、ほとんどの部分で非常にうまく機能しました。彼らがそうしなかったとき、開発者はそれを領土に付属するものとして受け入れました。マイクロソフトはほとんどショーを運営していた。その後、過去10年間の終わりに、マイクロソフトの800ポンドのゴリラの地位が明らかになり始めました。 iPhoneとMicrosoftの導入がモバイルへの移行を逃したためか、オープンソースプロジェクトの急増が原因だったのかもしれませんが、状況は変わりました。今日、これらの同じ企業は、MicrosoftStackを採用することを説得する必要があります。良い考えです。この記事では、Microsoftソフトウェアスタックを使い続けることに賛成する8つの理由を紹介します。

理由＃1：.NETは依然として最高の1つです

10年以上前に導入された.NETFrameworkは、機能が豊富で、徹底的にバトルテストされています。 .NETの初期の頃は、ネイティブ開発とマネージコードを組み合わせる必要がありましたが、今日では、開発タスクの大部分がすぐにサポートされています。 Oracleなどの企業でさえ、自社製品とのインターフェースをとるために100％.NETマネージコード（つまり、ODP.NETマネージドライバー）であるコンポーネントをリリースしました。 .NET APIは一貫性があり、十分に文書化されており、何百万人もの人々によって使用されています。

MSDN、StackOverflow、および何千ものフォーラムやブログから入手できるナレッジベースは膨大です。 .NETでの長年の開発では、フレームワークのバグで長い間立ち往生していた事例を思い出せません。毎回、誰かがすでに答えを経験し、調査し、投稿していました。必ずしも私が望んでいた答えではありませんでしたが、それでも私を前進させる何かがありました。今後の2015リリースでは、.NET Coreはオープンソースであり、Windows以外のシステムで利用できるようになります。

理由＃2：ASP.NETが進化した

10年前の従来のWebからデータベースへのMicrosoftスタックを振り返ると、どの部分が時間のテストを生き延び、どの部分が消えていくかを見るのは興味深いことです。 Microsoftスタックのバックエンドはほとんど変更されていませんが（依存性注入、タスク、Linq、EF、ADOなどの同じパターンとコンポーネントのセットを使用しています）、フロントエンドであるASP.NETの部分は「Microsoftのやり方でやる」（つまり、Webフォーム）から「自分のやり方でASP.NETをプラットフォームとして使用する」への根本的な移行。現在、ASP.NETはMVCベースのフレームワークであり、認証、バンドル、ルーティングのための堅牢なインフラストラクチャを備えており、BootstrapやAngularJSなどのMicrosoft以外の多くのテクノロジと統合されています。 ASP.NETサイトは、電話からデスクトップまで、さまざまなフォームファクターで見栄えがよく、そのWeb API機能により、Webサービスを簡単に公開できます。フレームワークは何年もの間オープンソースであるため、問題が発生した場合は、GitHubでソースを入手できます。 ASP.NETは変更され、より良い方向に変更されました。

理由＃3：WebAPIのシンプルさとWCFのパワー

私のこれまでのお気に入りの引用は、次のように述べたAlanKayからのものです。複雑なことが可能になるはずです。」 2006年にWindowsCommunicationFoundation（WCF）が最初にリリースされたとき、それは単純ではありませんでした。動作、エンドポイント、およびバインディングは圧倒的でした。そこで、MicrosoftはWeb APIをリリースしました。これは、HTTPWebサービスの公開を簡単にする使いやすいフレームワークです。数行の構成で、APIは安全な「業界標準」のWebサービスに変わります。

ユースケースが「標準」の型に適合せず、APIがネットワーク上でどのように公開されるかを完全に制御する必要がある場合は、いつでもWCFにフォールバックできます。 WCFを使用すると、無数の構成オプションとフックを使用して、データのカスタムシリアル化、ログ記録、インターセプト、メッセージのルーティング、ピアツーピアとキューイングの使用などを行うことができます。 Web APIは、WCFとともに、Kayの引用の両方の信条を提供します。単純なWebサービスが必要な場合は、WebAPIを数分で完了します。サービス要件が複雑な場合、WCFで「すべて」が可能です。これらの2つのテクノロジーは、サービスシナリオを包括的にカバーし、.NETFrameworkにあらかじめパッケージ化されています。

理由＃4：SQLServerはこれまでになく堅実です

何年もの間、新しい開発言語、フレームワーク、およびパターンの波がフロント層とミドル層を通過し、データベースのバックエンドを免れたように見えました。結局のところ、古き良き「SELECT」は、20年前と同じくらい今日でも使用されています。これは、多くの企業が自社のデータをビジネスのコアと見なしているためであり、そのコアの整合性を維持することは、データベース層で「何か新しいこと」を試みる興奮をはるかに上回っていると思います。

SQL Serverは、トランザクション、参照整合性、バックアップ、ミラーリング、レプリケーションの無数の機能を備えたデータキーパーの主要な役割に優れていますが、SQL Serverを競合他社と一線を画すのは、他のMicrosoftスタックとの統合性です。迅速な開発のために、現在バージョン6のEntity Frameworkがあり、思春期を過ぎ、データアクセスの合理化という約束を十分に果たしています。計算能力が必要な場合、.NETFrameworkはSQLServerとともにインプロセスで読み込まれます。つまり、パフォーマンスを犠牲にすることなく、.NETコードをストアドプロシージャ、関数、または集計として埋め込むことができます。これをSQLServer2014にインメモリテーブルが付属しているという事実と組み合わせると、SQLと通常のテーブルだけでは十分に高速化できなかった非常に洗練されたリアルタイムソリューションを思い付くことができます。業界で何年も働いた後も、SQLServerはまだ私のRDBMSのリストの一番上にあります。

理由＃5：簡単にテスト可能

多くの場合、企業のIT部門で働いていたとき、テストがなかったためにソフトウェアがこれらの手に負えないブラックボックスに変わるのを目にしました。また、「何かを壊す」ことを恐れてコードをいじりたくなかったのです。それから、何千ものテストが行われたシステムに取り組みましたが、ソフトウェアがリリースされてから何年も経って、「はい、これらの変更を加えることができます」とビジネスに伝えることができたのは素晴らしい気分でした。 Microsoftスタックは、テスト容易性を念頭に置いて設計されています。 ASP.NET MVCには依存性注入用のフックがあり、バージョン5では、依存性注入がフレームワーク自体に含まれるようになります。中間層でも同様の話です。依存性注入を使用して、実装とインターフェースの関連付けを解除します。これにより、テスト時に本番タイプをモックと交換できます。データベース側でも、ストアドプロシージャレイヤーに対してテストするためのテンプレートが付属するSQLServerデータツールがあります。テストは今日のソフトウェア開発プロセスの不可分の一部であり、Microsoftスタックはこの新しい現実に十分に対応しています。

理由＃6：精巧なサポートエコシステム

サポートに関しては、コミュニティフォーラムから始まり、サーバーのオンサイトで実際に作業している人間で終わるまで、さまざまなオプションがあると便利です。マイクロソフト製品のオンラインエコシステムは、業界で最大のエコシステムの1つです。結局のところ、Microsoftは、ソフトウェア開発者自身であるBill Gatesによって始められました。彼は、開発者による幅広い採用をMicrosoft製品の普及の鍵と見なしていました。これは、これらの開発者に多くのサポートを提供することを意味しました。

マイクロソフトは、従業員が取り組んでいるテクノロジについてブログを書くことを最初に奨励しました。業界の他の部分は確かに追いついてきましたが、今日のマイクロソフトから直接提供される教育用ビデオ、ガイド、記事の量と質は依然として維持されています。非常に印象的。その高品質のオンラインコンテンツのレイヤーは、StackOverflowなどの多数のコミュニティベースのサポートエコシステムによって補完されます。これらのエコシステムは、コンテンツの品質に関しては一貫性がありませんが、それでも、そうでない場合よりもはるかに役立ちます。

最後に、電話を取り、Microsoftサポートに電話するオプションが常にあります。私はめったにそれを使用する必要はありませんでしたが、Microsoftの開発者にコアダンプを分析させると、その日を節約するために、いくつかの本番環境の緊急事態が発生しました。サポートオプションの範囲は、明らかにMicrosoftスタックを採用するための要因です。

理由＃7：マイクロソフトは自社製品にこだわる

数年前、アプリケーションのフロントエンドとしてMicrosoft Silverlightを選択することは有効な選択のように思われましたが、もはやそうではありません。本格的なモバイルトレンドとフロントエンドスペースを支配するJavaScriptフレームワークにより、Silverlightはもはや実現可能なオプションではありません。それでもなお、2021年までマイクロソフトによってサポートされています。マイクロソフトはその銃に固執しています。これは、将来のソフトウェアの展望を支配するテクノロジーのトレンドを教えてくれる魔法のエイトボールを持たずにテクノロジーを選択しなければならない私たちにとっては良いことです。 Microsoftスタックを使用することで、業界で支持されなくなった場合でもサポートされるテクノロジに時間とお金を投資できます。

理由＃8：Visual Studio Umbrella

10年前、私は自分の時間の約50％をVisual Studioで、約50％を他のツールで過ごしていました。今日、分割は圧倒的にVisualStudioを支持しています。 Visual StudioがIDEをホストするためのワンストップソリューションであるというMicrosoftのビジョンは、VisualStudioとのある程度の統合を提供する多くのMicrosoftおよびMicrosoft以外の製品で実現しつつあります。 SQL Serverデータツールを使用したデータベース開発から、Xamarinを使用したiPadおよびAndroidアプリの作成まで、Visual Studioは、一貫したユーザーインターフェイスを備えた使い慣れた開発者エクスペリエンスを提供します。データベースホスティングからモバイルサービスまで、さまざまなサービスを網羅するクラウドプラットフォームであるMicrosoftAzureの操作についても同じことが言えます。

Visual Studioは、分散型クラウドインフラストラクチャの複雑さを難読化し、クラウドアプリケーションの開発エクスペリエンスを、クラウドでホストされていないアプリケーションの開発エクスペリエンスと一致させました。すべての要素がVisualStudioの傘下でうまく調和しているように見え、開発プロセス全体が非常に効率的になります。

MicrosoftStack-両方の長所

今日、10年前と比較して、高品質のソフトウェアを作成するための選択肢ははるかに多くなっています。グーグル、アップル、アマゾン、マイクロソフトなどの大手企業は、競争によって革新を続け、自己満足しないように強制されるため、これは確かに良いことです。マイクロソフトは過去10年間の技術の進化によって山の頂上から押し出されてきましたが、同社は現在の技術動向の現実に順応し、順応していることを示しています。 ASP.NETは他のテクノロジと方法論を採用しており、それらの多くはオープンソースであり、元のWebフォームは歴史に溶け込んでいます。 .NET Frameworkは進化を続けており、マルチスレッドおよびメニーコアコンピューティング用のライブラリで新しいフロンティアを打ち破っています。差し迫った2015年のリリースでは、フレームワークのコアはオープンソースであり、Windows以外のプラットフォームに移植可能になります。これは、包括性と透明性の方向への一歩です。

これらの歓迎された改善は、テストされ、文書化され、サポートされているソフトウェアをリリースするための長年のプロセスを持っている会社から来ています。 Microsoftスタックを使用すると、最新の言語とフレームワークを使用する興奮に加えて、開発業界で数十年の経験を持つソフトウェアの巨人に支えられた安定性がもたらされます。これが、今日Microsoftスタックを推奨している理由です。