1

I created a app using Microsoft's WPF. It mostly handles data reading and input as well as associating relations between data within specific parameters.

As a total beginner I made some bad design decision ( not so much decisions as using the first thing I got to work ) but now understanding WPF better I'm getting the urge to refactor my code with better design principles.

I had several problems but I guess each deserves it's own question for clarity. Here I'm asking for proper ways to handle the data itself. In the original I wrapped each row in a object when fetched from database ( using LINQ to SQL ) somewhat like Active Record just not active or persistence (each app instance had it's own data handling part).

The app has subunits handling different aspects. However as it was setup it loaded everything when started. This creates several problems, for example often it wouldn't be neccesary to load a part unless we were specifically going to work with that part so I wan't some form of lazy loading. Also there was problem with inner persistance because you might create a new object/row in one aspect and perhaps set relation between it and different object but the new object wouldn't appear until the program was restarted.

Persistance between instances of the app won't be huge problem because of the small amount of people using the program.

While I could solve this now using dirty tricks I would rather refactor the program and do it elegantly, Now the question is how. I know there are several ways and a few come to mind:

1) Each aspect of the program is it's own UserControl that get's reloaded/instanced everytime you navigate to it. This ensures you only load up the data you need and you get some persistancy. DB server located on same LAN and tables are small so that shouldn't be a big problem. Minor drawback is that you would have to remember the state of each aspect so you wouldn't always start at beginners square.

2) Having a ViewModel type object at the base level of the app with lazy loading and some kind of timeout. I would then propegate this object down the visual tree to ensure every aspect is getting it's data from the same instance

3) Semi active record data layer with static load methods.

4) Some other idea

What in your opinion is the most practical way in WPF, what does MVVM assume?

Improve this question

1 Answer 1

Reset to default
3

If you are going to refactor it, I would recommend using the MVVM design pattern

MVVM stands for Model, View, and ViewModel. Your Model is your class objects (such as a Customer, or a Product), your View is your UI (XAML file), and the ViewModel is what combines the two. ViewModels contain your UI implementation (Save Command, Add Command), and your application State (CurrentRecords, NewRecord, SelectedRecord, etc).

There are a lot of good articles online that can probably explain MVVM better than I can. This article is the one I used to start with

Improve this answer
4
  • So you are saying that MVVM actually solves my problem? After a glance I'm still not sure how, except maybe that he reloads the workspace part which is similar to what I name in 1) There are still some aspects of MVVM that elude me, like how it works with LINQ, the use of UserControls and such. Could the Customer class mentioned in your link represent the LINQ entity class or would that cost one more class. Having 5 classes for each of my 30+ tables could get messy.
    – Ingó Vals
    Commented Feb 16, 2011 at 17:23
  • I'm not really sure what you're asking without knowing more of your code. You might have better luck posting on StackOverflow for code-related questions. A simple MVVM example would be when you hit a "Get Customer" button on the View. This executes a GetCustomer() method on the ViewModel, which runs the Linq statement to get a Customer from the database and stores the result in a CurrentCustomer property on the ViewModel. The View is bound to the CurrentCustomer property, so gets updated automatically.
    – Rachel
    Commented Feb 16, 2011 at 18:00
  • I'm wondering, and my original question was, how do you keep the database info persistent. What if the same table/row was accessed in a different view inside the app when you would update one how do you ensure the other one is updated?
    – Ingó Vals
    Commented Feb 17, 2011 at 0:13
  • If the info can be shared between ViewModels, then I'd do that. Have both ViewModels reference the same source object so when one updates it, the other automatically changes its data. Otherwise, reload the object when the item comes into view. Or at very least provide a Refresh button so they can reload the object manually
    – Rachel
    Commented Feb 17, 2011 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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