Normally, when working with data from a database with a forms application, I keep it in a dataset or datatable and pull data out as needed. Now, I am working with WPF and trying to conform more to the MVVM pattern. Converting these datatables to objects make it a little easier to use with MVVM.
For example, if I had a table filled by a query like so –
Select p.first_name, p.last_name, p.phone,p.email from person as p where p.first_name = ‘Bob’
Instead of keeping the datatable, I would just now convert that into a person object.
From a performance standpoint, is there and downfall to making objects or should I stick with datasets and datatables?
The performance impact of using an ORM such as EF (or rolling your own) instead of DataTable/DataSet is negligible in applications like you’re describing, but it depends on how it’s implemented.
The main advantage of using an ORM is ensuring type-safety and not having to perform type-casting when retrieving data from a DataTable object. There are also benefits from using lazy-loading in Linq.
I don’t think that using entity objects everywhere is necessarily a solution. There’s nothing really wrong with using a DataTable object in a ViewModel (although I’m unsure how you’d use it with respect to the data synchronisation features of the DataTable class, but you’re free to not use it at all).
In a new project, I’d use EF, only because I like having the typing taken care of for me, but if you’ve got an older project using tables that works fine, I’d stick with it.