One of the nice things about using ASP.Net controls in place of standard HTML elements is the ability you gain to do server-side access, manipulation, and processing related to those controls. Let's consider a fairly simple page and look at how the coding process would work in the PHP world and in the ASP.Net world. Then I'll get to my complaints :)
Our simple page will consist of a dropdown selector and some corresponding text input fields. Based on the value of the dropdown selection, we want to populate the text input fields with data from our database.
In the PHP world, a good solution for this situation is to create the main page in HTML. Then you would attach javascript functionality to the dropdown, likely using the onchange event. Something like this:
Then in your javascript, you would provide the functionality to do something with this. Since we want to use it as a key to pull data out of the database, our javascript will basically be a pass through to send the data to our server-side PHP handler code, and then process the result back out to the HTML. Something like:
Then we finally do some PHP. We want a simple script that processes the input coming in, pulls the corresponding info from the database, and then writes the output as a stand-alone block of HTML. Our PHP could look like:
So in PHP, we have three distinct pieces: the HTML that presents the page to the client, the javascript that processes the interactions between the HTML and the server-side code, and the PHP which handles the javascript input and returns the appropriate output. There's a lot we could do to optimize this, such as using JSON to return smaller bits of the results and assign them as the value of the textboxes instead of rewriting the whole block of HTML. But that's not the point of this blog post, so I'm keeping things fast and simple.
In ASP.Net, it's different*. Instead of these three pieces, you have two pieces: a code-front (consisting of HTML elements and ASP.Net controls) and a code-behind (consisting of the functions that the server runs). You don't have to do the javascript processing code, as ASP will create its own javascript and do the attachments to the ASP.Net controls automagically.
*Note: It is certainly possible to do the three-piece approach in ASP.Net as well. You could completely replicate the PHP methodology through an ASP.Net HTTP Handler and avoid the user of ASP controls in favor of using standard HTML elements. The process of doing this would be extremely similar to the PHP process, and it would have most of the same good/bad points.
The code-front would look pretty similar to the HTML we had before:
The code-behind is actually a lot simpler than the PHP. Other than the difference in SQL syntax (which I'd just ask you to ignore, as this post isn't about LINQ to SQL), one big difference is that we can set the values directly to the ASP controls. There's no need for a javascript middleman:
All of that is well and good. The simplicity is great, and it is shorter code. But the really nice thing is that this difference only grows as you start doing more complex tasks. Smaller server-side code combined with minimal need for a javascript processor makes for some great savings in development cycles. But, of course, there are some drawbacks. Next time, I'll touch on the ones that bother me the most, as well as some possible solutions.
No comments:
Post a Comment