「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 # プロジェクトファイル