My own two cents: In web applications, it just makes senses that a new DI scope is created for every individual HTTP request received to the application. The request itself has a clear beginning and end and is tied to a single user (authenticated or otherwise), so creating services which live for the entire lifetime of the associated request (scoped service) is easy. However, in desktop/mobile style applications, there is no obvious place for a DI scope to be by default. What this doesn't mean though that scoped services are completely out of the picture. You just have to decide your self as to when a new DI scope should be created (by requesting the IServiceScopeFactory from DI), and how long the scope should last for (when to dispose of the scope and therefore all the attached services). I can say that from my own experiences that creating your own DI scope can at least help with services in multi-threaded contexts. Ultimately the question comes down to how long you want an instance of the service to exist for, and do you want that instance to be shared by other services that all have the same life time. If you do, then create a new DI scope yourself when you need it and register the appropriate services as scoped. If not, stick to Transient and Singleton services. I haven't yet built a propper MAUI app from the ground up (aside of my own Blazor MAUI hybrid app I've been building which doesn't use a MVVM library and is more Blazor than MAUI). But in my mind, for desktop/mobile style applications, creating a new scope for every command that the user invokes would somehwat make sense to me, that way they can be disposed off when the command complete. This feels somewhat equivalent to the web application receiving a HTTP request. But someone may have some counter points in doing that (again, haven't really tried but if some one does know better, please say so and give detailed explanation as to why).
@@AdrianSanguineti Your post aligns well with my thoughts on the use of scoped services in desktop and mobile apps. The applicability of scoped services in such apps is often limited, and deciding when (or if) to use them really depends on the structure of the service dependency tree. Your example of creating a scope for the execution of a command handler makes perfect sense. However, I'd like to point out that a cleaner approach, in my opinion, is to inject IServiceScopeFactory rather than IServiceProvider. You can then use the factory to generate a new scope, which contains its own IServiceProvider to resolve scoped services. I mention this because I frequently see people opting for the less clean approach of injecting IServiceProvider directly. Now, regarding the video content: I have some concerns about the correctness of registering IConnectivity as a singleton. While I haven't personally worked with this interface, I know that singleton instances are resolved only once for the entire lifetime of the application. My concern is that if the IConnectivity singleton is resolved when the app has internet connectivity and the connection is lost later, the singleton instance might still indicate that the internet is available, leading to stale state. I'm not familiar with the internal structure of the ConnectivityImplementation class and how instances are set in Connectivity.Current, but I would expect some state design pattern to be involved. This could result in stale instances being used if IConnectivity is registered as a singleton, preventing it from reflecting real-time connectivity changes. In this case, I would suggest registering IConnectivity as a scoped service using the factory method demonstrated in James's video. The MainViewModel would inject IServiceScopeFactory, and in the CheckInternet method, you could create a new scope (ensuring the scope is disposed of afterward) and use the scope's service provider to resolve the current instance of IConnectivity. This way, you ensure you're working with the most up-to-date connectivity state, demonstrating how scoped services can be leveraged effectively in a MAUI app.
Esta informacion es muy util
Muchas gracias
How will scope di work?
My own two cents: In web applications, it just makes senses that a new DI scope is created for every individual HTTP request received to the application. The request itself has a clear beginning and end and is tied to a single user (authenticated or otherwise), so creating services which live for the entire lifetime of the associated request (scoped service) is easy.
However, in desktop/mobile style applications, there is no obvious place for a DI scope to be by default. What this doesn't mean though that scoped services are completely out of the picture. You just have to decide your self as to when a new DI scope should be created (by requesting the IServiceScopeFactory from DI), and how long the scope should last for (when to dispose of the scope and therefore all the attached services). I can say that from my own experiences that creating your own DI scope can at least help with services in multi-threaded contexts.
Ultimately the question comes down to how long you want an instance of the service to exist for, and do you want that instance to be shared by other services that all have the same life time. If you do, then create a new DI scope yourself when you need it and register the appropriate services as scoped. If not, stick to Transient and Singleton services.
I haven't yet built a propper MAUI app from the ground up (aside of my own Blazor MAUI hybrid app I've been building which doesn't use a MVVM library and is more Blazor than MAUI). But in my mind, for desktop/mobile style applications, creating a new scope for every command that the user invokes would somehwat make sense to me, that way they can be disposed off when the command complete. This feels somewhat equivalent to the web application receiving a HTTP request. But someone may have some counter points in doing that (again, haven't really tried but if some one does know better, please say so and give detailed explanation as to why).
@@AdrianSanguineti Your post aligns well with my thoughts on the use of scoped services in desktop and mobile apps. The applicability of scoped services in such apps is often limited, and deciding when (or if) to use them really depends on the structure of the service dependency tree. Your example of creating a scope for the execution of a command handler makes perfect sense.
However, I'd like to point out that a cleaner approach, in my opinion, is to inject IServiceScopeFactory rather than IServiceProvider. You can then use the factory to generate a new scope, which contains its own IServiceProvider to resolve scoped services. I mention this because I frequently see people opting for the less clean approach of injecting IServiceProvider directly.
Now, regarding the video content: I have some concerns about the correctness of registering IConnectivity as a singleton. While I haven't personally worked with this interface, I know that singleton instances are resolved only once for the entire lifetime of the application. My concern is that if the IConnectivity singleton is resolved when the app has internet connectivity and the connection is lost later, the singleton instance might still indicate that the internet is available, leading to stale state.
I'm not familiar with the internal structure of the ConnectivityImplementation class and how instances are set in Connectivity.Current, but I would expect some state design pattern to be involved. This could result in stale instances being used if IConnectivity is registered as a singleton, preventing it from reflecting real-time connectivity changes.
In this case, I would suggest registering IConnectivity as a scoped service using the factory method demonstrated in James's video. The MainViewModel would inject IServiceScopeFactory, and in the CheckInternet method, you could create a new scope (ensuring the scope is disposed of afterward) and use the scope's service provider to resolve the current instance of IConnectivity. This way, you ensure you're working with the most up-to-date connectivity state, demonstrating how scoped services can be leveraged effectively in a MAUI app.