Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
#1 - Should I abstract the view rendering of the application to a stand alone core so that I can switch it out as needed (for ex: different rendering cores for different platforms)?
#2 - Should I also move my game engine to a separate core?
One solution I came up with was providing a way for each module to define the proxies it wants a reference to from the shell. When the shell creates the module, it can pass these proxies to the module. I could then treat these proxies almost as an external API that I could access from each module, perhaps having a proxy to abstract them from the module. I kinda feel like this type of a solution causes to much interdependence between a module and the shell. Any thoughts?
You're right, sharing a proxy reference between modules is not the good approach. But sharing data as you thought in the second part of your paragraph may be the right.
You should definitely not pass MVC actors between cores. That defeats the concept of modularity entirely. No core/module should know anything about the contents of another.
A good intermediary solution to have something neat and at minimum cost is simply to use a common proxy class that each module will instantiate in its own environment (not the same instance shared).
However, you can always have a 'common' package that multiple cores share. Usually this is done to provide base classes that modules will sublclass and use internally. But you never have Core A referencing Core B's internal MVC actors.
Passing Value ObjectsJust as with the MVC separation, at the modular level, it's often a good idea to separate the service interactions into a separate core/module. A request object might be passed to such a module, which would interpret and act on the request, sending back a message with a value object returned from the service.