Reputation: 3742
I am designing a complex web based business solution. My Domain, Reports and Processes projects are structured around business modules (3-4 levels deep) eg.:
\Franchises
\Regionals
\Billing
\Monthly
\...
\...
\...
\...
\...
\...
\...
\...
The traditional MVC folder structure sticks out line a sore thumb, with max 2 levels deep. Therefore I plan to implement this structure instead:
\Franchises\Regionals\Billing\Monthly\RegionalMonthlyBillingController.cs
\Franchises\Regionals\Billing\Monthly\Views\...
\Franchises\Regionals\Billing\Monthly\ViewModels\...
\Franchises\Divisionals\Allocation\DivisionalAllocationController.cs
\Franchises\Divisionals\Allocation\Views\...
\Franchises\Divisionals\Allocation\ViewModels\...
...
Note that our domain models are held in Domain, and the WebUI need only contain ViewModels.
Aside from the problem of customizing the MVC routing/mapping, can you see any problems with this approach?
Given there will be many Views folders, could there be a performance concern with MVC having to search 500+ folders to find the relevant view?
Upvotes: 0
Views: 228
Reputation: 1038830
Aside from the problem of customizing the MVC routing/mapping, can you see any problems with this approach?
Might lead to some pretty large project and it might be difficult to navigate for a newcomer. You could consider externalizing some of the logic in separate assemblies to avoid having a single monolith application. Consider ASP.NET MVC Areas.
Given there will be many Views folders, could there be a performance concern with MVC having to search 500+ folders to find the relevant view?
No, when running in release mode (debug="false"), ASP.NET MVC caches the location of the views and the lookup is pretty fast.
Upvotes: 3