I am working on a (largish) internal web application which has multiple modules (security, execution, features, reports, etc.). All the pages in the app share navigation, CSS, JS, controls, etc. I want to make a single "Web Application" project, which includes all the pages for the app, then references various projects which will have the database and business logic in them. However, some of the people on the project want to have separate projects for the pages of each module.
To make this more clear, this is what I'm advocating to be the projects.
/WebInterface*
/SecurityLib
/ExecutionLib
etc...
And here is what they are advocating:
/SecurityInterface*
/SecutiryLib
/ExecutionInterface*
/ExecutionLib
etc...
*project will be published to a virtual directory of IIS
Basically What I'm looking for is the advantages of both approaches. Here is what I can think of so far:
Single Virtual Directory
Pros
Modules can share a single MasterPage
Modules can share UserControls (this will be common)
Links to other modules are within the same Virtual directory, and thus don't need to be fully qualified.
Less chance of having incompatible module versions together.
Multiple Virtual Directories
Pros
Can publish a new version of a single module without disrupting other modules
Module is more compartmentalized. Less likely that changes will break other modules.
I don't buy those arguments though.
First, using load balanced servers (which we will have) we should be able to publish new versions of the project with zero downtime assuming there are no breaking database changes.
Second, If something "breaks" another module, then there is either an improper dependency or the break will show up eventually in the other module, when the developers copy over the latest version of the UserControl, MasterPage or dll.
As a point of reference, there are about 10 developers on the project for about 50% of their time. The initial development will be about 9 months.
