Strongly typed datasets vs. weakly typed datasets

Question

What is meant by strongly typed datasets in .Net? Can anybody explain with a clear and brief example?

And also, what is the difference between strongly typed and weakly typed datasets?

Unwell

Personally, I'm not sure I recommend either in most code; unless you are a: using SqlBulkCopy from in-memory, or b: writing a generic query tool like SSMS... – Froze

Have you tried looking at MSDN on this? msdn.microsoft.com/en-us/library/esbykkzb(v=VS.100).aspx – Froze

Both describe things you should not use. You should use ORM instead :) – Galatia

Answer 1

Strongly Typed Datasets are generated on the basis of a Db Schema. They consists of classes derived form DataSet, DataTable and DataRow. Db Columns become correctly typed properties of the TableRow derived class.

An Untyped Dataset simply means the direct use of Dataset, not of a descendant. All column access has to be type-cast.

There is no such thing as a Weakly Typed Dataset.

Receptive

Answer 2

Typed Versus Untyped Datasets A typed dataset is a dataset that is first derived from the base DataSet class and then uses information from the Dataset Designer, which is stored in an .xsd file, to generate a new strongly-typed dataset class. Information from the schema (tables, columns, and so on) is generated and compiled into this new dataset class as a set of first-class objects and properties. Because a typed dataset inherits from the base DataSet class, the typed class assumes all of the functionality of the DataSet class and can be used with methods that take an instance of a DataSet class as a parameter

An untyped dataset, in contrast, has no corresponding built-in schema. As in a typed dataset, an untyped dataset contains tables, columns, and so on — but those are exposed only as collections. (However, after manually creating the tables and other data elements in an untyped dataset, you can export the dataset's structure as a schema using the dataset's WriteXmlSchema method.)

Contrasting Data Access in Typed and Untyped Datasets The class for a typed dataset has an object model in which its properties take on the actual names of the tables and columns. For example, if you are working with a typed dataset, you can reference a column using code such as the following:

C#VBCopy

// This accesses the CustomerID column in the first row of the Customers table.
string customerIDValue = northwindDataSet.Customers[0].CustomerID;

J#Copy

// This accesses the CustomerID column in the first row of the Customers table.
String customerIDValue =
    northwindDataSet.get_Customers().get_Item(0).get_CustomerID();

In contrast, if you are working with an untyped dataset, the equivalent code is:

C#VBCopy

 string customerIDValue = (string)
    dataset1.Tables["Customers"].Rows[0]["CustomerID"];

J#Copy

 String customerIDValue = (String)
    dataset1.get_Tables().get_Item("Customers").get_Rows().get_Item(0).get_Item("CustomerID");

Typed access is not only easier to read, but is fully supported by IntelliSense in the Visual Studio Code Editor. In addition to being easier to work with, the syntax for the typed dataset provides type checking at compile time, greatly reducing the possibility of errors in assigning values to dataset members. If you change the name of a column in your DataSet and then compile your application, you receive a build error. By double-clicking the build error in the Task List, you can go directly to the line or lines of code that reference the old column name. Access to tables and columns in a typed dataset is also slightly faster at run time because access is determined at compile time, not through collections at run time.

Even though typed datasets have many advantages, there are a variety of circumstances under which an untyped dataset is useful. The most obvious scenario is when no schema is available for the dataset. This might occur, for example, if your application is interacting with a component that returns a dataset, but you do not know in advance what its structure is. Similarly, there are times when you are working with data that does not have a static, predictable structure; in that case, it is impractical to use a typed dataset, because you would have to regenerate the typed dataset class with each change in the data structure.

More generally, there are many times when you might create a dataset dynamically without having a schema available. In that case, the dataset is simply a convenient structure in which you can keep information, as long as the data can be represented in a relational way. At the same time, you can take advantage of the dataset's capabilities, such as the ability to serialize the information to pass to another process, or to write out an XML file.

Winch

Answer 3

I'm guessing that the distinction goes like so:

Strongly typed datasets are where the dataset knows the type associated with each column at or before the dataset is filled.

Weakly typed datasets force the dataset to guess what the type might be. In cases where a column might be null OR a number, the dataset might incorrectly guess that the intended type is a string and not a nullable int.

Selvage

A Dataset (typed or untyped) won't have to guess datatypes. – Receptive

Answer 4

Here is another simple explanation: http://allthingscs.blogspot.com/2011/03/weakly-typed-vs-strongly-typed-objects.html

Gareri