0
votes

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?

2

2 Answers

2
votes

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.

1
votes

Just make sure that your objects contains only the necessary fields and embrace the objects if they make the solution clearer.

Any eventual performance downfall (minimal) will be compensated by potential long-term performance benefits of an cleaner and clearer solution.