views:

19

answers:

1

Say you have a large Web site, containing several discrete applications that run in the same site to do various things. You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.

These applications will run in the same process. No virtual directories or app isolation. They will share things like session, cache, cookies, etc.

Sure, the code-behinds and class-libraries are just DLLs in the bin folder, but what of the presentation-level stuff that has to integrate in the runtime environment? What about sharing of the code-level resources I mentioned above -- cookies, session, cache, etc.? What about base page classes?

Example: it strikes me that every sub-app needs to be "master page aware" -- it needs to know where the master page will be located, and what ContentPlaceHolders are available, because the sub-apps Web forms will need to reference this stuff.

Any other thoughts here? Assume the sub-apps will share the same master page, theme, and everything else in the presentation layer, so they appear to be a seamlessly integrated part of the whole. But they will be worked on in different Visual Studio projects, by different dev teams that know nothing about one another except what's absolutely necessary.

Anyone want to share some best practices here?

+1  A: 

You don't want to manage everything as a single project, so you break them apart, work on them in total isolation from one another, and just deploy them separately into the same runtime environment.

Why work in isolation? Establish a repository for the entire solution including all projects. Whatever change is made it is immediately available to all developers. With your approach it will be a nightmare to come.

Consider splitting responsibility by pages. One team does one segment, the other does the other one.

Another option is to let each team develop their part as a user control. You can easily assemble those together to represent a complete product.

Developer Art
Agreed, it sounds like one solution containing multiple projects is appropriate here.
s_hewitt
I guess my problem isn't how they're *developed* but rather how they're *executed*. How do you make sure they share resources nicely, without stepping on each other?
Deane