Application "partitioning"

[BobRoyAce]

Let's say I have an ASP.NET application which has a dozen or so pages as
well as some supporting .cs class files. Does it make sense to split out
things into separate solutions, creating multiple DLLs, or is it better to
have a single DLL? What are the PROs and CONs of each approach? I am
thinking that, at a minimum, it would make sense to have the class stuff in
a separate DLL. In addition, perhaps it makes sense to have pages that are
part of a functional area separate. I am thinking that in this way, it kinda
compartmentalizes functionality and then would just need to recompile DLLs
for pages/code changed rather than all of it. Any related input, or pointers
to books or URLs, would be appreciated.

 

[Scott Allen]

It's difficult to spread out pages across multiple projects because they
will end up in a different applications. In different applications they cannot
share the same cache, session, or static / shared objects, so it really has
to be the case that the pages are meant to be pieces of different apps.

If you have plain code (not web forms) it is often worthwhile to extract
out pieces you might use in other applications into one or more class libraries.
You can then version the library without building the web app and also reuse
the library for other projects.

 

[Suhaib Khan]

Yeah it can be done look at this article for more detail -

http://www.dotnet247.com/247referen...01.com/articles/jayram/sharestate/default.asp

Keep this thing in mind in doing this -

1. Keep it Simple - Look at your options, why you need this, if you really
have distinct modules, then you can seperate them into individual projects.
But one thing you need to be careful is - the versions of the shared dlls
being used by these individual projects.
2. Don't do it for the sake of doing it.

Suhaib