ASP.NET website technical layout versus classic ASP
-
Hello. I've read some articles in internet concerning this subject but, as far, I haven't reached to a conclusion. The topics I would like to clarify are the following: - In classic ASP all the code is written directly in the ASP pages. If changes have to be made, only the corresponding page will be updated. In the other hand, an ASP.NET project generates a DLL file with all the code behind compiled. When a single ASP codebehind file is updated, the DLL has to be recompiled and replaced. If two persons are working in different pages in the same project they are working on the same dll file, although the changes are for different pages. Will this constitute a problem that may generate inconsistencies? When developing a website, is it advisable to sub-divide it in many projects in order to have many independent DLLs, or just one project with the whole website code in it, and thus just one DLL file? - In classic ASP the pages may access components that are registered in COM+ Component Services Manager. This ensures the support for object pooling (the reusability of component instances) and distributed transactions. In ASP.NET, apparently there isn't a direct support for these features on .NET managed components. The alternative I've found is to use .NET Enterprise Services to wrapp the managed components so that they are visible to COM+. From what I've read, the disadvantage of this solution is the overhead of the communication between managed and unmanaged environments. If there are many simultaneous connections to the website and a lot of intensity in component instance creation it may lead to bad performance. In actual enterprise scenarios what is the common layout, or what is best advisable for assuring performance (object and connection pooling) and distributed transactions in a .NET website? Thanks for your help.
-
Hello. I've read some articles in internet concerning this subject but, as far, I haven't reached to a conclusion. The topics I would like to clarify are the following: - In classic ASP all the code is written directly in the ASP pages. If changes have to be made, only the corresponding page will be updated. In the other hand, an ASP.NET project generates a DLL file with all the code behind compiled. When a single ASP codebehind file is updated, the DLL has to be recompiled and replaced. If two persons are working in different pages in the same project they are working on the same dll file, although the changes are for different pages. Will this constitute a problem that may generate inconsistencies? When developing a website, is it advisable to sub-divide it in many projects in order to have many independent DLLs, or just one project with the whole website code in it, and thus just one DLL file? - In classic ASP the pages may access components that are registered in COM+ Component Services Manager. This ensures the support for object pooling (the reusability of component instances) and distributed transactions. In ASP.NET, apparently there isn't a direct support for these features on .NET managed components. The alternative I've found is to use .NET Enterprise Services to wrapp the managed components so that they are visible to COM+. From what I've read, the disadvantage of this solution is the overhead of the communication between managed and unmanaged environments. If there are many simultaneous connections to the website and a lot of intensity in component instance creation it may lead to bad performance. In actual enterprise scenarios what is the common layout, or what is best advisable for assuring performance (object and connection pooling) and distributed transactions in a .NET website? Thanks for your help.
Sorry, I answered this at length and CP lost my answers to the 'sorry, too many users' message. Short version - you have nothing to worry about, you should definately not use ASP - it is crap. Christian Graus - Microsoft MVP - C++
-
Sorry, I answered this at length and CP lost my answers to the 'sorry, too many users' message. Short version - you have nothing to worry about, you should definately not use ASP - it is crap. Christian Graus - Microsoft MVP - C++
-
oh that's too bad those posts were lost. Anyway, the main question would be (just to put it in a simple direct topic): Should Enterprise Services and wrapping .NET components to COM+ be used or not? Thanks.
PeteConc wrote:
Should Enterprise Services and wrapping .NET components to COM+ be used or not?
We use Windows Services for some tasks, there's no tangible performance hit for doing so. But overall, I'd do that only where I needed a backgroun task that ran independently of the web site. Otherwise, I'd steer clear of COM interop if I could, just because I don't see a reason to use it if I can stick to managed code. Christian Graus - Microsoft MVP - C++