As I delve into structuring multiple modules for our company's application, I find myself at a crossroads trying to design the most optimal architecture. Research suggests two prevalent approaches - one module per page or a holistic 'master' module encompassing several others. Yet, having to load all JavaScript content required for the entire application on each page feels like an impractical choice, particularly when I need to reuse modules across different parts of the same page.
Take the membership module, for instance. Originally designed for managing login credentials, registrations, and password retrieval processes within the webpage header, I encountered challenges when attempting to integrate password reset functionalities from the membership module onto a standalone password reset page where the header was also present.
Is restructuring the modules based on functions and features more viable than their physical placement on the page? Are there alternative strategies worth exploring to address this dilemma effectively? Could creating separate modules for the header and the body alleviate redundancy concerns without introducing complexity?
The underlying technology of our ASP.Net MVC application heavily relies on MVC paradigms for view management and partial views. In light of this, would adopting a dynamic JavaScript rendering mechanism to upload necessary scripts per page offer a meaningful resolution, or is it merely a false hope?
<header ng-app="membership">
//functionality related to header membership
</header>
<div ng-app="membership">
//usage outside of header where membership is utilized
</div>