It must have been almost 10 years ago. I was composing an email to a colleague telling him how excited I was about this new .Net thing that Microsoft was releasing. Several months later, I found myself in a meeting when someone of some import asked me if there was any good reason to upgrade to .Net. His staff was telling him there was no significant difference from classic ASP. Even at the time, I was able to launch into a pretty good monologue about several cool new things that .Net offered, yet I later found that I was only scratching the surface.
Perhaps a couple of years passed, I was working on a .Net 1.0 or 1.1 application, and I was evaluating several browser-based HTML editors. The application was an early version of my framework that I planned to use to manage several web sites. (If you read my future posts here, you'll learn more of this framework.) Well, in working with Telerik, the vendor I chose and eventually came to love, I posted a question to them that I'm quite frankly embarrassed to admit. Without going into the details, the answer sent me on a journey of true understanding of the .Net environment - an environment that I've truly come to love.
You see, once I truly embraced Microsoft's way of doing things, and let go of my preconceptions about how to develop web sites, my abilities began to soar. (I spoke to colleagues about how I felt like I was being assimilated into the Microsoft Collective Consciousness, and loved it!)
Note that this is a very high level article, and as such, it doesn't going into a lot of details, nor does it include any code examples. However, it is a launching point into future articles that will go into more detail, and will have code examples, so don't forget to subscribe to my blog!
So, without further ado, here are my 5 Really Big Reasons I Love .Net.
1. A Serious Object-Oriented Architecture
I've worked with the Basic programming language pretty much forever, so while I appreciate the other .Net languages, I prefer working with VB.Net since it's almost a second language for me. In the days before .Net, I tried to get some level of Object-Oriented capabilities with VBScript in ASP pages by using Windows Scripting Host components. It was far from true OO (even admitted by Microsoft), but at least it was a small step in the right direction. Unfortunately, it only made me want for more, and left me disappointed.
When I started working with VB.Net, I was practically giddy with the Object-Oriented design of the language. It gave me pretty much everything I wanted. While there are perhaps one or two OO constructs that aren't offered (such as multiple inheritance), it is true OO, and that's a good thing. I immediately launched into an effort to create Object-Oriented data access and business object classes building on what I did with the Windows Scripting Host components. With true inheritance, I was able to develop more robust code without having to worry about duplicating that code each time I needed a new class. This was great! It's just what I wanted.
With these initial efforts under my belt, I was feeling pretty good. Still, it took me quite a while to realize just how Object-Oriented the .Net environment was. When I did realize it, it took me even longer to truly appreciate it. It turns out that the Object-Oriented nature of .Net goes well beyond the languages it supports. In fact, pretty much everything is an object. The controls on a page are objects; the form inside a page is an object; the web page itself is an object; and even the user's session and the entire application are objects. Ok. Nice, but so what?
In classic ASP, a page script started at the beginning and ran to the end. If the user did something like click a button, I looked for that and handled it. Now, I had all of these events inside a page script. There were events for when the page loaded, when it unloaded, when it initialized, when it rendered, before it rendered, and even before it initialized. Really, there was a Page_Init and a Page_PreInit, but no Page_PrePreInit? (I chuckled at the time). Well, being familiar with classic ASP and other non-OO scripting languages, I just picked the Page_Load event and stuck everything in there. Simple enough.
One of the things I wanted to do with my framework was to implement certain functions that would operate across all pages on a site. For that matter, I wanted to take things even farther, and implement functions that would run across all of the pages on all of the sites I managed. For example, I wanted to connect to the database and authenticate users. I also didn't want to write this code more than once and I wanted all of my sites to benefit from enhancements to that code without having to copy and paste from site to site. This is when things started to click. I could create a class that inherited from ASP.Net's built-in page class, add in my common functions, and have all of the pages on a site inherit from that new class. That new class, which I call my Application Base Page class, implements only those functions I want to operate across all of the pages on every site I manage. If I enhance the code in there, I need only copy the class to the other sites.
Ultimately, I ended up with a pretty sophisticated hierarchy of page classes. At the very top level, each page on a site inherits from a Page Type class. Types of pages include discussion boards, chat rooms, blogs, Wiki's, etc. Each Page Type class inherits from a Forum Page class. Forums are essentially groups of pages that are grouped together so there can be discrete areas within a site that share certain characteristics, settings, and/or permissions. The Forum Page class inherits from the Site Page class, which defines functionality common to all of the pages on a single site. The Site Page class inherits from the Application Base Page class, which ultimately inherits from the ASP.Net Page class. This may sound like a bit much, but it works great. With this hierarchy of page classes, I can implement a new Discussion Board, Wiki, or anything else on any site in generally a matter of minutes. Yes, the initial design is somewhat complex, but that's the point of Object-Oriented design. I can work very hard to make something extremely sophisticated, and then use that over and over again, ultimately resulting in a strikingly sophisticated solution. Without OO, there's a definite tendency to keep things simple with the "Oh, I don't want to have to do that all over again" attitude.
2. Separation of Code and Design
Oh, how I don't miss the days of
classic ASP. With classic ASP and dynamic pages, you generally had
small blocks of code embedded inside an HTML page, or conversely, you
had large blocks of code that dynamically built large strings of HTML
and spit it out to the browser. If you had anything semi-complex, you
had one script that built a form, and another script that handled its
submission. Going back to the user with invalid data, at that point,
wasn't exactly trivial.
With ASP.Net, you have code in one place, and HTML in another. Since the HTML is built with objects, your code can perform functions against those objects. For example, if you want a section of HTML only to be visible during certain times, you can simply set it's "visible" property to "false". If you want to set a default value in a text box, you simple access the "text" property of the text box and set it to the value you want. And, if you want to dynamically create a control, like a special User Control (see below), you can create it and insert it into the page where needed.
The benefit to this separation is a significant reduction in complexity, and a significant increase in the ability to focus on either code or design at any given time. When building huge strings of HTML as I did with ASP, it could be a very complex process to change the formatting of part of the page. So complex, in fact, that I would often opt for a "less is more" approach and just stick to the basics. Now when I'm focusing on the HTML portion of a page, I can get as sophisticated as I like in the presentation. No longer do I say, "I'm pretty much just a back-end guy." Now I say, "Yes, I can make this pretty!"
3. User Controls
If I had to pick my absolutely favorite feature of ASP.Net, it might very well be User Controls as they are a huge step in Object-Oriented design. Essentially, User Controls are kind of like mini-web pages, but they're implemented in such a way that they easily can be dropped anywhere on a page just like a standard HTML control. You can create User Controls on a page to implement a login form, a menu, a "gadget", or just about anything else. Since they are their own objects, complete with their own design and functionality (controls and code), they can be developed independently from the pages they are eventually placed on. At the same time, they can be designed as components to integrate into the functionality of a specific type of page. This is a great way to break down a complex page into manageable components that can be implemented and tested independently of the rest of the page.
I use User Controls for a variety of functions. For example, on a blog page (like this) within my framework, there are several User Controls. Independent User Controls are used for the page header and footer, the page menu at the top of the page, the user login form (visible only when logging on, of course), and a few other non-visible components. There are also several integrated User Controls designed to work together exclusively for blogs. They implement the content area where these articles are displayed; the highlights, tags, and archives navigation; and the subscription interface. If I were to have developed this page without taking advantage of User Controls, it would have been significantly more complex, which means I would probably would have chosen to simplify the functionality. I guess I like User Controls because it helps me to create complex systems in a much less complex manner.
Now, to take Object-Oriented design and User Controls to another level, I started looking at how User Controls could participate in their own inheritance hierarchy, and I decided to build a mechanism for creating robust user input forms. This got me excited. If I could create a base User Control that acted as a generic form, I could implement all of the more sophisticated functions that I expect to be in a good user form without having to tediously write that code over an over again. Ultimately, I wanted a form that would verify the user is authorized to access the form and handle it if he is not. I wanted a form that would validate user input and display messages back to the user when their input fails that validation. I wanted the form to pull existing data in from the database, and to update the database when the user submitted valid information. I wanted the form to be intuitive, but also have well-integrated help. I wanted the form (when appropriate) to auto-save data back to the server so that when a user spends a long time on a form they wouldn't lose their data. Oh, and as I've stated before, I was willing to write all of this code, but only once. And, yes, User Controls made this all possible.
4. An Amazingly Robust Common Language Runtime (CLR)
As .Net supports several languages, there was a definite potential problem in that one language might end up supporting one set of features, while another language might end up supporting another. This could have a detrimental impact on a project in just having to choose one language over another in that you might not even be able to implement all of the functionality you needed with just one language.
The .Net Common Language Runtime is an incredibly huge library of classes that can be called from any language that supports .Net. The result of this huge language independent library is that you have access to a ton of functionality that is easily implemented in your application regardless of you choice of language. Some of these functions are basic in that just about any application is going to want to access them, were others are very specialized providing functionality that your less likely to need. Fortunately, to access the functionality you need, you only have to reference the specific library and it quickly becomes part of your development environment.
Some of the more common classes provide individual programming language support (VB.Net, C#, etc.), data access, string handling, email access, web user interface controls, math functions, and date/time functions. Some of the more advanced classes provide membership services, data encryption, network communication, diagnostics, drawing/graphics, and charting. And this is only a small representation of what is available.
I've found that sometimes just by looking around, you can stumble onto classes within the CLR that are really useful. For example, at one point, I needed to create unique file names. I found the GUID class, which I could use to generate random unique strings in the format of a GUID. I could have put more effort into this since I generally don't like to take shortcuts, but here was something that was certainly going to meet my needs. Another time, I wanted to make sure that certain data elements in my database were stored encrypted - just another layer of security. I started looking around to see how best to implement encryption, then I decided to look to the CLR, and viola! The mechanism for encrypting data seemed to be slightly complicated in that I had to create encryption keys, which was new ground for me as a developer. It turned out that the level of security far surpassed the level of complexity, and I had really great data encryption in no time.,
There are other times I find things in the CLR that I personally choose not to use. For example, there is a membership system that lets you authenticate users, create user accounts, handle lost passwords, and all of the standard things you would like to do with user accounts. I chose not to implement this for a couple of reasons. First, I'm used to doing this for applications. It's almost second nature. Second, I knew there were going to be times that I wanted to integrate with external user databases, so I wanted to leave myself as much flexibility as possible. And I guess the final reason is that I just didn't take the time to really investigate what was available. It's possible everything I needed was in there, but again, I was comfortable with how I was already implementing this.
Ultimately, there are a lot of classes available in the CLR. It would be prudent to anyone developing .Net solutions to periodically browse around the CLR to see what's available. Chances are it can save you some time or even allow you to implement functionality you might otherwise have overlooked.
5. Significantly Improved Performance
One of the biggest complaints of classic ASP was that it was dog slow. I know this to be true from my experience in developing the earlier version of my framework with classic ASP. It couldn't do even a tenth of what the current ASP.Net version does, and it must have been 100 times slower. When a page takes several seconds to load, you know you have a problem. Now, that's not to say that you couldn't have a fast ASP site, and in fact, there are many out there. It's just that the more your site did, the more likely it was that it was going to suffer performance issues.
According to Microsoft, ASP.Net is 3-5 times faster than classic ASP. And while the source is clearly biased, I would have to agree. ASP.Net makes better use of compiled code, and in fact, allows you to publish your web site in a pre-compiled format. Clearly, compiled code is going to run faster than interpreted code since the compilation process happens before users start requesting pages.
Another aspect of faster code is database access. I once read that the only thing that remained the same between ADO (ActiveX Data Objects used by ASP) and ADO.Net are the three letters ADO. That may very well be true. One of the biggest things I noticed when researching ADO.Net way back was that they really took performance into consideration. They added a Read-Only, Forward-Only data reader that retrieves data back from the database very quickly. By removing the abilities to write back to the database and to navigate the result set, the resulting objects performed the tasks they were designed to do very quickly and efficiently. And, of course, when you need to navigate your result set or write back to the database, there are ways to do that. The point is that you use the objects as designed to get the most impact.
Summary
I've never really been a big proponent of specific web development technologies. I've had my favorites, but I chose them mainly out of familiarity and/or availability. In the very beginning of my web development career, I didn't even use Microsoft technologies, so I don't consider myself to be overly pro-Microsoft. Over time, as I've had to address more robust projects, I've found myself wanting for much more in a development environment. The interesting thing is that when .Net came out, I felt like I was reading about the environment I would have put together for myself. And again, as great as it seemed, it was only scratching the surface.
I could go on and on about how great ASP.Net is, and over time, I will. I would like to think of this article as a launching point into other articles down the road.
If you have any questions or comments about this article, or would like to see something addressed in more depth, please don't keep it all locked up. It's not good for you. If you're a registered user of this site, you will find a comment box below. Post your comments, and I'll be sure to respond.