That's correct, a dedicated service should be implemented for that, and that service would probably consume the people repository when needed.
In the context of using Unity in your application, a singleton instance is an instance of a class that will be kept alive as long as the container is kept alive (which is probably the whole life cycle of your application). Therefore, in practical purposes,
the same instance of your class will be returned when you call the IUnityContainer.Resolve<T> throughout your application. Using the
IUnityContainer.RegisterInstance<T> method is a possible way to achieve that. Another one is to use the
IUnityContainer.RegisterType<TFrom,TTo> method, passing a
ContainerControlledLifetimeManager as the parameter. The difference between them is that, when you use the
RegisterInstance method, you need to pass an instance to that method, and that will be the one that will be shared and kept alive; whereas when you use the
RegisterType method passing a ContainerControlledLifetimeManager, the container will instantiate your service, and will always return the first (and only) instance it has created.
Using a static resource would, as I've mentioned in my previous answer, break testability and maintainability concerns. This is because you would be creating a strong dependency between your components and your static resource, and you wouldn't be able to
mock it on a test scenario. But in the case of using the container to expose a shared service (by doing an interface mapping), you would only depend on the interface, and your view models or any other component that depends on that service would be abstracted
from the concrete implementation of the service (i.e. the only one that will be concerned with the concrete implementation of the service will be the container, which is responsible for mapping ISomeService -interface- to SomeService -implementation-).
You can read more about the benefits of the Inversion of Control pattern and Dependency Injection in the following chapter from the Prism MSDN documentation:
Chapter 3: Managing Dependencies Between Components
As for the approach you've proposed which involves using the event aggregator, it is a valid possibility to achieve your scenario. In case you use the event agrgegator, you don't need to make your view models depend on your service, but rather on the event
However, using the event aggregator is not the only possibility to achieve that; when I mentioned the use of an event to notify that the list of people has been refreshed, I was referring to exposing a common .NET event in your service, which your components
(such as the view models) could subscribe to.
Both approaches have their benefits and caveats, so the choice would be based on your personal preference and requirements. You can read more about it in the following chapter from the Prism MSDN documentation:
Chapter 9: Communicating Between Loosely Coupled Components
I hope you find this helpful.
Guido Leandro Maliandi