2026 年の Flutter web における CanvasKit と skwasm: どちらのレンダラーを出荷すべきか
依存関係が Wasm にコンパイルできるなら、flutter build web --wasm で skwasm を出荷しましょう。ダウンロード量が少なく、重いシーンでは CanvasKit より 36% 多くのフレームを描画しました。Flutter 3.47.x では、マルチスレッド時のテキストのクラッシュ修正がベータを抜けるまでシングルスレッドにしておきます。
タグ: comparison
59 件 · ページ1/6
.NET 11 における Microsoft.Data.SqlClient と System.Data.SqlClient の比較
Microsoft.Data.SqlClient を使ってください。System.Data.SqlClient は非推奨で、触れる型すべてに CS0618 が出ます。さらに .NET 8 が 2026-11-10 にサポート終了を迎えると .NET 向けアセットが削除されます。その日は .NET 11 のリリース日でもあります。実測した機能差、マイグレーションを壊す Encrypt の既定値、そして 7.0 でのパッケージ分割について解説します。
.NET 11 の Process.Run と Process.Start: どちらを使うべきか
ツールを起動して終了の仕方だけが気になるなら Process.Run を使います。1 回の呼び出しで済み、タイムアウトで子プロセスを強制終了し、シグナルを含む ProcessExitStatus を返します。stdin への書き込み、出力を届いたそばから読む処理、UseShellExecute、プロセスツリー全体の強制終了など、Process オブジェクトが必要な場合は Process.Start を使い続けます。
SQL Server 互換性レベル 150 vs 160: EF Core 11 のクエリで何が変わるのか
EF Core 11 では UseSqlServer の既定の互換性レベルが 160 になり、LEAST、GREATEST、2 引数の LTRIM/RTRIM が SQL に入るようになりました。すべての Take(n).FirstOrDefault() も対象です。SQL Server 2022 以降なら 160 のままにし、SQL Server 2019 がまだ動いている環境が一つでもあれば UseCompatibilityLevel(150) で固定してください。
EF Core 11 で SQL Server に JSON を保存するときのネイティブ json 列と nvarchar(max) の比較
SQL Server 2025 と Azure SQL ではネイティブの json 型を使いましょう。EF Core 11 はそこから JSON_CONTAINS、型付きの JSON_VALUE、インプレースの modify()、JSON インデックスを引き出せます。SQL Server 2019/2022、レガシーなツール、あるいはロールバックできる必要があるスキーマの場合は nvarchar(max) のままにしてください。
C# で重複キーを扱うなら Lookup<TKey, TElement> か Dictionary<TKey, List<TValue>> か
一度グループ化して読むだけなら ToLookup を使います。不変で、存在しないキーには空のシーケンスを返し、null キーを受け付け、最初に現れた順序を保ちます。構築後にグループが変化する場合や JSON の境界をまたぐ場合は Dictionary<TKey, List<TValue>> を使います。
Riverpod の ref.watch と ref.read の違いと、それぞれをいつ使うか
ref.watch は購読して再ビルドし、ref.read は一度読むだけで再ビルドしません。watch はすべての build メソッドの中で、read はイベントのコールバックの中だけで使います。判断マトリクス、flutter_riverpod 3.4.3 における両メソッドのソースコード、そして 4 つの静かな失敗パターン (コールバック内の watch、プロバイダー本体での read、autoDispose なプロバイダーへの read、最適化のつもりの read) を解説します。
.NET 11 のコンテナーイメージにおける framework-dependent と self-contained と Native AOT の比較
ASP.NET Core サービスを .NET 11 で動かすなら、chiseled な aspnet イメージ上の framework-dependent が正しい既定です。ランタイムのレイヤーがサービス間で共有され、ランタイムの CVE はベースイメージの差し替えだけで塞げるからです。self-contained + トリミングと Native AOT はイメージを 2 倍から 5 倍小さくし、コールドスタートを大幅に速くしますが、その代わりに前述の利点を失います。実測された公開サイズ、共有レイヤーの計算、そして AOT の経路を壊す .NET 11 のベースイメージ推論バグを扱います。
C# のリポジトリメソッドで Task を直接返す vs async/await でパススルーする: どちらを使うべきか
リポジトリのパススルーメソッドで async/await を省略すると約 6 ns と 72 バイトを節約できますが、スタックフレーム、try/catch のセマンティクス、安全なリソース破棄を失います。計測済みのホットパス上の純粋なパススルーでない限り、return await を残してください。
AutoMapper と Mapperly と手書きマッピングの比較 (2026年版)
新しい .NET コードでは Mapperly が既定の選択です。手書きマッピングと同等の速度で、Native AOT でも動作し、マップ漏れをコンパイル時に検出します。ProjectTo では AutoMapper が依然として優位です。ベンチマークとライセンスのしきい値付き。