「C Sharpの基礎 - Blazorデスクトップ」の版間の差分

提供:MochiuWiki : SUSE, EC, PCB
ナビゲーションに移動 検索に移動
 
(同じ利用者による、間の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>
== 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><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


以下に示すように分割することにより、ロジックは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      # プロジェクトファイル