Question

We're developing a new project that is to be deployed on a large number of client sites. The project contains a web-based GUI as one of it's "access points". Speed of the web interface is a priority for this project, second only to security.

In the past, we've always created "web sites" in Visual Studio, which, when published, results in one dll and one aspx file for each page within the system. However, I am aware that you can actually create a "web application" and have it compile everything down to a single dll.

To me (based on no real data, just gut feeling), compiling the site as a single dll sounds like it would be better for both security and speed (if only marginally).

What are the considerations we should look at, and are there any obvious pitfalls we should be aware of when choosing the method that's right for us?

Was it helpful?

Solution

If it is a large application, there should be natural areas of division in your business logic (software tiers, if you will) which can go in their own DLL's.

It would be nice if the core website functionality could go into a single DLL. It eases deployment concerns, and is a natural unit anyway. One DLL per page seems excessively granular.

OTHER TIPS

apply the concept of "separation of concerns" if possible, meaning the businesslogic could be in dll, data access layer another and ui for another ...

this might come in handy if you happen to lose the source code ... when decompiling the dll might be easier.

Licensed under: CC-BY-SA with attribution
scroll top