Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm developing an application handling DB parts. I retrieve the data from the DB with stored procedures and prepared statements. Now I want to display the data in the GUI.

What is the current technology used for that? Does one still use DataSet and DataTable for that?

share|improve this question
What's your GUI technology? –  Oded Jan 8 '13 at 13:31
I am using WPF. –  juergen d Jan 8 '13 at 13:32
MVVM is pretty much the pattern to be used with WPF. –  Oded Jan 8 '13 at 13:38
add comment

2 Answers

There are different tools and different patterns.



ADO.NET is much more than DataSet and DataTable. I would not use those classes in any project but instead use the IDataReader to populate pocos as I describe here: http://blog.gauffin.org/2013/01/ado-net-the-right-way/

Data mappers

The next step is to use a data mapper. What they do is to let you write SQL statements, but they will automatically return POCOs to you. Either as a dynamic representation or as T4 generated classes. (You can also map your own classes)

Some examples are Massive, PetaPoco and Simple.Data.


Object/Relation mappers are the most complex approach (complex as in creating). They take care of everything for you. Most OR/Ms also has a LINQ to SQL provider. That is, you can write LINQ statements which then are converted to SQL.

Entity framework for instance has a visual designer in which you can point at the tables/columns that you want to get classes for. Hence it's quite easy to get started.

Examples: Lightspeed, Entity Framework and nhibernate.


Patterns help you structure the code in the data access layer.

Repository pattern

Repository pattern is quite old but still a relevant pattern. The idea is to abstract away the data access to reduce coupling and complexity.

Query object

The query object pattern is used to create a class per query. For instance, it makes it easier to see which parameters are required (constructor arguments) and which are optional.


Command/Query separation is a way to separate querying (fetching) and commands (storing) information. It's not just a data access pattern but a way to structure your application.


CQRS is similar to CQS but takes it a step further. It uses separate models (databases) for reads and writes. The read model is typically generated with the help of events from the writes.


In WPF you have view models which you use to map the GUI to your data access. You use ObservableCollection to get a GUI which responds to changes.

In the view model you'll use any of the tools that I described above (directly or through one of the described patterns).

Additional info

I've written a blog post about the data layer here: http://blog.gauffin.org/2013/01/data-layer-the-right-way/ where I discuss the data access.

imho stored procedures are obsolete. Parameterized queries are in many databases as fast as stored procedures.

share|improve this answer
add comment

What is the current technology used for displaying Data? Does one still use DataSet and DataTable for that?

Well, taking into account your project needs it can really wary what to use, and what client design pattern to choose from.

However, the main point is not to over-complicate things (project design) that you are planning to achieve. Because, each design pattern has purpose to solve some common business problems, and implementing them for the sake of saying stating that project uses blah.. pattern has no value at all.

This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages. Far from it, often they not only add clarity and maintainability they also improve performance. But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant.

Thus, my advice would be to practice KISS and YAGNI principles.

Regarding MVVM pattern: It is a pattern designed to solve specific business problem which are combined under the term separation of concerns. Thus, you may consider it if it suits your project. For more readings on MVVM technical descriptions you may look here.

A good reading that may help you to clarify your decision regarding this pattern to look is - WPF Apps With The Model-View-ViewModel Design Pattern.

share|improve this answer
+1 That is actually a good point. But I feel I should use the opportunity of building a whole new application to catch up with current technology. Don't you think? –  juergen d Jan 8 '13 at 16:06
Yes, you are right. You have to spent some time to understand the business problem that you are planning to solve and then re-search for the best solution that fits your bill. –  Yusubov Jan 8 '13 at 16:10
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.