which senario do you prefer when you're retrieving data from database?

1 - Populating a datatable and then bind a datagridview to开发者_StackOverflow中文版 it?

OR

2- populating a genric list of your own custom object and then bind a datagridview to it?

Thank you

2 - list of objects :-)

reasons (or as marc notes, 'merits'):

• lighter weight
• ability to extend the list via custom class
• potential to use filters/linq to objects in a fashion that are better suited to business objects
• DataTables are Microsoft specific. If you need to pass them into a non-Microsoft, i.e. Java web service you will need to create a separate business object to pass to it.
• check out current OR/m implementations - not many datatables going on there..
• if it's a web project, then keeping the connection open whilst reading the results into the datareader is a bit of a no-no
• DataTables almost beg the developer to place the business logic in the user interface layer. Having a business rules region in a business object woos the coder into placing the business rules in the proper place.
• unit testing of your results - far easier in a custom class defined via an interface
• strong typing of properties (rather than string indexes against the datatable 'fields')

also, using DataTables directly means tying yourself to the underlying data source and how that is structured. From a maintainability point of view, this isn't a good idea. If all your view needs is a list of some objects, that's all you should be giving it (i.e. a list).

[edit] - it's an old article, but is worth adding to the 'debate':

When considering DataSets vs. business objects, remember that a well designed application using business objects will reduce future headaches in the maintenance of the application which ultimately lead to lower support costs.

http://www.kellermansoftware.com/t-articlebusinessobjects.aspx

I would not suggest working with db directly at all. There're nice ORMs: LINQ to SQL, Entity Framework and NHibernate. Who needs old painful datatables ?