Using strongly typed data in VS2005 and asp.net2.0

First, Introduction

As a developer, when we are learning new technologies, examples may be our biggest enemies. Tutorials are often designed to be easy to understand, but at the same time they often reinforce lazy, inefficient, and even dangerous coding habits. There is no better explanation for the problem than the ado.net example. In this article, we will be ready to analyze the significance of strongly typed objects for your database development and why you should use strongly typed objects in your application without an example.

Specifically, we will analyze how strongly typed datasets are created and used in Visual Studio 2005. As discussed in this article, strongly typed datasets offer many advantages over other, weakly typed data access technologies, and with Visual Studio 2005, it is easier to create and use strongly typed datasets than ever before.

Two, strong type Object Foundation and merit

To understand the meaning of the strongly typed, let's consider the example of a date first. If you are a bachelor, what kind of person do you expect to date? You may already have your own specific criteria, such as being rich and attractive or perhaps living in a superior and sexy environment. No matter what your condition, when you decide who you want to spend more time with, you will inevitably have a set of dating standards. If you're smart, you can make a list of carefully thought-out lists that can help you save unnecessary emotional effort. Adding a "non-alcoholic" condition to your dating criteria will save you a lot of time and allow you to spend your time and energy on dating better candidates.

You may wonder, how can this be compared to programming? Please listen to my explanation. Ado. NET data Access object is designed to achieve maximum flexibility. Unless you get into a lot of trouble, when you read data from a database, you use a lot of ordinary, untyped objects--of course. NET Framework is fully permitted to do so. Using our dating analogy, always treating your relational data as a generic object is a bit like admitting, "I only date people who meet my criteria." Can't you just relax some of the conditions a little bit? As your friend, I must advise you to "set some standards first and then refine your list!" "Perhaps better."

Just as ignoring the ability of the person you want to date can lead to future relationships, keeping the "loose coupling" of your objects can bring errors to your code. Also, because if you let any old object "go out" with your subroutine, you may not know the problem until your application executes at run time. In our date-dating analogy, catching bugs at run time is much like having a painful and embarrassing discussion with your date in a trendy Italian restaurant. Yes, you have found the problem, but if you have planned it beforehand, your results will not be "a group of diners staring at you, and you are covered in Italian meatloaf." If you simply apply some tighter criteria to your code, you will be able to catch errors before your application starts running (at compile time). For example, consider the following sample code:

String FirstName = Myrow. ("FirstName"). ToString ();

The above DataRow is untyped; As a result, you must access the value in a string form as the name of the column you want to query (or use the index value of the column in the column collection). It is possible that this column really exists. The data type of a DataRow column is an object; we assume that the basic data type of the FirstName column is a string, but we have to explicitly convert it to a string to use it. If the column name changes (for example, you change it to Personfirstname), then the compiler cannot notify you. Don't do this! So if your code looks more like the following form, your life will be easier and your code will be more reliable:

string FirstName = Personrow.firstname;

In the second example, we have a strongly typed row, and we know that the FirstName property is a string type. Here, there is no messy column name, and there is no messy object conversion problem. The compiler does type checking for us, and we can go on with other tasks without worrying about whether we've entered the column names correctly.

This is also true for all other columns; In short, you should never use a generic object when you can use a more specific type. But wait a minute, please. Where does the strongly typed object originate? I think I can tell you that these objects are created automatically for you. However, just as it takes time and effort to build a good relationship, it takes other efforts to strongly type your object. The good thing about it is that the extra time spent here is worth it, and it saves you more time to spend on debugging in the future.

There are several ways to implement a strongly typed method, and in the remainder of this article we will discuss how to create a strongly typed dataset in Visual Studio 2005, and, of course, analyze the pros and cons of doing so.