A module may certainly have more than one view control. Add an additional .ascx user control (also inheriting from PortalModuleBase) and when registering this new control give it a unique ControlKey. Note that there most be one and only one view control (the default view) which will have a blank ControlKey.
You may then redirect to the second view control using one of the overloads of the DotNetNuke.Common.Globals.NavigateURL() method passing in parameters for the ModuleId and ControlKey as well as any others such as your entity ID needed by the second view. See the following Wiki entry for details: http://www.dotnetnuke.com/Resources/W....
What I don't like about this approach is that anytime the ControlKey is passed in the URL (e.g. ?ctl=details), the DNN framework switches to the "edit" skin and isolates the targeted module by itself on the page.
My preference would be to use a single view control with multiple views - multiple divs, panels, or multiview control hiding the unused views and displaying the target view based on url parameters. Although I'm not fully comfortable with it yet (having spent most of my programming days writing backend/server-side code), the trend today is toward the single view control with most of the work being done client-side using jQuery, Knockout, web service for data access, etc. Take a look at how the new social features - journal, groups, member directory are coded in the DNN 6.2.x source.
A different approach to have multiple view controls on the same page simultaneously is by creating a second .ascx that is registered with a blank ControlKey but which is registered using a different ModuleDefinition than the first. One of the few formerly "core" modules which takes that approach is the Blog module whose source is available in the Forge/CodePlex. Take a look at it's manifest file to see how this may be done.
My least favored approach in this case would be to create a second module (view control with blank ControlKey) and place it on a different page. You can certainly create the second module with only a view control (no edit or settings control) and share common entity classes, controller, and SQL stored proceedures with the main module. But . . . the first module will have to be aware of the ModuleId (which will be different) and TabID or page name of the second module to properly redirect. This should not be hard-coded but automatically or manually configured in the first module's settings. The other problem is packaging the two modules for installation. Although you can (manually) create a single zip archive having multiple modules/packages - each module will show up in the Host-->Extensions Installed Modules view as a distinct module/package. The Store module available in the Forge/CodePlex is one that takes this approach. Likewise with the core Search and Search Results module - although they are not installed though the usual zip archive packaging.
I hope this helps in your development!