View on GitHub


This user doesn't have any project on FeatHub yet.

Features suggested

Project Feature Score Description
unitycontainer/unity Support async 31 Short: support ability to register factory which can load services in the asynchronous mode. Why: Some complex application uses asynchronous loading logic. As an example, huge enterprise WPF application can do different http calls to load actual data. Financial applications load the actual market data (spots, etc.). These applications use the following warm up logic: 1. Open Splash screen to show user, what is happening for current moment. 2. Start creation main service/main screen, etc. 3. Main service requires to create tree of dependent services, so cascade creation is started 4. After main service loading finish - close splash screen and show main window. Some of services uses asynchronous method to load configuration (from file or network), to load workspace, etc. Moreover, some of services can be created in parallel: user's avatar can be loaded in the same time with workspace creation. So, what we have: 1. Loading method can be asynchronous (e.g. splash screen window can use Task-based method simple) 2. Some of services works better in async mode 3. Some of services can be warmed up in parallel with other Proposed design: 1. Support loading factory with method like "Task<TContainerInterface> CreateAsync<TContainerInterface>(IFirstDependency firstDependency, ISecondDependency secondDependency)". Some of services will use this method for creation 2. Support async methods in IUnityServiceLoader - they will be used by asynchronous factories and by global splash screen Proposed implementation: 1. Services resolution logic can be the same. 2. Services initialization should work in the different ways of parallelism: 2.1. By default all services should be created one-by-one, without any parallel invocation. 2.2. In case, when factory implements special interfact IUnityInitializationContextProvider { object InitializationLock { get; } }, then: 2.2.1. If object is null - then factory methods should be called in the same way, as in item "2.1" 2.2.1 Otherwise, InitializationLock should be used for initialization task grouping. So, all initialization tasks should be groped by the resulting objects. This is the same, with using Synchronization Context in .Net. 3. I tried to show the simplest idea. Of course, we should not use object type for InitializationLock: we have to use interface with several members, to describe parallelism ways, etc.


This user hasn't voted yet.


Vote When Project Feature
over 2 years ago unitycontainer/unity Support async