「C Sharpの基礎 - Blazorデスクトップ」の版間の差分
| (同じ利用者による、間の5版が非表示) | |||
| 1行目: | 1行目: | ||
| == 概要 == | == 概要 == | ||
| Photino.Blazorは、.NET開発者にとって有益なデスクトップアプリケーション開発プラットフォームである。<br> | |||
| このフレームワークの基本的な特徴として、OSネイティブのWebViewを使用して、Blazorの強力な機能をデスクトップアプリケーションに適用できる。<br> | |||
| 従来のElectronと比較して、はるかに軽量なアプリケーションを開発することができる。<br> | |||
| <br> | |||
| 開発環境のセットアップにおいて、Rider / Visual Studio等を使用して開発を進めることができる。<br> | |||
| 開発者は主に、C#とRazor構文を使用してアプリケーションを構築する。<br> | |||
| これにより、WebフォームやWPFの経験がある.NET開発者にとって、学習曲線を緩やかにすることができる。<br> | |||
| <br> | |||
| アプリケーションのアーキテクチャに関して、Photino.Blazorは単一のプロセスモデルを採用しており、UIレイヤーとビジネスロジックが密接に統合されている。<br> | |||
| 状態管理やデータバインディング等のBlazorの優れた機能をそのまま活用することができる。<br> | |||
| <br> | |||
| Photino.Blazorは標準的なデスクトップアプリケーションのセキュリティモデルに従う。<br> | |||
| 例えば、ファイルシステムへのアクセスやネットワーク通信は、.NETのセキュリティ機能によって制御される。<br> | |||
| <br> | |||
| Photino.Blazorのパフォーマンスにおいて、メモリ使用量はElectronベースのアプリケーションと比較して大幅に少なく、起動時間も短縮されている。<br> | |||
| これは、ネイティブのWebViewを使用しているため、余分なランタイムを含まないからである。<br> | |||
| <br> | |||
| Windows、MacOS、Linuxで動作するデスクトップアプリケーションをほぼ同一のコードベースで開発することが可能である。<br> | |||
| プラットフォーム固有の機能へのアクセスも、.NETの標準APIを通じて実現可能である。<br> | |||
| <br> | |||
| デプロイメント手順も簡便であり、アプリケーションは単一の実行可能ファイルとして配布可能で、必要なランタイムコンポーネントも含めることができる。<br> | |||
| そのため、自己完結型の配布パッケージを作成することが可能である。<br> | |||
| <br> | |||
| .NETコミュニティの一部として、多くのリソースやライブラリが利用可能である。<br> | |||
| また、既存の.NETライブラリとの互換性も高く、既存のコードベースの再利用も容易である。<br> | |||
| <br><br> | |||
| == オールインワンアプローチ == | |||
| Photino.BlazorやElectronでは、デスクトップアプリケーションのフレームワークとして、フロントエンドとバックエンドのコードを1つのパッケージにまとめる<u>"オールインワンアプローチ"</u>を取っている。<br> | |||
| <br> | |||
| Photino.Blazorの場合<br> | |||
| * .NET/Blazorのコードがバックエンド相当の処理を担当 | |||
| * 軽量なネイティブWebViewをフロントエンドとして使用 | |||
| * BlazorのWebAssemblyとC#コードが統合された形で動作 | |||
| * やはり1つのパッケージとしてビルド・配布される | |||
| <br> | |||
| Electronの場合<br> | |||
| * Node.jsをバックエンドとして使用して、Chromiumブラウザをフロントエンドとして使用する。 | |||
| * メインプロセス (Node.js) とレンダラプロセス (Chromium) が存在する。 | |||
| * 両者はIPCを通じて通信する。 | |||
| * 全てのコードは1つのアプリケーションパッケージとして配布する。 | |||
| <br> | |||
| ==== オールインワンアプローチのメリット ==== | |||
| * 開発とデプロイメントが簡単である。 | |||
| * フロントエンドとバックエンドの連携が取りやすい。 | |||
| * オフライン動作が容易となる。 | |||
| <br> | |||
| ==== オールインワンアプローチのデメリット ==== | |||
| * アプリケーションサイズが大きくなる。 | |||
| * リソース消費が比較的多い。(特に、Electronの場合) | |||
| * スケーラビリティに制限がある。 | |||
| <br><br> | <br><br> | ||
| 34行目: | 85行目: | ||
| 以前のBlazorは、WinForms / WPFのWebView2を使用したWASMとWindowsのみであった。<br> | 以前のBlazorは、WinForms / WPFのWebView2を使用したWASMとWindowsのみであった。<br> | ||
| 現在では、Maui Blazor Hybridがある。<br> | 現在では、Maui Blazor Hybridがある。<br> | ||
| <br><br> | <br><br> | ||
| 79行目: | 108行目: | ||
| <br><br> | <br><br> | ||
| ==  | == WebView2 / WASMの違い == | ||
| WebView2とWASM (WebAssembly) は異なる技術である。<br> | |||
| <br> | |||
| ただし、これらの技術は組み合わせて使用することも可能である。<br> | |||
| * WebView2内でWASMを実行するWebアプリケーションを表示する。 | |||
| * BlazorアプリケーションをWebView2でホストする。 | |||
| <br> | |||
| これらの技術は異なる目的と用途を持っていますが、相互に補完し合うことができる。<br> | |||
| <br> | |||
| Photinoは各プラットフォームごとに以下に示すWebViewエンジンを使用している。<br> | |||
| * Windows | |||
| *: WebView2 (Chromiumベース) | |||
| * MacOS | |||
| *: WKWebView (WebKitベース) | |||
| * Linux | |||
| *: WebKitGTK | |||
| <br> | |||
| これにより、各プラットフォームのネイティブなWebViewコンポーネントを活用しながら、クロスプラットフォームな開発が可能になっている。<br> | |||
| <br> | |||
| ==== WebView2 ==== | |||
| WebView2はMicrosoftが開発したブラウザコンポーネントである。<br> | |||
| Windowsプラットフォーム向けのコンポーネントであるため、その他のプラットフォームでは使用されていない。<br> | |||
| <br> | |||
| Chromiumベースのエンジンを使用して、デスクトップアプリケーション内でWebコンテンツを表示することが可能である。<br> | |||
| .NET/C#アプリケーションにWebベースのUIを統合する場合に使用される。<br> | |||
| <br> | |||
| ==== WebKitGTK ==== | |||
| Linux上のPhotino Blazorは、現在GTK3ベースのGTKをバックエンドとして使用しており、WebKitGTKを使用してWebViewをレンダリングする。<br> | |||
| これは、PhotoinoのGithubリポジトリのソースコードで確認することができる。<br> | |||
| <br> | |||
| 以下に示す理由から、GTK4への移行は行われていない。<br> | |||
| * 依然として、GTK3は広く使用されており安定している。 | |||
| * 多くのLinuxディストリビューションでGTK3は標準でインストールされている。 | |||
| * GTK4への移行には、APIの変更への対応等、多くの作業が必要になる。 | |||
| <br> | |||
| ==== WKWebView ==== | |||
| MacOS上でのPhotino Blazorは、WKWebViewを使用している。<br> | |||
| <br> | |||
| ==== WASM (WebAssembly) ==== | |||
| Webブラウザで動作する低レベルのバイナリフォーマットである。<br> | |||
| <br> | |||
| C++やRust等の言語で記述されたソースコードを、Webブラウザで実行可能な形式にコンパイルする。<br> | |||
| Blazor等のフレームワークを通じて、C#コードをWebブラウザで実行することができる。<br> | |||
| <br><br> | |||
| == Bootstrap == | |||
| Bootstrapを使用することにより、簡単にCSSを記述することができる。<br> | Bootstrapを使用することにより、簡単にCSSを記述することができる。<br> | ||
| テーマを実装する場合、BootswatchがBootstrap向けの26のテーマを提供している。<br> | テーマを実装する場合、BootswatchがBootstrap向けの26のテーマを提供している。<br> | ||
| 134行目: | 208行目: | ||
| 全てのリソースが含まれているため、アプリケーションのサイズが約2[MB]大きくなる。<br> | 全てのリソースが含まれているため、アプリケーションのサイズが約2[MB]大きくなる。<br> | ||
| <br><br> | <br><br> | ||
| == ディレクトリ構成 == | |||
| ==== Blazorプロジェクトの構造と分割パターン ==== | |||
| * 共有ライブラリ | |||
| * コアクラス | |||
| *: コアクラスを保持する<code><Project Sdk="Microsoft.NET.Sdk"></code>型の<code>OpenHabitTracker</code> | |||
| * Razoorファイル | |||
| *: Razoorファイルを保持する<code><Project Sdk="Microsoft.NET.Sdk.Razor"></code>型の<code>OpenHabitTracker.Blazor</code> | |||
| <br> | |||
| 以下に示すように分割することにより、ロジックはUIから分離されて、Razorファイルには数行のC#コードが含まれるようになる。<br> | |||
| C#のソースコードを.razor.csファイル (コードビハインドファイル) に記述するとエディタの動作が改善される。<br> | |||
| <br> | |||
| また、C#のソースコードを別のライブラリに記述することもできる。<br> | |||
| <br> | |||
| Razorコンポーネント / Razorページのみを共有ライブラリに配置して、<br> | |||
| App.razor、_Imports.razor、MainLayout.razor、JsInterop.cs、jsInterop.js、app.cssは共有ライブラリに移動しない。<br> | |||
| <br> | |||
| .csとindex.htmlを除く全てのファイルを共有ライブラリに移動することができる。<br> | |||
| プラットフォーム固有の動作がある場合は、C#インターフェースで解決することができる。<br> | |||
| <br> | |||
| 全ての.cssと.jsファイルは共有ライブラリに格納することができ、<br> | |||
| index.htmlの_content/OpenHabitTracker.Blazor/...のように、プラットフォーム固有のプロジェクトにインクルードすることができる。<br> | |||
| <br> | |||
| ==== ディレクトリとファイル構成 ==== | |||
| * wwwrootディレクトリ | |||
| *: アプリケーションの静的ファイルを格納するディレクトリ | |||
| *: CSS、JavaScript、画像等のクライアントサイドリソースを格納する。 | |||
| *: <br> | |||
| * Pagesディレクトリ | |||
| *: Blazorのページコンポーネントを配置するディレクトリ | |||
| *: 各ページは、.razor拡張子を持つ。 | |||
| *: <br> | |||
| * Sharedディレクトリ | |||
| *: 複数のページで共有されるコンポーネントを配置するディレクトリ | |||
| *: レイアウトやナビゲーションメニュー等が含まれる。 | |||
| *: <br> | |||
| * Dataディレクトリ | |||
| *: データモデルやサービスクラスを配置するディレクトリ | |||
| *: ビジネスロジック、データアクセスコードもここに含まれる。 | |||
| *: <br> | |||
| * /ディレクトリ (プロジェクトのトップディレクトリ) | |||
| *: Program.cs : アプリケーションの起動処理を定義する。 | |||
| *: Startup.cs : サービスの設定やミドルウェアの構成を行う。 | |||
| *: .csproj : プロジェクトの設定やパッケージ参照を管理する。 | |||
| <br> | |||
| 上記のディレクトリ構成は標準的なものであるが、プロジェクトの要件に応じて適宜カスタマイズする。<br> | |||
| <br> | |||
| 例えば、以下に示すようにディレクトリを構成することも一般的である。<br> | |||
| * Services | |||
| *: ビジネスロジックを分離する場合 | |||
| * Models | |||
| *: データモデルを別途管理する場合 | |||
| * Helpers | |||
| *: ユーティリティクラスを配置する場合 | |||
| <br> | |||
|  # ディレクトリ構成例 | |||
|  PhotinoProject/ | |||
|  ├── wwwroot/                   # 静的ファイル用ディレクトリ | |||
|  │   ├── css/                   # CSSファイル | |||
|  │   ├── js/                    # JavaScriptファイル | |||
|  │   └── index.html             # メインのHTMLファイル | |||
|  │ | |||
|  ├── Pages/                     # Blazorのページコンポーネント | |||
|  │   ├── _Host.cshtml           # アプリケーションのホストページ | |||
|  │   ├── Index.razor            # メインページ | |||
|  │   └── NextPage.razor         # 他ページ | |||
|  │ | |||
|  ├── Shared/                    # 共有コンポーネント | |||
|  │   ├── MainLayout.razor       # メインレイアウト | |||
|  │   └── NavMenu.razor          # ナビゲーションメニュー | |||
|  │ | |||
|  ├── Data/                      # データモデルとサービス | |||
|  │   └── Data.cs                # サンプルデータモデル | |||
|  │ | |||
|  ├── Program.cs                 # アプリケーションのエントリーポイント | |||
|  ├── Startup.cs                 # アプリケーションの設定 | |||
|  └── PhotinoProject.csproj      # プロジェクトファイル | |||
| <br><br> | |||
2025年1月1日 (水) 13:15時点における最新版
概要
Photino.Blazorは、.NET開発者にとって有益なデスクトップアプリケーション開発プラットフォームである。
このフレームワークの基本的な特徴として、OSネイティブのWebViewを使用して、Blazorの強力な機能をデスクトップアプリケーションに適用できる。
従来のElectronと比較して、はるかに軽量なアプリケーションを開発することができる。
開発環境のセットアップにおいて、Rider / Visual Studio等を使用して開発を進めることができる。
開発者は主に、C#とRazor構文を使用してアプリケーションを構築する。
これにより、WebフォームやWPFの経験がある.NET開発者にとって、学習曲線を緩やかにすることができる。
アプリケーションのアーキテクチャに関して、Photino.Blazorは単一のプロセスモデルを採用しており、UIレイヤーとビジネスロジックが密接に統合されている。
状態管理やデータバインディング等のBlazorの優れた機能をそのまま活用することができる。
Photino.Blazorは標準的なデスクトップアプリケーションのセキュリティモデルに従う。
例えば、ファイルシステムへのアクセスやネットワーク通信は、.NETのセキュリティ機能によって制御される。
Photino.Blazorのパフォーマンスにおいて、メモリ使用量はElectronベースのアプリケーションと比較して大幅に少なく、起動時間も短縮されている。
これは、ネイティブのWebViewを使用しているため、余分なランタイムを含まないからである。
Windows、MacOS、Linuxで動作するデスクトップアプリケーションをほぼ同一のコードベースで開発することが可能である。
プラットフォーム固有の機能へのアクセスも、.NETの標準APIを通じて実現可能である。
デプロイメント手順も簡便であり、アプリケーションは単一の実行可能ファイルとして配布可能で、必要なランタイムコンポーネントも含めることができる。
そのため、自己完結型の配布パッケージを作成することが可能である。
.NETコミュニティの一部として、多くのリソースやライブラリが利用可能である。
また、既存の.NETライブラリとの互換性も高く、既存のコードベースの再利用も容易である。
オールインワンアプローチ
Photino.BlazorやElectronでは、デスクトップアプリケーションのフレームワークとして、フロントエンドとバックエンドのコードを1つのパッケージにまとめる"オールインワンアプローチ"を取っている。
Photino.Blazorの場合
- .NET/Blazorのコードがバックエンド相当の処理を担当
- 軽量なネイティブWebViewをフロントエンドとして使用
- BlazorのWebAssemblyとC#コードが統合された形で動作
- やはり1つのパッケージとしてビルド・配布される
Electronの場合
- Node.jsをバックエンドとして使用して、Chromiumブラウザをフロントエンドとして使用する。
- メインプロセス (Node.js) とレンダラプロセス (Chromium) が存在する。
- 両者はIPCを通じて通信する。
- 全てのコードは1つのアプリケーションパッケージとして配布する。
オールインワンアプローチのメリット
- 開発とデプロイメントが簡単である。
- フロントエンドとバックエンドの連携が取りやすい。
- オフライン動作が容易となる。
オールインワンアプローチのデメリット
- アプリケーションサイズが大きくなる。
- リソース消費が比較的多い。(特に、Electronの場合)
- スケーラビリティに制限がある。
クロスプラットフォーム .NET UIフレームワークの対応状況
Blazorは多くのプラットフォームで動作し、全てのプラットフォーム間で多くのソースコードを共有することが可能である。
| フレームワーク | 初公開 | UI技術 | Windows | MacOS | Linux | Android | iOS | Web Assembly (WASM) | 
|---|---|---|---|---|---|---|---|---|
| .NET MAUI | May 2022 | XAML | Yes | Yes | No | Yes | Yes | No | 
| Blazor | Sep 2019 | HTML + CSS | Yes | Yes | Yes | Yes | Yes | Yes | 
| Avalonia | Feb 2015 | XAML | Yes | Yes | Yes | Yes | Yes | Experimental | 
| Uno Platform | Sep 2018 | XAML | Yes | Yes | Yes | Yes | Yes | Yes | 
| Xamarin.Forms | May 2014 | XAML | Yes | No | No | Yes | Yes | No | 
XamarinはMAUIに取って代わられており、MAUIはWebをサポートしていないため、Avalonia UI、Uno Platform、Blazorが選択肢に挙がる。
以前のBlazorは、WinForms / WPFのWebView2を使用したWASMとWindowsのみであった。
現在では、Maui Blazor Hybridがある。
フレームワークの選択
Windowsのみ
- WinForms
- WPF
Windows、Linux、MacOS
- Photino Blazor
- コンパイルや起動が速い。
 
- Electron.NET
- ElectronNET.APIで動作する。
- ただし、長いコンパイル時間、サイズの大きなビルドファイル、起動が遅い等のデメリットがある。
 
- Chromely
- ただし、長いコンパイル時間、起動が遅い等のデメリットがある。
- また、2023年1月16日に開発停止している。
 
WASM、Windows、Linux、MacOS、iOS、Androidをサポートするには、少なくとも以下に示すものが必要となる。
- Photino Blazor
- Blazor WASM
- Maui
WebView2 / WASMの違い
WebView2とWASM (WebAssembly) は異なる技術である。
ただし、これらの技術は組み合わせて使用することも可能である。
- WebView2内でWASMを実行するWebアプリケーションを表示する。
- BlazorアプリケーションをWebView2でホストする。
これらの技術は異なる目的と用途を持っていますが、相互に補完し合うことができる。
Photinoは各プラットフォームごとに以下に示すWebViewエンジンを使用している。
- Windows
- WebView2 (Chromiumベース)
 
- MacOS
- WKWebView (WebKitベース)
 
- Linux
- WebKitGTK
 
これにより、各プラットフォームのネイティブなWebViewコンポーネントを活用しながら、クロスプラットフォームな開発が可能になっている。
WebView2
WebView2はMicrosoftが開発したブラウザコンポーネントである。
Windowsプラットフォーム向けのコンポーネントであるため、その他のプラットフォームでは使用されていない。
Chromiumベースのエンジンを使用して、デスクトップアプリケーション内でWebコンテンツを表示することが可能である。
.NET/C#アプリケーションにWebベースのUIを統合する場合に使用される。
WebKitGTK
Linux上のPhotino Blazorは、現在GTK3ベースのGTKをバックエンドとして使用しており、WebKitGTKを使用してWebViewをレンダリングする。
これは、PhotoinoのGithubリポジトリのソースコードで確認することができる。
以下に示す理由から、GTK4への移行は行われていない。
- 依然として、GTK3は広く使用されており安定している。
- 多くのLinuxディストリビューションでGTK3は標準でインストールされている。
- GTK4への移行には、APIの変更への対応等、多くの作業が必要になる。
WKWebView
MacOS上でのPhotino Blazorは、WKWebViewを使用している。
WASM (WebAssembly)
Webブラウザで動作する低レベルのバイナリフォーマットである。
C++やRust等の言語で記述されたソースコードを、Webブラウザで実行可能な形式にコンパイルする。
Blazor等のフレームワークを通じて、C#コードをWebブラウザで実行することができる。
Bootstrap
Bootstrapを使用することにより、簡単にCSSを記述することができる。
テーマを実装する場合、BootswatchがBootstrap向けの26のテーマを提供している。
| ライブラリ | 仕様 | 公開日 | 説明 | 
|---|---|---|---|
| Blazorise | Bootstrap、Bulma、AntDesign、Materialに対応 | 2019/6 | Blazoriseは最も多くのコントロールがあり、C#の列挙型とクラスにCSSを抽象化している。 コミッタは、リクエストにも応えてくれやすい。 | 
| MudBlazor | Material Designのコンポーネントを提供 | 2020/4 | |
| AntDesign Blazor | Ant Designからインスピレーションを得たデザイン | 2020/3 | |
| MatBlazor | Material Designのコンポーネントを提供 | 2019/2 | |
| BlazorStrap | Bootstrap 4 / 5をベースにした実装 | 2019/4 | |
| Blazor Bootstrap | Bootstrap 5のコンポーネントを提供 | 2021/6 | 
Blazorプロジェクトでは、使用頻度の高いアイコン群を以下に挙げる。
- Font Awesomeアイコン
- Google Fonts
- 埋め込みフォントファイル
- Bootstrapアイコン
- アイコンライブラリには、SVG、SVGスプライト、Webフォント等の2000種類以上のアイコンがある。
- https://icons.getbootstrap.com/
- インストールコマンド : npm install bootstrap-icons
 
全てのCSS、JS、フォントをプロジェクトに含めることにより、スループットは良くなる。
全てのリソースが含まれているため、アプリケーションのサイズが約2[MB]大きくなる。
ディレクトリ構成
Blazorプロジェクトの構造と分割パターン
- 共有ライブラリ
- コアクラス
- コアクラスを保持する<Project Sdk="Microsoft.NET.Sdk">型のOpenHabitTracker
 
- コアクラスを保持する
- Razoorファイル
- Razoorファイルを保持する<Project Sdk="Microsoft.NET.Sdk.Razor">型のOpenHabitTracker.Blazor
 
- Razoorファイルを保持する
以下に示すように分割することにより、ロジックはUIから分離されて、Razorファイルには数行のC#コードが含まれるようになる。
C#のソースコードを.razor.csファイル (コードビハインドファイル) に記述するとエディタの動作が改善される。
また、C#のソースコードを別のライブラリに記述することもできる。
Razorコンポーネント / Razorページのみを共有ライブラリに配置して、
App.razor、_Imports.razor、MainLayout.razor、JsInterop.cs、jsInterop.js、app.cssは共有ライブラリに移動しない。
.csとindex.htmlを除く全てのファイルを共有ライブラリに移動することができる。
プラットフォーム固有の動作がある場合は、C#インターフェースで解決することができる。
全ての.cssと.jsファイルは共有ライブラリに格納することができ、
index.htmlの_content/OpenHabitTracker.Blazor/...のように、プラットフォーム固有のプロジェクトにインクルードすることができる。
ディレクトリとファイル構成
- wwwrootディレクトリ
- アプリケーションの静的ファイルを格納するディレクトリ
- CSS、JavaScript、画像等のクライアントサイドリソースを格納する。
 
- Pagesディレクトリ
- Blazorのページコンポーネントを配置するディレクトリ
- 各ページは、.razor拡張子を持つ。
 
- Sharedディレクトリ
- 複数のページで共有されるコンポーネントを配置するディレクトリ
- レイアウトやナビゲーションメニュー等が含まれる。
 
- Dataディレクトリ
- データモデルやサービスクラスを配置するディレクトリ
- ビジネスロジック、データアクセスコードもここに含まれる。
 
- /ディレクトリ (プロジェクトのトップディレクトリ)
- Program.cs : アプリケーションの起動処理を定義する。
- Startup.cs : サービスの設定やミドルウェアの構成を行う。
- .csproj : プロジェクトの設定やパッケージ参照を管理する。
 
上記のディレクトリ構成は標準的なものであるが、プロジェクトの要件に応じて適宜カスタマイズする。
例えば、以下に示すようにディレクトリを構成することも一般的である。
- Services
- ビジネスロジックを分離する場合
 
- Models
- データモデルを別途管理する場合
 
- Helpers
- ユーティリティクラスを配置する場合
 
# ディレクトリ構成例 PhotinoProject/ ├── wwwroot/ # 静的ファイル用ディレクトリ │ ├── css/ # CSSファイル │ ├── js/ # JavaScriptファイル │ └── index.html # メインのHTMLファイル │ ├── Pages/ # Blazorのページコンポーネント │ ├── _Host.cshtml # アプリケーションのホストページ │ ├── Index.razor # メインページ │ └── NextPage.razor # 他ページ │ ├── Shared/ # 共有コンポーネント │ ├── MainLayout.razor # メインレイアウト │ └── NavMenu.razor # ナビゲーションメニュー │ ├── Data/ # データモデルとサービス │ └── Data.cs # サンプルデータモデル │ ├── Program.cs # アプリケーションのエントリーポイント ├── Startup.cs # アプリケーションの設定 └── PhotinoProject.csproj # プロジェクトファイル