Still not convinced? Here are some additional benefits of this architecture:

Benefits of the Architecture

1. Unlike an ASP.NET UpdatePanel we only pass what we need; we only receive what we need. We don’t pass ViewStates, in fact we don’t even have a ViewState. We also don’t pass entire HTML chunks and receive HTML chunks we don’t use. For more on this; read: Why ASP.NET AJAX UpdatePanels are dangerous.
2. By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests that's included when you use ASP.NET Ajax.
3. Less dependencies – because all our code is simply xHTML we could switch to a PHP or a Java backend and none of our code for the UI would have to change. That's right, there are no server-controls; that means no GridViews, no Repeaters, no ListViews, nothing that uses runat server will be found on the page. Not even a ScriptManager.
4. Usability – We can create RIA interfaces AND maintain usability, giving us the best of both worlds.
5. Cross-Browser friendly – We use nothing but xHTML code and jQuery which works across browsers.
6. The entire presentation for the UI is done via CSS. Change the CSS and the entire UI can look different.
7. We maintain a 'Separation of Concerns' - this means we have 3 distinct and wholly separate code bases. A content or HTML level. A presentation or CSS level and a behavior or JavaScript level. We don't have code mixed together in a web-page jambalaya.
8. Switching architectures from Web Forms to MVC is a breeze.

Hopefully you are salivating at these benefits enough to decide to get your feet wet and follow along.

In this article will be leveraging these technologies to build a grid (or what looks like a table). Later on, in future articles, I will then show you how to implement sorting, paging and filtering on the grid. I have divided this article up into four sections: 1. Sever-side code (ASP.NET). 2. HTML 3. jQuery and lastly CSS.

ASP.NET

In this article I will be using LINQ to SQL to query the database and return a collection. LINQ to SQL allows you to model a relational database using .NET classes. You can then query the database using LINQ, as well as update, insert and delete data from it. LINQ to SQL fully supports transactions, views, and stored procedures. If you're not familiar with LINQ then I will refer you to these articles: Using LINQ to SQL (Part 1) and LINQ to SQL - 5 Minute Overview.

The goal of this article is not to teach you LINQ. But I will say that if you are not using LINQ and you are still using a DataReader or DataSet to access your data then shame on you. Simply put, I believe LINQ is the coolest technology Microsoft has come out with in recent years.

And the best news is, it's EASY to use. Let's look at the code:

The first thing we do is create a class called CourseReservations. This class contains all the properties we will need to create our grid on the client. In other words, these will become our columns. The next part is our LINQ statement. This code uses LINQ query syntax to retrieve a sequence of GolfReservations for a given course. Note how the code is querying across the GolfReservations / GolfCourse / Aspnet_User / GolfUser relationships to retrieve all the data we need from our tables, and we didn't have to write any SQL filled with JOINS to do it.

We then return a list of CourseReservations. What's important to note is that our list will get automatically serialized to JSON. How fantastic is that? Before we move on, also note the name of our method: GetGolfCourseReservations(). This is what we will call via Ajax using jQuery.

HTML

That's right, just a simple unordered list with an id of "reservationsList" and class of "stripedList". We don't use any controls, nothing with runat="server" will be found on the page. This way we don't have any ViewState taking up load time, nor do we have Microsoft inserting JavaScript into our page without our consent. Our page, at least on the front-end, is devoid of ASP.NET or any other language. Nothing but pure HTML. If we ever have to port to PHP or JSP we wouldn't have to change a single thing on the UI side.

jQuery

Let's look at the jQuery code now. Bit by bit.

Notice the SendAjax() method's signature. It takes three parameters, the first urlMethod is the path to the Web Service followed by the name of the Web Method. It should look something like "webservice.asmx/webmethod". The second parameter jsonData will be exactly that, your JSON data. More on this later. The final parameter returnFunction will be the function you wish to call after the return trip from the server.

The $.ajax() method performs an asynchronous HTTP (Ajax) request. You can read all about it here, but for now, just know it's the liaison for the client / server relationship; or the Ajax call.

We will use this light, but powerful SendAjax() method over and over again each time we wish to go to the server.

This function is simply used to stripe the rows. Every other row will be colored differently in our grid. You pass it a list, it then finds all the list items in that list and removes a class. It then adds a class to all the even list items. The reason why I removeClass() from all list items first is so that if you ever add or remove list items (dynamically) to the grid you don't get them all messed up colorwise.

If you are new to jQuery then you need to start by understanding $(document).ready(). You can read all about it here. But the bottom line is that everything inside this method will load as soon as the DOM is loaded and before the page contents are loaded. This is extremely efficient because we don't have to wait for images or content to load, just the DOM elements. Again, if you are new to jQuery start by understanding the $(document).ready() method.

We are telling it to call the method GetGolfCourseReservations() as soon as browserly possible.

The three lines in the GetGolfCourseReservations() method will become very familiar to you in this methodology. Recall that urlMethod is the path to your web service and your web method. You do remember our .asmx file contains a web method called GetGolfCourseReservations? Good. The next line with jsonData is the JSON that we are passing in. Note that if you are not passing any data, as we are in this case, you must still have the empty curly brackets. Finally, the third line is our call to SendAjax() method. Notice the third parameter: ReturnGetGolfCourseReservations. This is the method to be called on the round trip from the server. Conveniently you will find this function one line down. I always keep to this standard.

In our ReturnGetGolfCourseReservations method we loop through the returned JSON and create our rows or list items. We then drop our list items into our unordered list and lastly call our method to strip the rows.

TIP: Two tools that are indispensable for this methodology are Firebug and this JSON checker. Without Firebug you will not get far. It allows you to see all your Ajax calls, the post, the request and the returned JSON. Get it and learn it.

CSS

Lastly, let's look at the CSS involved to make our grid look pretty. Do note that we could have used a table instead of a list very easily. It's your choice.

Most of the CSS is pretty straight forward; we stylize our list-items and use spans as our cells. The classes .c1, .c2 ect. allow us to assign a width to each column.

The Take Away

What I really want you to take away from this article is all the benefits gathered from this methodology. When I build Web-based apps the thing at the front of my mind is speed. It's all about speed. Nobody likes to wait for anything these days, on the web or off. This is about as fast as you can do things. In addition, we have nice clean code that adheres to the separation-of-concerns. On the front is just good old HTML, probably the first thing you learned when creating websites. On the back-end is our Web Service that does our actionable request: get, save, update and delete. That's all it does, it knows nothing about the UI, unlike a typical ASP.NET page with its CodeBehind page that is all aware of the UI and talks to it. If we ever had to change over to an Apache server and use PHP we wouldn't have to change a thing on the front-end, simply our methods on the back-end would change.

We allow our CSS file to control the way the entire application looks. Once again, compare this to many typical ASP.NET apps that use Web Controls and want you to set presentation properties either in the .aspx page or the CodeBehind page. Yuck. Never do that.

Lastly, not only is our code fast and clean, but it's also lean. When you get good at this methodology there is usually a lot less code. Less code is always a good thing.

For example, let's say you have a div with an id of "contentTop" like below:

Because you have made the control a server-side control by adding the runat="server" attribute it will now be rendered with a different ID when it hits the browser (view the source code and you will see). It will get rendered as something like this:

This is because ASP.NET generates its own IDs to ensure that every element on the page has a unique ID. Developers that work with JavaScript and CSS will immediately see the problem. This causes difficulty when using JavaScript and CSS which rely on those IDs to reference elements, as they can't easily predict what the generated ID will be. When it comes to CSS specificity the ID selector is extremely useful. In addition, anyone that uses JavaScript knows that getElementById (or one of the JavaScript library ways) is the most popular way to target an element. So why the hell does ASP.NET do this to us? Honestly, I can't really tell why, other than the fact that they must not trust us enough to be able to uniquely ID our elements ourselves.

But I don't want to just complain here, I would like to provide some solutions too.

Solution

The solution will be found in the ClientID property of the server-side control. The ClientID property represents the ID that ASP.NET will use for the element on the client.

Using the ScriptManager we place the ClientID in a hidden form field. This can all be done in the code-behind file by using the following code:

Be sure to have included the ScriptManager to your page, like so:

Now we can use JavaScript to retrieve the value from our hidden form fields.

That's it, if you know of another way, please let us know.
Happy coding.

Automatic properties provide you with a shorthand for defining a new property. No more do we have to create the private property and then use Getters and Setters to access and set that property. Here's the old code:

Now here's the code using automatic properties:

Oh my! How nice is that? The C# compiler creates the Getters and Setters and the private fields for you automagically!

2. Initializers

We've talked about initializers before, but let's review anyway. You can use initializers to reduce the amount of work it takes to create a new instance of a class. Instead of this:

We can do this:

Short and sweet -- the way I like it.

3. Type Inference

This new feature takes a page out of JavaScript's book. When you take advantage of type inference, you allow the C# compiler to determine the type of variable at compile time. Here's an example of how you use type inference with C#:

Looks like JavaScript eh? Notice that we didn't declare a type? The C# compiler can infer the type of variable (it's a string) from the value you use to initialize the variable.

No performance impact results from using type inference. The compiler does all the work figuring out the data type at compile time.

Notice the use of the keyword var? You declare a variable of type var when you want the compiler to figure out the variable's data type all by itself.

Enjoy those three shorthand shortcuts and happy coding.

Here's some typical code to initialize an object:

Stud mark = new Stud();
mark.Name = "Mark";
mark.Hotness = 10;


Here's the new C# 3.0 object initializer way:

mark = new Stud() { Name = "Mark", Hotness = 10 };


This does exactly the same thing as the three lines of code above, but in one line! And the IDE (Visual Studio 2008) even helps out with IntelliSence showing you the fields available. Pretty cool eh? If you're running Visual Studio 2005, then this won't work.

What is the difference between a struct and a class? When should you use a struct versus a class? How do you know?

What is the difference between a struct and a class?
It is simple, structs cannot be inherited from or extended. They can have properties, private variables, methods, and even constructors and deconstructors. Unfortunately, that is where they end in their likeness to classes. Classes on the other hand are extensible and can be inherited.

Finally, it should be mentioned that structs are stored on the stack as a by value type and classes are stored on the heap as a by reference type. What you do need to know is if you copy a struct to another variable, you will now have two copies of the entire struct in the stack, causing a performance hit (depending on the size). For a class, this is not true, the second variable gets stores the address to the original heap location, thus no performance hit.

So when should you use a struct versus a class?
Whenever you do not need extensibility or inheritance. As for the "How do you know?", you are the architect; during your analysis take into consideration what you might be able to re-use in the future.

The nice thing about classes are their advance functionality. You can extend upon them creating large webs of functional objects and you can use them as a refactoring foothold to make smaller chunks of reusable code (modularization). For example, let's say you have a class called "Person". This class contains information such as "First Name", "Last Name", "Middle Initial", "Birth Date", and "Gender".

Now let's say you want to extend that class to have "Customers" and "Employees". You would inherit the "Person" class and extend it with the additional information you want to store. Let's say the "Customers" class should have an "Account Number", "Credit Card Number", "Credit Card Expiration Date", and "Credit Card Type". The "Employees" class would have an "Employee ID", "Email Address", "Title", and "Department". Now if we didn't use inheritance, all of this extra data would all be in the "Person" class, and that would just look busy.

So here is the Employees and Customers classes:

Now that we have covered inheritance to show how to extend a class, let's tackle abstraction. Abstraction provides a mechanism to define methods that MUST be created by anything extending it. For example, let's say the "Person" class wanted to abstract the method to display the "Full Name". This way the "Customers" class must write it's own "Full Name" method and so must the "Employees" class.

Due to the abstraction, our "Person" class needs a few changes:

Now keep in mind that abstract classes can have non-abstract methods, however, you cannot create an instance of this class, it must be inherited.

Finally, interfaces solve the biggest problem with objects. In C# and PHP, you are only allowed to inherit from a single class, however, you can implement an infinite number of interfaces. Interfaces like abstract classes cannot be instantiated, they can only define the method definitions; they cannot actually implement the methods.

There you have it, in this article we learned how to use classes to extend, abstract, and interface your code to make smaller chunks re-usable and extensible.

History:
07/13/2007 11:44 AM
Added information denoting that structs are stored on the stack and classes are stored on the heap -- hat tip to Ramjee.

What language should I use to program my next project?

As someone who has been on a few of said forums, mailing lists, and chatrooms for a while now, I hate seeing this question. Yes, it comes around a lot, but repetitiveness isn't what bugs me about it. What bothers me is that there's usually very little background information attached to that question, which makes it as open-ended as asking what mode of transportation you should take to get to the store. I can tell you anything from a skateboard to a jet and either vehicle can get you to the store, but to give you the best answer I need to know how far you have to travel, what you plan on buying, and how much money you have, among other things. The same holds true for the programming language question, so let's look at some factors that can help you choose which language to use on your next project.

What do you want to build?

This should be the first question you ask yourself when choosing a language, because some languages are better at some things over others, and some language just plain can't work in certain contexts. Are you building a desktop application? If so, you might want to look at a language like C++ or Visual Basic over say, PHP. Conversely, for a web application, PHP or Ruby (optionally with a nice framework like Rails or Symfony) will get you up and running much faster than trying to write your own CGI handler in C.

Some languages, like C# or Java, try to do it all, so this question may not lead to one clear answer for you if those are among your options. Keep them in mind, and try to filter your selection down with the following questions.

What platform(s) am I going to be running on?

This is almost as big of a decision-maker as the kind of program you're writing. Some languages only work well on one platform, so if you're on another platform the choice gets limited pretty quickly. For example, if you're writing a Windows program you might not want to learn Objective-C and Cocoa, which is a programming framework for Mac applications. Conversely, if you're building a website that is intended to run on a Linux server, PHP is a much better option than C#. Many languages, like Python and Java, are cross-platform, so at first it may not look like it matters, but look closer. Some server-side languages might "work" on Windows, but with Apache and not IIS, or may not perform well on Windows relative to Linux/OS X. Yes, it might still be possible to work in a language on a second-class platform, but it might be more painful than it's worth.

What do I already know? Do I like it?

Prior experience is also a good way to gauge which language you should use. If you like a C-style syntax, the style of a language like Ruby or Visual Basic might make you scream and run back to the safety of curly braces and semicolons. On the other hand, if you've been writing Java code for the last 7 years and are TiredOfTheVerbosityOfItAll, then maybe a more terse language like Python would be a nice change of pace.

Does the language have features for my project?

Look at your project and see what your needs are. Is it a simple frontend to a database with a couple of forms? Well, just about any language is capable of handling something like that nowadays. Do you have to deal with processing large amounts of text? Well, Perl was built just for that so maybe it's worth a look. Different project requirements may make you decide to switch it up.

To conclude...

I'm not here to tell you which language you should choose. You and I may look at the same project and end up with two completely different ideas about which language is best to go with. I don't expect people to run through this process every time they come across a new project, but hopefully this article gives you something to think about when you decide you want to start playing with another programming language.

Often times when you belong to a forum you start stalking certain people. Every time the person you are stalking post and you notice it, you go read what they have to say because you know it's going to be good. Well, Louie was the first person I ever stalked

So when I was putting together the Search-This team I knew that I had to get him on board, it makes it easier to stalk him that way! We're glad to have you on the team Louie.

Enjoy Louie's bio below:

User Name: louissimps

• childhood ambition: marry a rich woman
• fondest memory: going to my grandpa's ranch
• favorite music: a little something from every genre
• retreat: the ocean
• proudest moment: the path I have lead so far
• biggest challenge: not going to college
• alarm clock: 6:50(snooze until 7:45)
• perfect day: coffee, surfing, lunch with my wife, afternoon nap, head to my favorite bar
• first job: busboy at a banquet hall
• indulgence: Belgian Ale
• favorite movie: too many to name, Super Troopers, Napolean Dynamite, Platoon
• inspiration: accomplishment

I'm a programmer (PHP and C#), but am really average at best. You aren't going to get some life-changing "aha" code examples from me. I do try hard and I'm always trying to learn better practices. I am a firm believer in knowledge is power and the more knowledge I have on a certain topic, say OOP in PHP for example, the better armed I am for battle! What I love about programming is solving problems and of course just the ability to make things happen. My favorite part of the lifecycle is the application and database design. So, there is a good chance you will see some examples of design documents from me.

I'm a blogger and am completely fascinated with how blogging and other forms of social media are changing the way businesses, well, do business. I have several places I blog at, both personally and professionally, so you may say I'm a bit of an addict. When Mark waved the needle in my face, it was hard to resist . You are likely to see me write about topics like this and I will try to illustrate how businesses can integrate blogging and social networking sites into their marketing plans.

I'm a business-woman. I am a partner in a Web development company, brainyminds. I started the business 4 years ago and we provide web development services to businesses and individuals. We were recently recognized as an Authorize.net Certified Developer, which is pretty cool as there are currently only 12 other companies who we share that title with. I may talk about working with clients, bidding on projects, and documentation.

I'm a life-long learner. A big reason I got into this field is because it will always be changing, providing me ample opportunity to continue learning. I may write reviews of industry-related books that I'm reading or share some great info that I have found that has helped me. I like to learn, but I also like to share what I've learned. From the search engine perspective, the most frequent terms that lead people to my personal site, ilovecode are error codes from people who have encountered an error in their code. I have posted examples of errors I have encountered and their solutions. It makes me happy if I can save other people of going through the frustration that I've encountered. I may share those here as well.

I'm a wannabe website publisher. This statement may be confusing as I already own websites that I've built, but what I really want to do is launch some websites that can earn decent recurring revenue. There are so many topics that I could talk about related to this field. SEO is something I am continually trying to improve on. I know the basics and I employ them, but there will ALWAYS be room for improvement. Ad networks is another area that could be discussed. I am a complete novice when it comes to making money from your websites using advertisements. I will talk in general about my experiences and also seek advice from you! There are several other topics that I will hit on too. I have a content website in the works currently so be prepared for me to talk about that, successes and failures both.

Hopefully that gives you a glimpse of what to expect from me. I look forward to starting a conversation with you.. after all, that is what blogging is about, the conversation. So, don't be afraid to comment!

Matt's passion has always been as a coder. Now that Matt has graduated college and become a full time software engineer there's not many languages he hasn't worked with.

Look for Matt's, or rather cpradio's first article this Monday titled: "OOP in PHP from a .NET OOP Perspective" - should be a good read.

I can't really welcome cpradio as a new member to the team, because he has always been part of the team. So just enjoy his bio below.

User Name: cpradio

• childhood ambition: to be a software developer, seriously, it was...
• fondest memory: looking at my old code and just realizing what an idiot I was back then
• favorite music: anything but elevator music, seriously, how do you not fall asleep to elevator music?
• retreat: hiking in the smokies
• proudest moment: three weeks of hammering an application, countless thankful users
• biggest challenge: writing quote engines for an insurance company and making it easy to maintain
• alarm clock: 6:30 AM on a good day, 4:30 AM on implementation day (project going to production)
• perfect day: my wife told me it was her wedding day, err... our wedding day.
• first job: PetsMart stocker/fork-lift driver
• indulgence: hard drives, I have 10 (in one PC) equaling 1.8 TB but that is not enough
• favorite movie: geez, I can't just pick one, that would be unfair to the rest of them
• inspiration: knowing knowledge has no limits other than a person's refusal to continue learning