Added a note about DI support

Author: Sergio0694

docs/mvvm/PuttingThingsTogether.md

@@ -155,6 +155,9 @@ We now have a draft of our viewmodels ready, and we can start looking into the s
 
 ## Building the settings service
 
+> [!NOTE]
+> The sample is built using the service locator pattern, but this is not the only possible pattern to use to manage service. The MVVM Toolkit also fully supports the dependency injection pattern, and you can choose the one you prefer depending on the architecture of your application, the available development time or personal preference.
+
 Since we want some of our properties to be saved and persisted, we need a way for viewmodels to be able to interact with the application settings. We shouldn't use platform-specific APIs directly in our viewmodels though, as that would prevent us from having all our viewmodels in a portable, .NET Standard project. We can solve this issue by using services, and the `Ioc` class. The idea is to write interfaces that represent all the API surface that we need, and then to implement platform-specific types implementing this interface on all our application targets. The viewmodels will only interact with the interfaces, so they will not have any strong reference to any platform-specific type at all.
 
 Here's a simple interface for a settings service:

samples/MvvmSampleUwp/MvvmSampleUwp/Assets/docs/PuttingThingsTogether.md

@@ -155,6 +155,8 @@ We now have a draft of our viewmodels ready, and we can start looking into the s
 
 ## Building the settings service
 
+> **NOTE:** the sample is built using the service locator pattern, but this is not the only possible pattern to use to manage service. The MVVM Toolkit also fully supports the dependency injection pattern, and you can choose the one you prefer depending on the architecture of your application, the available development time or personal preference.
+
 Since we want some of our properties to be saved and persisted, we need a way for viewmodels to be able to interact with the application settings. We shouldn't use platform-specific APIs directly in our viewmodels though, as that would prevent us from having all our viewmodels in a portable, .NET Standard project. We can solve this issue by using services, and the `Ioc` class. The idea is to write interfaces that represent all the API surface that we need, and then to implement platform-specific types implementing this interface on all our application targets. The viewmodels will only interact with the interfaces, so they will not have any strong reference to any platform-specific type at all.
 
 Here's a simple interface for a settings service: