更新履歴
- 2020/03/23
- IoT について追記
- その他に帝国兵さんのツイートを追加
- サーバーレスカテゴリーを追加して AWS Lambda を追加
- ASP.NET Core Razor Pages を追記
- 2020/03/24
- kennakamu さんの「個人的に C# が向かないと思うこと」へのリンク追加
本文
昔ブログにこんな記事を書きました。
あれから 2 年が経って昔からある Windows 専用の .NET Framework に対する新機能の提供が終わり、クロスプラットフォームに対応した .NET Core が今後のメインストリームとして .NET 5 → .NET 6 のように進化していくことが 2019 年 5 月の Build 2019 で発表されました。以下の Blog 記事がアナウンス後に発表されています。
ということで情勢が変わったので、ここらへんで一度まとめなおしてみようと思います。
そもそも C# とは
2002 年に .NET Framework 1.0 上で開発するための言語として登場。最初見た感想は「命名規約が Java はメソッド名は小文字始まりだけど大文字始まりになってる言語なんだな」でした。
言語仕様的にはプロパティが言語仕様に組み込まれている、デリゲートという今では、ほぼ全ての言語でできるメソッドを変数に代入するための型があって、それをつかってイベントという仕組みも言語仕様に組み込まれてる違いがありましたが、当時の自分はマイクロソフトが作った Java と認識してました。
その後主な機能だけ列挙すると：
- 2005 年に C# 2.0 でジェネリクス/Nullable 型
- 2007 年に C# 3.0 で LINQ
- 2010 年に C# 4.0 で動的型付け
- 2012 年に C# 5.0 で非同期処理（async/await) (8 年も前から async/await 使えてたの凄い）
- 2015 年に C# 6.0 で null 条件演算子
- 2017 年に C# 7.0 でタプルや型スイッチ
- 2019 年に C# 8.0 で null 許容参照型や switch 式、パターンマッチ系
のように、進化してきて、最初に抱いていた Java クローンという印象はすっかり消えて、自分の中で最高に書きやすい言語になりました。細かい所では TypeScript とか Dart とか、Kotlin とか見てうらやましいなぁと思う言語仕様もあるけれど、これから書く守備範囲の広さと合わせて、しばらくは C# メインでやっていこうと思える感じになってます。
ちなみに、あくまで私個人の認識なので、知識に偏りはあるし、もしかしたら間違った認識をしているものもあるかもしれないので、そういうものはバンバン編集リクエストなりコメントで指摘ください m(_ _)m
コンソールアプリケーション開発
やっぱり、余分な技術的な要素を排除しつつ、やりたいことだけを検証するときとかはコンソールアプリケーションが最強ですよね。.NET Core は、グローバルツールというのがあって dotnet tool install -g dotnetsay のようなコマンドでツールをインストールして、インストール後は CLI からパチパチと叩けたりします。npm とかでやってたようなことが C# でも出来るようになってます。.NET Framework も、もちろんコンソールアプリはいけますね。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| .NET Core | これでやってれば、とりあえず良さそう | .NET Core ツールの管理方法 |
| .NET Framework | .NET Framework にしか対応してないものがあるならこっちでも |
ここから先の全てに言えることですけど、.NET Framework を検討無しで新規開発に選ぶのは辞めた方がいいと思います。.NET Core でもいけるものなら、今後も新機能追加が行われる .NET Core 系を選ぶほうが個人的にはお勧めです。
塩漬けこそ正義の環境なら .NET Framework もいいかもしれないですが
Web アプリケーション開発
Web アプリは ASP.NET Core/ASP.NET あたりを使えば出来ますね！
今から始めるなら、過去のしがらみとかが無い限りは .NET Core 3.1 で ASP.NET Core MVC とかあたりで作り始めることになると思います。
.NET Core で作っておくと、今後のメインストリームの .NET 5, .NET 6... の流れに乗れるので間違いないです。Windows でも Linux でも動くしね。Azure でも AWS でも GCP でも、何処でもデプロイ可能だし、Visual Studio 2019 を使って最高の環境で開発出来るし、Visual Studio Code で手に馴染んだエディター上でもコード補完などが効いた状態で開発もできて、実際にクラウドへのデプロイも、そこから可能でお手軽に始められる。CI/CD パイプライン組んで自動デプロイとかも楽しい。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| ASP.NET Core MVC | 第一候補。これでいけるなら行くべきだと思う | ASP.NET Core MVC の概要 |
| ASP.NET Core Razor Pages | View(cshtml) の書き方は、MVCと同じだが、Viewに対するアクションをコントローラーではなく、cshtmlと1対1に対応した ページクラス(cshtml.cs) に定義していくスタイル。MVC がコントローラーへのアクションが起点なのに対して、こちらはページを起点に考えて作っていくスタイルなので、コントローラーをどう分割するかという問題から解放される。DI などの機能も使えるので、結構良さそう。SPA じゃない Web ページが主体のアプリだと ASP.NET Core MVC よりも作りやすい雰囲気を感じる（自分は、これでしっかり作りこんだことはない） | ASP.NET Core での Razor ページの概要 |
| ASP.NET MVC | .NET Framework に縛られるなら、これを使ってなるべく ASP.NET MVC への依存を低く作っておくのが良さそう | ASP.NET MVC 5 の概要 |
| ASP.NET WebForms | 過去の資産がない限りは採用する理由は、あまりないと思う。 ノンコーディングで DB からデータ取ってきて表形式で表示できるとかの強みが活かせるなら強いかもしれないけど、そういう用途なら PowerApps 系とかそっちのほうが今では良さそうに思う。 |
ASP.NET Web Forms |
その他にも Blazor サーバーというものもあって、SPA みたいなのを作れるけどブラウザは HTML/CSS でレンダリングしてるだけで、実態は WebSocket とかでサーバーに繋いでいてボタンを押したときの処理やらステートやらは全部サーバーでもってるというのもあります。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Blazor サーバー | 1,000 人クライアントがいたら 1,000 人ぶんのデータをサーバーのメモリ上に持つので、大規模な B2C とかに使うのは、個人的にはちょっと不安がある（検証はしたことないです）。社内アプリとかでは、C# でロジックとかが書けるので幸せになれるかもしれないと思ってる。 | ASP.NET Core Blazor の概要 |
Web API 開発
これも Web アプリケーション開発とほぼ同じです。.NET Core 系が今後のメイン。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| ASP.NET Core | これが一番機能充実してそう | ASP.NET Core を使って Web API を作成する |
| ASP.NET WebAPI | .NET Framework ならこっち | ASP.NET Web API 2 (C#) を使ってみる |
Web API を作るという観点では、共通の前処理を仕込んだりとか便利機能が豊富な ASP.NET Core が一番開発効率は高いような気がしてますが、サーバーレスプラットフォームの Azure Functions の Http trigger を使っても Web API は作れます。HTTP で受けてメッセージキューにメッセージ投げて、その裏でごにょごにょやるようなアプリとかの場合は、Web API 部分も後述する Azure Functions で作ってもいいと思います。
サーバーレスプラットフォーム上での開発
C# でサーバーレスプラットフォーム上での開発も出来ます。Azure Functions は当然ネイティブで対応しています。C# 以外の言語は、Azure Functions のランタイムとは独立したプロセスとして起動していて、gRPC でプロセス間通信しているのですが、C# のほうはランタイムに組み込まれてるので、C# が書けるなら C# で書いたら何か安心感があります。AWS Lambda も、C# に早くから対応していて .NET Core が発表されて暫くして「AWS Lambda が C# をサポート」のニュースとともにサポートされたことにびっくりしたのを覚えています。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Azure Functions | Azure のサーバーレスサービスの代名詞的な Azure Functions で動かしたいならこれ。 | Azure Functions の概要 |
| AWS Lambda | AWS のサーバーレスの代名詞的な AWS Lambda で動かしたいならこれ。 | C# による Lambda 関数のビルド |
Web フロントエンド
最近は C# でも Web フロントエンドいけるんですねぇ。JavaScript 系フレームワークの方が実績もあるし、やってる人も多いので、それはそれで正義なのですが C# が好きなチームとかでは、ここら辺のも候補に入るかもしれない。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Blazor WebAssembly | 正式リリースされてないけど、WebAssembly 対応のが正式版としてリリースされたら、恐らく最強。 WebAssembly 系の奴ら全般にあることだろうけど、初回起動時の遅さが懸念事項。 |
ASP.NET Core Blazor の概要 |
| Uno Platform | これは UWP アプリのコードをビルドしてクロスプラットフォームで動くようにするコンセプトのプラットフォームです。WebAssembly にも対応しています。MS 製品ではありませんが、MS ともコミュニケーションをとってやってるようです。GitHub のページのコントリビューターに Microsoft アイコンがあるので。 2020年3月時点では、安定した盤石なプラットフォームだと思って触らないのが吉です。面白いプラットフォームではありますが、日進月歩でバグフィックス、新機能実装が行われています。 |
What is the Uno Platform? |
モバイルアプリケーション開発
Android や iOS といったモバイル OS 用のアプリ開発です。何も考えずに C# でやりたいなら Xamarin を選ぶといいでしょう。次点で Web フロントエンドでも紹介した Uno Platform です。ワンチャン Unity。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Xamarin ネイティブ | Android/iOS の API を、ほぼそのまま全て C# でラップしてあるので、いざとなったら Android/iOS のネイティブアプリ開発向け情報を参考に C# に翻訳して開発もできるし、Xamarin のドキュメントにも結構色々書いてある。 各プラットフォームで出来ることは、多分ほぼ全て出来る上に基本的に全て C# で書けます。Java, Kotlin, Swift, Objective-C を書かないといけないシーンは、他のクロスプラットフォーム系の製品に比べて極端に少ないと思います。それこそ、既存の自社製 or OSS のネイティブ向けライブラリーを Xamarin から使いたい時とかに見るくらいだと思います。 最近は、Uno Platform や Mobile Blazor Bindings の Android/iOS 対応は Xamarin 上で動くようになっているので、安心感があります。 |
Xamarin とは |
| Xamarin.Forms | Xamarin ネイティブとまとめて紹介しようか悩んだけどわけました。Xamarin ネイティブの上に各プラットフォーム共通の UI コントロールや API 群を提供しています。うまいことやればワンソースで Android/iOS/UWP に対応できます。うまいことやればね。現実は Xamarin.Forms の API や .NET Standard の API では出来ないことをしたいこともあるので、その時は Xamarin ネイティブの方に頼って各 OS ネイティブの API を叩くコードをプラットフォーム毎に書かないといけません。その場合でも C# で書けるのは個人的には神。XAML と呼ばれる Windows アプリ開発者にはなじみ深い XML ベースの言語で画面を作れるのも〇。でも、最近は Flutter などの影響なのかは知らないけど C# で UI を組めるようにする CSharpForMarkup というのも出てきているので、そっちはそっちで楽しみ。 | Xamarin.Forms とは |
| Uno Platform | UWP アプリのソースを Android/iOS/WebAssembly/macOS 向けアプリとしてビルド出来るようにしようという、とても野心的なプラットフォームです。OSS で開発されています。まだこなれてないけど、そのぶん進化が早くて追いかけるのが楽しいです。 | What is the Uno Platform? |
| Mobile Blazor Bindings | これは、完全に名前しか知らないけど Blazor で開発したものがモバイルでも動くんだって。しかも基盤は Xamarin らしい。まだ実験段階なので、こういうのがあるんだな～という位には知っておけばいいと思います。もちろん興味がある人は触ってみよう！ | Announcing Experimental Mobile Blazor Bindings |
| Unity | ゲーム開発用途が主ですが、AR 系アプリとか、ワンチャン画面アプリとかもいけるかも。個人的にはモバイル用の普通の画面を作るならUIWidgetsを使うと Flutter と同じノリで画面が作れるのでお勧め。 | Unity |
Windows アプリケーション開発
デスクトップ アプリですね。Windows 7 のサポートも終わり、Windows 8.1 を使っている人が少なめとうことで、運がいいと最近は Windows 10 のみをターゲットとして開発できるようになってきました。UWP or WPF |超えられない壁| WinForms の順番でお勧めかなぁ。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| UWP | Windows 10 が出たときに出てきたプラットフォーム。昔は、これに非ずんば Windows 10 アプリに非ず。とも受け取れるくらいごり押しをしてきたけど、最近は落ち着いて他のプラットフォームでもデスクトップアプリ開発してもらって大丈夫みたいなメッセージを感じる。 一番セキュアな環境で動かせるので、ユーザーとしてはメリットが大きいのですが、開発者目線では、昔は出来たあれが出来ないとか、別の方法を使わないといけない、使う機能を事前に示的に宣言しないといけない、配布するには証明書が必要（オレオレでもいいけど、その場合はユーザーにオレオレ証明書を入れてもらわないといけない）という点で不自由を感じる。 でも、一番今のところ今風の UI を作りやすいプラットフォーム。私は好き。ユーザーの意図に反する動きが作りにくいように出来てるので、例えばユーザーがウィンドウを最小化しようとしたら止めることは出来ないし、ユーザーが閉じようとしたら基本的には閉じられる。個人的にはあるべき姿だと思うけど、業務アプリでユーザーが間違ったことしようとしても力ずくで止めるようなものを実装するのがシンドイ。 一部新機能の API は、UWP からしか呼べないものもある。 |
ユニバーサル Windows プラットフォーム (UWP) アプリとは |
| WPF on .NET Core | .NET Core 3.0 以降で WPF がサポートされた。実行速度も早い、自由度も高い、配布形式も柔軟に選べる（従来通りの方法もいけるし、MSIX にパッケージングして UWP っぽい感じに配布も出来る）。最近は Windows 10 向け API も NuGet パッケージ追加するだけでサポートされているものは呼べるようになったり、UI コントロールも XAML Islands などを使って UWP の UI コントロールのホストも可能。個人的には一番バランスが取れてるところにいるのではないかと思う |
Windows Presentation Foundation (WPF) documentation Migrating WPF apps to .NET Core が .NET Framework の WPF から .NET Core の WPF へのマイグレーションのドキュメント |
| WPF on .NET Framework | 基盤が .NET Framework であることを除くと WPF on .NET Core と同じ。.NET 6 くらいの時代になると、段々と使えない新機能が出てきだすのではないかと個人的には思ってる。 | 概要 (WPF) |
| Windows Forms on .NET Core & Windows Forms on .NET Framework |
めんどくさいので纏めた。古き良き世代の .NET での Windows アプリ開発のフレームワーク。正直、高 DPI とか Per monitor DPI とか、今風のレイアウトのリストとか出そうとすると労力が高くなるので辛い。Windows Forms で提供されているコントロールとサードパーティー製コントロール内で収まるように設計して作れば普通に使えるとは思うけど、新規では Windows Forms 以外を選ぼう。 | Windows フォーム |
macOS 向けアプリケーション開発
Xamarin.Mac でいけるらしい。実際に freee さんで実績があるけど、自分は macOS がメインじゃないので触ったことがない。でも、C# で作れちゃうの凄い。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Xamarin.Mac | よく知らない | Xamarin.Mac の概要 |
機械学習系
ML.NET で行ける。これも触り程度しか使ったことがないのでコメントできるほど知らないけど、こういうのがあるよっていうのは知っておいて、いざというときに覗いてみよう。もし機械学習をやることになったら ML.NET で勉強すると Python の学習と機械学習系の勉強の二重苦にならずに、C# は知ってるので機械学習系の勉強にフォーカス出来る。
もし、Python 系のでやらないといけなくなったら、ML.NET で軽く雰囲気掴んでから Python 系のほうを触ってみるというラーニングパスもありかもしれない。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| ML.NET | よく知らない | ML.NET のドキュメント |
ゲーム開発 & MR(VR/AR) 開発
Unity 一強の世界ですなぁ。（開発言語を C# に絞らなければ、他もありますけど）
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Unity | 昔 DirectX の本をみたときは、本で数ページに渡るコードを書いて実行した結果がティーポッドが出るだけ、みたいな世界だったんですが、今ではポトペタと、Behaviour を作って GameObject にアタッチして動作をカスタムできるという、とっても簡単に作れるような世界になってるので最初に触った時は感動しました。 でも、UI を作ろうとすると、個人的には辛い…、あと Unity と利用ライブラリー間のバージョン合わせチャレンジが辛い点が解消される未来が来たら、より幸福度が上がりそうだと思ってます。 |
Unity |
IoT 開発
Azure IoT Edge で C# を使った開発が出来ます。（瀬尾さんに教えてもらいました！）
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| Azure IoT Edge | Azure IoT Edge のモジュール開発に C# が使えます。Docker イメージにして展開する形になります。私は、やったことないのですが、Docker 強いですね。 さらに、パブリックプレビューだけど Azure Functions が動くのも凄い |
Azure IoT Edge とは |
その他
何に入れていいか迷ったので、その他をここに。
| プラットフォーム/フレームワーク | コメント | ドキュメント |
|---|---|---|
| gRPC サーバー/クライアント | .NET Core 3.0 から gRPC がサポートされています。マイクロサービスのサービス間を gRPC で繋いでとかいうのもよく聞く話なので、そこにも C# を仲間に入れてやってください。.NET Framework でも前からライブラリー使えば出来たけど、ASP.NET Core に含まれたのが大きいです。.NET Framework の WCF の移行先としても案内されています。 | チュートリアル: ASP.NET Core で gRPC のクライアントとサーバーを作成する |
| マイクロサービス | 旬ですよね。Azure アーキテクチャーセンターにドキュメントも上がってます。なんとなく、この記事に書くような粒度の話じゃないと思ったのですが、その他カテゴリーを後で追加したので、備忘録的に書いておきます。 | .NET マイクロサービス: コンテナー化された .NET アプリケーションのアーキテクチャ |
| Azure App Service の開発 | Microsoft Azure の App Service の製品チームの帝国兵さんから App Service も、ほとんど C# で作ってるとコメント貰いました。 |
|
C# が向かないこと
この記事を受けて kennakamu さんが以下の記事を書いてくれました。個人的に同意です。
因みに、この記事にポジショントークというはてぶコメントが付きましたが Android アプリの開発がしたいんです！っていう人に Xamarin にいきなり勧めたり、機械学習の勉強したいんです！っていう無垢な人に ML.NET を勧めようという意図で書いてる記事ではないということを書いておきます。
例えば Android ネイティブアプリ開発したいなら Kotlin、iOS アプリ開発したいなら Swift、そうじゃなくて Xamarin を選ぶなら C# のノウハウがあるとか、C# で開発している資産の再利用だとか、マルチプラットフォーム対応したいとかっていう理由が無いなら、ただ辛いだけな気がするので…。C# Love なら Xamarin 一択。
まとめ
C# は、相変わらず色々なことが出来て言語的にも他の最新言語と比較して遜色ない状態をキープし続けてくれてる素敵な言語だなぁと思いました。
システムを作る上で、システム内の○○はXX言語、△△はYY言語のような複数言語が乱立するよりも 1 つの言語で統一できるといいなぁと思ってる人には C# は結構いい選択なのではと思ってます。
マイクロサービスの文脈では、各々のチームが一番適してると思った言語で開発すればいいという流れもありますがケースバイケース？
C# に興味を持った人は、以下のちょまどさんのツイートから行ける Microsoft Learn のラーニングパスもみてみてください。
無料オンライン学習サービス「Microsoft Learn」の
— ちょまど🎀ITエンジニア兼マンガ家 (@chomado) March 24, 2020
「C# の最初のステップ」コースがあるね！
ハローワールドからhttps://t.co/e5ubswDSsi