はじめに VContainerはUnity向けのシンプルで強力なDIコンテナとして有名ですが、いきなり使っても使い方があまり確立されないように思います（VContainerに限らず、DIコンテナ全般としての話だと思いますが）。 最近、自分なりにある程度納得できる使い方がわかってきたので、参考程度に紹介します。 1 シーン 1 LifetimeScope VContainerのLifetimeScopeは親子関係を持たせることができます。加えてLifetime.Scopedを利用することでスコープを絞ることができます。これによって依存関係をより厳密に管理することができるのですが、濫用すると逆に複雑になりすぎる場合があります。 シーンごとにLifetimeScopeが管理されていれば十分な場合が多いので、自分は1シーンに1つのLifetimeScopeを持たせるようにしています。 たとえば、
それぞれ依存性注入するのは変わりませんが、オブジェクトの生成タイミングが違うので実際に比較します。 環境 .NET 8 お試しコード AddTransient、AddScoped、AddSingletonを以下のコードで切り替えながらserveエンドポイントを叩いてみて試してみます。 using DILifeCycle; using Microsoft.AspNetCore.Mvc; var builder = WebApplication.CreateBuilder(args); // 依存性注入コンテナへのサービス登録 // AddTransient、AddScoped、AddSingleton を切り替えて試す builder.Services.AddTransient<IService, ServiceA>(); // builder.Services.AddScoped<ISer
この記事は以下の知識を前提とします。 VContainer等のDIコンテナ VitalRouter等のメッセージライブラリ はじめに ローグライクゲームなどによくあるアイテム取得処理の設計について考えてみます。 仕様の確認 ローグライクでのアイテムは、主にプレイヤーのステータスを変更するものや、プレイヤーの行動を変更するものがあります。 ステータス変更 HPの回復 攻撃力の上昇 防御力の上昇 行動変更 スキルの追加 既存のスキルとのシナジー スキルAで倒したらスキルBのクールタイムがリセットされるとか その他あらゆる変数への影響 お金の増減 運の上昇 これらは単なる変数として表現するのがほぼ不可能であり、そうなると1つ1つ特有のアイテムクラスを作成する必要が出てくると思われます。 インターフェースの作成 これらのアイテムを抽象化すると、「取得時になんらかの影響を追加する」ということまでしか
はじめに 前回の記事では、UnityのDIコンテナとして有名なVContainerの基本的な使い方を紹介しました。 その際、PureC#でエントリポイントを含めた設計がしやすいことや、実行順を気にしない簡単な記述で書けるなどのメリットがあることを確認しました。 ですが、そんなDIコンテナ（正確には、DIコンテナを利用したPureC#メインの開発）にも弱点があると思っているので、今回は、DIコンテナ、ひいてはPureC#をメインに使うメリット・デメリットについて見ていきます。 DIコンテナを使ってPureC#を含めるメリット まずは前回の確認的な部分にもなりますが、メリットについて見ていきます。 PureC#でエントリポイントを含めた設計がしやすい 前回の記事でも触れましたが、DIコンテナを使うことでPureC#でエントリポイント（Start()とかUpdate()とかを使えるクラス）を含め
本稿は「アーキテクチャを突き詰める Online Conference」における発表「なぜDependency Injectionなのか？ ～関心の分離と疎結合～」の登壇原稿となります。 発表時の動画アーカイブは後日公開されたタイミングでリンクを追加いたします。 また、本稿のサンプルコードとPower PointはGitHubで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 https://github.com/nuitsjp/WhyDependencyInjection というわけで、本稿の目指すゴールはこちら。 今日は、この場にいる皆さんが「なぜDependency Injectionを利用するのか？」ということを、理解いただくのが本日のゴールとなります。 というわけで本
はじめに 前回はUnityにおけるDI(Dependency Injection)のちょっと実践的な使用方法についての記事を書きました。 前回での気づきとして、UnityDIはこのままの手順でやるとちょっと面倒になる、というお話をしました。 他にも、UnityDIを手書きで書くデメリットはいくつかあります。 newなどの実行順が大事になってくるのが面倒 エントリポイントの設計がちょっと面倒 MonoBehaviourクラスのStart, UpdateなどのライフサイクルメソッドをPureC#で利用したい場合、GameEntryPointでそれらを呼び出す必要がある 複数個のオブジェクトの依存の解決・動的な依存の解決が面倒 いちいちInit()メソッドを呼び出すのが面倒・保守性が微妙 …要するに、総じて「GameEntryPointを書くのが面倒！！難しい！！」ということです。 今回は、これ
はじめに 前回の記事では、UnityにおけるDI(UnityDI)の基本的な概念について見てきました。 今回は、具体的な実装例を見ながら、UnityDIの基本的・実践的な使い方を見ていきます。 [SerializeField]とコンストラクタを使ってゲームの依存関係を解決する ここからは、実際に前回の機能を利用してゲームの依存関係を解決する方法を見ていきましょう。 この話を抜きにしていきなりVContainerなどの話をしてもDIコンテナのメリットがあまり伝わらないと思うので、まずはUnityDIの基本を理解しておくことが大事だと思って書いています。 例題 例題として、以下のようなゲームを作ることを考えます。前回の例のもうちょっと実践的なバージョンです。 GameLoopSystemはPlayerのHPを監視し、HPが0になったらGameOverUIを表示する PlayerがCoinと衝突
はじめに DI(Dependency Injection)。 単語自体を聞いたことがある方はそこそこいるのではないでしょうか。 Unityにおいては、ZenjectやVContainerといった便利なDIライブラリも登場し、その話題もちらほら耳にすることがあるかと思います。 しかしながらそれらのライブラリの意義・メリットが分かりにくいと感じたことはないでしょうか？ これには主に以下の2つの理由があると思っています。 UnityにおけるDIのメリット・効能を実践的に示した記事があまりない UnityにおけるDIはちょっと軽めの意味で使われることが多い Zenject / VContainerはDIのライブラリなので、「UnityにおけるDI」が何たるかを知らないと話も分かりづらいですし、何より使う気にならないと思います。 そこで、今回からは、そもそもDIって何がいいのかを知ってもらうことを主
VContainerで動的に生成したGameObjectにDIする方法についてまとめました。 はじめに パターン1: Enemyを生成するクラス（Spawner）にDIする場合 パターン2: Spawnerを介しつつEnemyにDIしたい場合 パターン3: ファクトリメソッドをDIする場合 参考 VContainer 1.15.3 はじめに 本記事では VContainer を使って動的に生成したGameObjectにDIする方法についてまとめます。 例として、ゲーム中に動的に多数の敵が生成され、それぞれの敵は自身が行動したイベントを他に伝えるためのイベントバスを持つものとします。 まずイベントバス以下のように定義します（説明用なのでログを出力するだけ）。 using UnityEngine; public sealed class EventBus { public void Publi
業務で抽象クラスを継承し、インターフェースを実装しているクラスがあり、併用している意図が分からなかったので調べてみました。 結論 Template MethodとDIの組み合わせでした。 Template Method Template Methodは親クラスで大まかな処理を定義し、詳細は親クラスを継承した子クラスで実装するデザインパターンです。 親クラスで大まかな処理を定義しておくことで、子クラスごとに同じコードを書かずに共通化することができます。 DI オブジェクトの依存関係を外部から注入することで、クラス間を疎結合にするデザインパターンです。 DIを利用することでクラスの付け替えがしやすくなり、モックによるテストがしやすくなります。 例 クラス図 PRGでキャラクターを操作するCommnadクラスとキャラクターを共通化した抽象クラスのCharactorクラスがあります。 子クラスのW
今回の記事はDependency Injection(依存性の注入)について。 設計についての学習を始めると「依存性の逆転」「Dependency Injection(依存性の注入)」「DIコンテナ」など言葉を耳にする機会が増えてくると思います。適切にDIを扱えるようになると設計の柔軟性が飛躍的に向上するため、是非とも習得したい知識です。 今回は「そもそもDependency Injection(依存性の注入)とは何なのか」という話から始め、サービスロケータやDIコンテナについてまで解説していきたいと思います。 またこの記事ではSOLID原則(特に依存性の逆転)等の知識を前提として進めるため、設計何もわからん！という方は以下の記事から読むことをお勧めします。記事の後半で依存性の逆転について触れているため、その辺りを押さえてからDIについて学ぶと良いでしょう。
Dependency Injection (DI) とは、オブジェクトに必要な依存関係を外から注入する設計パターンです。 本記事ではiOSアプリの実装をテーマに、DIがなぜ必要なのか、さらにはDI Containerとは何を解決するためにあるのかについて具体的な実装例をもとに解説します。 ※ 本記事は iOS Test Night #12 にて発表した内容を書き起こしたものとなっております。 speakerdeck.com Dependency Injection 依存を内部で初期化する書き方 依存性逆転の原則に従った書き方 DI Containerの基本 Daggerに学ぶ依存のライフタイム管理 SwiftUIアプリにおけるDI Containerの実装例 DI Containerの実装 Viewの実装 まとめ Dependency Injection Dependency Inject
こんにちは！ 株式会社OGIXのクライアントエンジニアのK.Iです。（OGIXについてはページ最下部で紹介しています！） 今回はUnityで扱うDIコンテナについて、内部のDI（依存性注入）の構造まで深く紹介している記事が少なかったので、ご紹介します。 まずDIとは DIは Dependency Injectionの略で、別名 依存性注入と呼びます。 プログラミングにおけるデザインパターンの一つで、オブジェクトを成立させるために必要となるオブジェクトの参照を実行時に注入（Inject）する手法のことです。 DIという概念自体はとてもシンプルで、 オブジェクトの生成時に注入を行うコンストラクタインジェクション、 生成後にメソッド経由で注入を行うメソッドインジェクションやセッターインジェクションなど DIという用語を知らなくても、普段から行っているこれらの処理のことを示します。 Unityの
概要 ASP.NET Coreのコントローラから呼び出しているScopedサービスのクラスをバッチ処理からも呼び出そうとしたらエラーになった 原因はDIコンテナのスコープ範囲（ASP.NET Coreではリクエスト単位）がバッチ処理だと違ってくる為だった ASP.NET Coreと同様に、処理の呼び出し毎にDIコンテナのスコープを生成するようにしたらうまくいった 内容 次のようなASP.NET Coreのコントローラがあり、その中でMyLogicのDoWorkAsyncメソッドを呼び出している。 MyLogicには様々なScopedサービスが注入されており、DIコンテナを利用してコントローラに注入される。 ASP.NET Coreではサービスのスコープ範囲は「リクエスト単位」である為、DoWorkAsyncの呼び出しも基本、1回毎に異なるスコープで呼び出されることになる。 public c
はじめに この記事はiOSDC Japan 2023での「Xcode Previewを気軽に使うためのDI戦略」の要約と補足です。 スライドも公開しているので、そちらも併せてご確認ください。 発表を見ていない方のために要約を書いていますが内容自体は発表のものと同じかつ長いので、発表を見た方は要約をスキップして、いきなり補足から見ていただいて大丈夫です。 発表の要約 Xcode Previewをする上でのDI Xcode Previewを利用する上で、Dependency Injection (DI) は避けては通れないテーマです。 例としてAPI通信をして記事の一覧話取得する ItemListView を考えてみます。 struct ItemListView: View { @StateObject var viewModel = ItemListViewModel() var body:
このドキュメントの内容 任意のロガーを汎用ホストのDIに組み込む例です。 要件 今回は次の要件を満たすものを考えます。 汎用ホストの既定のログプロバイダに組み込む。 構成ファイルで独自のオプション値を設定できること。 実装方針 ILogger インターフェースを実装したロガークラスと ILoggerProvider インターフェースを実装したプロバイダークラスを実装します。 プロバイダークラスを汎用ホストが管理するログプロバイダーに登録します。 独自のプロパティを定義したオプションクラスを実装し、構成ファイルから読み込むようにします。 実装したコード SampleLogger クラス ログをコンソールに表示するだけのロガー。 /// <summary> /// サンプルロガー。 /// </summary> internal class SampleLogger : ILogger { /
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く