I'm currently learning C#, and recently I've learned about the MVVM design pattern for WPF. I am writing a simple program as a way to practice this, but I'm not sure where I should write the method that loads the data.
I have a SalesSheet class, as shown below. This holds the data that I load from a .xls file.
class SalesSheet
{
public List<Row> Rows { get; set; }
public SalesSheet()
{
Rows = new List<Row>();
}
public class Row
{
public string CallType { get; set; }
public string HistoryText { get; set; }
}
}
My question is, where should I write the method that loads the data? Is it bad practice to write a method like:
private void LoadData(string filePath)
in the model, and call it the constructor?
Should I load it from the ViewModel?
Rationale. MVVM was designed to remove virtually all GUI code ("code-behind") from the view layer, by using data binding functions in WPF (Windows Presentation Foundation) to better facilitate the separation of view layer development from the rest of the pattern.
Google's interpretation of mvvm framework as can be seen on their android portal clearly says that it should be in the view model layer.
The Layers of MVVM with Clean Architecture Even within the Android app architecture we're using, there are many ways to structure your file/folder hierarchy. I like to group project files based on features. I find it neat and concise. You are free to choose whatever project structure suits you.
MVVM separates your view (i.e. Activity s and Fragment s) from your business logic. MVVM is enough for small projects, but when your codebase becomes huge, your ViewModel s start bloating. Separating responsibilities becomes hard. MVVM with Clean Architecture is pretty good in such cases.
In general, a small WPF project should have the following approximate folder structure:
DataAccess
is the folder where you should store your data access classes. It is good practice to separate the various aspects of the application; the views, the view models and the data access classes. This is known as Separation of Concerns and is good practice because (among other things) it enables you to switch out layers... this means that you could later add a web interface (or change your database) while still keeping the majority of your code the same, and it also makes testing your code easier.
You might only have one class in this folder, let's call it DataProvider
. In this DataProvider
class, you put all of your data access methods. You now have one point of entry to your data access and you can add a reference to it in a base view model:
protected DataProvider DataProvider
{
get { return new DataProvider(); }
}
Now your view models all have access to the project data source and then you can do something like this:
SomeObject someObject = DataProvider.LoadData(filePath);
Of course, there are many different ways of implementing this pattern, but hopefully now, you get the idea.
In my understanding of MVVM your LoadData method belongs in the model. The viewmodels can then access the loaded data through a property or method from the model. The important point here is, that the viewmodels don't know about the concrete file access logic, it is abstracted by the model.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With