Should my class return a dataset/datatable or other?

[tig2810]

Hi
If I have a class that returns a basic set of data such as:

varchar Costcode, varchar costdescription, double costamount, double rateofexchange, datetime dateandtime and a few other int fields. All basic stuff.

What is the best return type for this class? From reading the web it seems a datatable is best and a dataset is too slow for simple data.

The datatable/set or other will be used to populate invoice prints (html/pdf) and update another sql table so i'm not looking for much functionality in the returned type.

This is already working but the code is all stuck behind a button click event.

thanks for any advice.

[Tom Gunn]

How about a list of objects that represent the data:

class Cost // needs a better name
{
    public string Code { get; private set; }
    public string Description { get; private set; }
    public double Amount { get; private set; }
    public double ExchangeRate { get; private set; }
    public  DateTime Date { get; private set; }

    public Cost(DataRow row)
    {
        // populate the object with data
    }
}

DataTable table = GetData(); // simulate reading from a DB
List<Cost> costs = new List<Cost>();

foreach (DataRow row in table.Rows)
{
    costs.Add(new Cost(row));
}

Data tables and sets are fine for what they do, but working with them directly is tedious. Code reads better when you abstract the tedious stuff away. :)

[sknake]

Using a typed data set is very slow but ones created at runtime are not quite as bad. I assume you already have this table bound to a report for creating PDFs? If that is the case then you can leave them in a datatable/dataset.

You will want to use a DataSet if you have multiple DataTables. If you do have multiple tables and go the DataSet route be sure to set .EnforceConstraints = false

[serkan sendur]

i recommend creating a dataset using the designer, then you can fill it it with your data, i think you dont even need to create a class for that, visual studio generates the required classes. and you can directly bind this dataset or datatable to your data elements on your toolbox. i would go with dataset but typed dataset. Forget about slowness, you can cache the data on the server so the next request will be fast enough.

[sknake]

i recommend creating a dataset using the designer, then you can fill it it with your data, i think you dont even need to create a class for that, visual studio generates the required classes. and you can directly bind this dataset or datatable to your data elements on your toolbox. i would go with dataset but typed dataset. Forget about slowness, you can cache the data on the server so the next request will be fast enough.

I despise the designer generated datasets. I use them for databound reports so I can preview them in design time and for a control that is basically an outlook calendar. For anything I don't have to I stay away from the datasets because of their poor performance :(

[serkan sendur]

yeah but it depends on your stored procedures as well as caching.
dataset is good as long as you use it to structure your data. you have to have paging in your t-sql statements and you have to cache the returning data, even you should cache the html output for a while using sql-cache dependency to invalidate it when change occurs in database. the time is not only spent waiting for response from the server, but also spent when developing the application, so the balance is good.

[sknake]

Yes, they are good for that. I don't have a need for those functions in my asp.net projects so I didn't consider that .. but that can all still be implemented in a slick DAL!

HOWEVER I still say datasets make the CLR cry :(

(Are you getting the impression I am one of those guys who will spend extra time writing code to avoid using a DataSet?)

[serkan sendur]

>Are you getting the impression I am one of those guys who will spend extra time writing code to avoid using a DataSet

yeah i think so :) but what is wrong with it?
it is kind of job security. there are two things to production; production capacity and production itself. production is repetition of some work, this is usually what most programmers focus. you can write 100 lines of code to do the same thing provided by the library if you dont know that functionality. But you have to stop coding to learn about that functionality, then your manager might think that you dont keep being busy. I think that is a cultural issue in the work place. Recently i offered using .net framework enterprise library 2.0 which creates the layers and patterns for you. My manager didnt like the idea of inventing new thing, i also think that if you get something done very fast, why would they need that many of programmers? it is our own job security i think. Before critisizing anything, we have to suspect the unknown.