0

One year ago, I discovered the WPF technology and I developed a little application, as first experiment, to compare the content of two different directories. The content of each directory is shown in a different DataGrid. At that time, I didn't develop the application using MVVM pattern, because it was only an experiment, not so good, but it worked.

Now that I've much more experience with WPF and with the design patterns, I'm not so proud of that work, and I want to rewrite the application, improving it and following the recommended MVVM pattern.

Actually, I designed the application in this way:

  • the MainModel, with the main common algorithm.
  • the MainView is the unique view of the application with the datagrids where I can show the results of my algorithms.
  • a MainViewModel, that it will take care of handling the connection between other two ViewModels, the MainModel and the MainView.
  • One ViewModel for each DataGrid. In this way, I'll separate the behavior and the data of the two DataGrids.

The MainModel contains the main algorithm used to search the files in a given directory, like this:

public class MainModel
{
    public MainModel()
    {}

    public List<Results> GetFiles(string directoryPath)
}

The MainViewModel will instantiate an object for each ViewModel (I have a ViewModel for each datagrid), using some properties to do it:

public class MainViewModel
{
    public MainViewModel()
    {
        FirstViewModel = new ViewModelDG1();
        SecondViewModel = new ViewModelDG2();
    }

    public ViewModelDG1 FirstViewModel
    {get;set;}

    public ViewModelDG2 SecondViewModel
    {get;set;}
}

I wanted to apply a design pattern to help me manage the application, like a Factory Method or Builder, or a Template Method, but I think they're not suitable for my application for the different usages/conditions of those design patterns.

I'm not so sure of this design, I don't know if this a is correct implementation of the MVVM pattern and if it promotes a loose coupling and high cohesion. Can you help me in the design? Is mine a correct implementation of the MVVM? If not, then what is the correct one? What are your opinions?

Thank you.

2 Answers 2

4

Alberto, about one and a half years ago I was where you are now, and I've learned a lot about MVVM, WPF and Programming Meta Skills on the way.

For the time being, I will refrain from answering your questions specifically, and like to get a few words out that are of general interest/guidance, if you will.

MVVM is a design/architectural pattern that takes some time getting used to. There is no one right or correct way, MVVM is practiced in many different flavors with strictly no code-behind on the one side, and a more "integrated view model"-like approach (with a certain amount of code-behind allowed) on the other side. As with many things in IT, this topic also borders on personal liking.

Don't make the mistake I made by trying to push in patterns (or someone else's design liking) for patterns' sake. Recognize your specific problems, and try to solve them one at a time. See how other WPF/MVVM experts are solving and buildings things. By recognizing a problem and finding a way to solve it, you learn your MVVM/WPF skill by heart. Many small steps will get you in the right direction faster than any doggedly "I'm trying to get this 100% correct the first time" approach.

Now to your question:

I cannot see any problem with your approach so far. The only things I'd like to comment on are:

  1. Instantiate your VMs via lazy loading, so that they consume memory/processing time only on-demand. Also, if you're allowing re-setting your view model objects (see your setters), please make sure that the container class implements INotifyPropertyChanged.

    public ViewModelDG2 SecondViewModel { get { return _viewModelDG2 ?? (_viewModelDG2 = new ViewModelDG2()); } }

  2. As for your "loose coupling" concern: That one is more about providing interfaces to your specific implementation (classes). If the view is created in a different assembly, it might make sense to operate via internal classes and public interfaces.

Resources I can warmly recommend to you:

Best!

1
  • Thank you for the advices and the resources. So I should not push in patterns, to avoid a mess in the design of application. Do two ViewModels 'talking' with a MainViewModel could introduce a little overhead? I thought about the above approach to introduce a common behavior in the MainViewModel and then implemented in the two ViewModels, but I'm thinking about the consequences.. Jul 15, 2013 at 21:40
0

Hello I think it's to late to give this question answer but I think it may be useful to others who search same content.

as per my view the best Design Approach should be .

Your Application have below mentioned folder

1.Resources

2.Models

3.ViewModel

4.View

5.ServiceAgent //Which is used for reduce the dependance injection

6.Libs

Ok, All Views of your Application must have end with View Name. e.c MainPage is your xaml then it name should be MainPageView.xaml

All same as All Viewmodels and models.

Your Viewmodel folder contain one ViewmodelLocator which is used to initialized all Viewmodel Which are used in your application.

you have to create object of Vuewmodel locator in App.xaml file and use it all view as a staticresource

e.c

xmlns:vm:"Your ViewModel namespace"



<resource><VM:YourViewModelLocatorName X:key="Key Name" /></resource> 

Your View Datacontext Should be

Datacontext="{Binding ViewModelName,Source="{StaticResource KeyName}"

Thanks

Your Answer

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

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