As part of a larger school project I have an application design using MVC pattern and now have a new requirement to add a remote monitoring station. It seems the proxy pattern is best for the remote monitor but... Does it make sense to hook the proxy into the view or do I need something else like an adapter... or hook into the model and use a new view/controller on the client side?
Here is an basic UML example of what I'm attempting to describe.
You could model this where the Controller accesses the Proxy to retrieve its data, and then includes that data in the model for the view to display. This would allow you to do certain things, like hide API access keys or other credentials from the client (very important when consuming many third party services). This also allows you to do things like cache values from a proxy at your controller level - or more likely an injected aspect [i.e., yet another proxy] between the controller and the proxy.
There are situations, however, where you'd consider this problem from the client side and in a web application you might logically think of the solution living in the view (insofar as you may logically think about JavaScript). In reality the actual design is that you have client code that lives in the view that breaks down into its own UML model where there's a controller, model, view, etc. You'd do this in situations where caching on the server backend is unimportant, or where sensitive credential information shouldn't ever leave the client's machine.
When you remove JavaScript from the equation and you are considering just a vanilla MVC design I believe its better to have the controller access the proxy.