There is to prescribed relationship between the number of view components and mediators. You'll learn about the right granularity as you go, and you can search for 'granularity' and mediators in this forum for a lot of discussion.
For a service, typically you'll have one proxy for the service but that's not hard and fast either. It all has to do with how the service is implemented.
Most service endpoints are designed to work with a particular data type and give you various functions against it like list, search, fetch, update, remove, etc. In this case a single proxy that deals with that data type becomes the single place in the app for keeping that data and causing updates to it.
However if a service works with a number of different data types, you might put the service information into a delegate class and have several proxies that use the same delegate to access the service.
The proxies are generally aligned around data type in the application, not around the service accessed to maintain the data. We don't want the rest of the application to even know there is a service, or to have code that is tied to a specific service. This keeps the whole client portable.
And commands are needed when coordinating an update between the model and view could not be done directly, or where there is a lot of duplication going on in the mediators where proxy communication is involved.