7

In a data access layer, that queries a database and returns an enumerable object of results, what are the advantages of returning say a list of Dog objects with properties Name, Age, etc, instead of a DataTable that has columns like "Name", "Age", etc ?

Brian Smith
  • 153
  • 1
  • 4
  • 3
    The fact that a POCO gives you a list of Dog objects with properties Name, Age, etc, instead of a DataTable that has columns like "Name", "Age", etc. – John Saunders May 06 '11 at 16:08

4 Answers4

9

A few:

  • Type safety
  • Serialisation not just to XML but JSON, binary ...
  • Readability
  • More light-weight
  • Ability to add behaviours
  • Ability to define DataAnnotation and validation logic
  • Ability to use ORMs
Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • when you mention serialization, are you referring to some .net automatic ability to serialize POCOs, but it doesn't know how to serialize DataTables ? – Brian Smith May 06 '11 at 19:24
  • That ia right. Serialising poco is automatic u just need to use the right serialiser – Aliostad May 06 '11 at 21:02
7

If you use a plain DataTable, you end up with magic strings everywhere (even if you use constants). The code to extract the values ends up being clumsy and error-prone, basically because you end up having to supply data (names, expressions etc) where you're really trying to express code.

Any time you call DataTable.Select or DataTable.Sort, or access the DataRow indexer, imagine how much less fluff - and less potential for error - there would be if you were using a strongly-typed model. This could be a strongly-typed data set of course, but even then I find there's generally less friction with POCOs.

Additionally, POCOs typically require less fluff to test code with than DataTables.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • It sounds like POCOs are superior. Why would one ever want to use data tables? Are they just a relic of the past? – The Muffin Man Jun 28 '16 at 01:45
  • 1
    @TheMuffinMan: Not quite... if you don't actually need to do anything with the data other than show it in a grid, for example, it's simpler to just use a `DataTable`. Or if you're using queries with a dynamic shape. If you're used to Json.NET, it's like using `JObject` instead of deserializing to a specific class. – Jon Skeet Jun 28 '16 at 05:19
  • 1
    @TheMuffinMan write a class which can represent a csv file, but have more than 1 file, aka like excel with sheets.... so rows, check, columns, check, ok now how do you store columns of unknown types..., please show me how "POCOs" can achieve this. What you are talking about, is when you have a known data/type structure. built a csv mapper of which the csv is dynamic and flexible. so no they not superior they are used in different situations. – Seabizkit Dec 11 '19 at 18:34
1

If you use objects instead of DataTables, you get strongly typed results and makes the code using the data a lot cleaner. You won't have to have all sorts of strings in order to access what should just be a property on an object.

Also, if you use an ORM tool like NHibernate, you can map from the database directly to your objects without having to manually call out to the database and deal with SqlCommands, etc..

Rex Morgan
  • 2,979
  • 2
  • 21
  • 32
0

It separates your business logic from your persistence layers.

So your 'Dog' object, and most of the code that uses it, can just concern itself with Dogs and Doginess, and not worry about which ever flavour of data access is fashionable this week.

Will Dean
  • 39,055
  • 11
  • 90
  • 118