I was working on rewriting an old ASP 3 application into ASP.Net 2.0 today and came into an interesting thought that caused me to look at the past 5 years of ASP.Net. Back in ye' old ASP 3.0 days, everything was inline code. Then came .Net and the trend of Code Behind files. Everything seemed good aside from the initial runtime compilation upon the site's first request. Now in the ASP.Net 2.0 world, we're blessed with the truly pre-compiled/published sites that only hold marker files in place of the traditional files that would house the mark up.
Now, looking at the history of the application that I am rewriting, this specific application tends to have a few pieces (usually just presentation layout) that requires changing on a frequent basis. Now, this is where the difference of opinion lies. Some people see these changes as a cause for a full deployment and along with that, some QA representatives would also deem that a full deployment requires a full application test (I've worked with people who demand such even if the change was only the order of text boxes). There are also others that think that one would only need to deploy only the updated files. While this seems logic, it comes with the price of having the ASP.Net 1.x initial lag once the file is accessed. In addition to the lag issue, there's also the requirement of deploying the solution in an "updatable" mode. As in most cases, this would be a trade off between security and convenience. I'll let you decide on when such a trade off is applicable.
Assuming that the convenience is agreed upon as necessary for the project, there's two ways that could accomplish this task. One is to simply replace/update the markup of an ASPX or ASCX file. While this is great, what if the UI needed to change from a drop down list to a series of cascading drop down lists to obtain the "same" value in a more refined manner?
At this point, I would advocate a full deployment in order to maintain a consistency of code (or in the case code-behind); however, curiosity got the best of me on this one. :)
Never trying it myself, I created 2 simple user controls where the code was inside of a <script runat="Server" > tag. I chose to Register the controls via Web.Config instead of directly on the page for a single location, should I find myself wanting to use the control elsewhere. Upon updating the SRC of the registration entry, the user control flips.
After doing this, I realized that it would work if I modified the user control logic a bit. Many developers create user controls that are nothing more than a segmented section of the page that houses it. This tightly couples the control to the page and is considered a bad practice in many groups. A better way is to just encapsulate the functionality of the control so it doesn't rely on any external piece of information. Yet an alternative way (and the way that arguably works best for this situation) is to create the user control where any data that would need to be passed to the page itself be exposed through properties and events. Ensuring that all controls that a person will be swapping out implement the same interface(s), the page's code behind should be able to implement the logic without a full deployment needed.
Base on this information, I'd have to argue that Code behind with a non-updatable deployment may be the best and most secure form of deployment, there may come a situation where it's not the best option.
No comments:
Post a Comment