だから私は、API レイヤー、サービス レイヤー (ビジネス ロジックを考える)、およびその周りのすべての適切なサポート レイヤーを利用する単純なプロジェクトに取り組んでいます。以前は、コントローラーがスコープ外になったときに、Web Api 2 要求が破棄階層を開始すると考えていました (したがって、API から呼び出され、クラスのデータ メンバーであったサービスは、後続のリポジトリ/依存関係と共に破棄されました)。 .
コアでは、base.dispose() を呼び出す単純なメソッド オーバーライドを実行すると、コントローラから dispose が呼び出された場所を確認できます。ただし、私のサービスは廃棄プロセスを開始しているようです。LightInject の PerRequestLifetime スコープを使用して廃棄可能なリソースを取り除くのに行き詰まっています。これはコアとの違いですか?通常、トランジェントは私が期待する動作を私に与えました (controller.dispose() が呼び出されると、依存関係の破棄呼び出しが行われます)。私が行った以前の作業では、Unity IC コンテナーを使用していたことが完全に開示されています。
最終的には、コントローラーの dispose メソッドをオーバーライドして service.dispose() を呼び出すのと同じ結果になると思いますが、コア コンテキストでの LightInject トランジェントの動作には驚かされます。
これが私のリポジトリで、コード例はhttps://github.com/napalm684/ReciPiBookCoreです。
ここでの主な焦点はもちろん、UnitOfMeasureController と UnitOfMeasureService です。DI レイヤー (具体的にはhttps://github.com/napalm684/ReciPiBookCore/blob/master/src/ReciPiBook.Di/ServiceContainerExtensions.cs ) は、サービスの LightInject 登録作業を見つける場所です。
登録
container.Register<IUnitOfMeasureService, UnitOfMeasureService>(new PerRequestLifeTime());
コントローラ
[Route("api/[controller]")]
public class UnitOfMeasureController : Controller
{
private readonly IUnitOfMeasureService _unitOfMeasureService;
public UnitOfMeasureController(IUnitOfMeasureService unitOfMeasureService)
{
_unitOfMeasureService = unitOfMeasureService;
}
[HttpGet]
[Route("{id:int}")]
public string Get(int id)
{
return _unitOfMeasureService.Get(id).Description;
}
}
サービス
public class UnitOfMeasureService : IUnitOfMeasureService
{
private readonly IRepository<Entities.UnitOfMeasure> _repository;
private bool _disposed = false;
public UnitOfMeasureService(IRepository<Entities.UnitOfMeasure> repository)
{
_repository = repository;
}
public Dtos.UnitOfMeasure Get(int id)
{
return _repository.Get(id).AsUnitOfMeasure();
}
protected virtual void Dispose(bool disposing)
{
if (_disposed) return;
if (disposing)
_repository.Dispose();
_disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}