Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I'm having trobule figuring out the best way to use the MVVM pattern while creating a WPF control dynamically within
my code. Would this even make sense or is it better to avoid the MVVM pattern all together?
If it does make sense then please share code examples of the view model.
In general, if you're using MVVM, controls will only be created "dynamically" in response to the data changing. If you have an ItemsControl bound to a collection, for example, the controls to represent the items will automatically be created for you.
If you're talking about making a custom control in general, custom controls are really "pure view", so MVVM doens't really make sense in this scenario. The main goal of creating a custom control is to build it in a way so that it can be used by code developed with MVVM, which typically means building the control with proper Dependency Properties (so data binding works properly), etc.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am in the Process of converting a VB project to C# WPF. We are planning to do with MVVM concept and I am in the learning process. To my understanding each form in VB is a View. Each view should have a corresponding Model and ViewModel.
For the Second Form, another view and a corresponding Model and ViewModel.
If there are n Forms in VB, there will be n Views, n Models and n ViewModels in C#.
I am not sure what I asked here is right or not. Experts here please help
As far as the view is concerned, you're right. Each form will have a view for presentation and a view model for presentation logic, or how your models should interact with the view. These are not necessarily one-to-one with models. You might have a model that encapsulates some data and business logic that you want to reuse. I suspect you VB projects had such classes.
MVVM Light is a simple and effective framework you may want to look into. This is a pretty good summary of MVVM using this framework.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm doing a C# application using WPF. I'm trying to follow correctly the MVVM pattern because (especially with C#/WPF) is very useful.
My app is designed in 3 "big" parts, as the MVVM model says:
The view, in XAML -> The MainWindow.xaml
The ViewModel, in C# -> MainWindow.xaml.cs
The Model, in C# -> A my static class named Register.cs
It's a strong pattern, and it's working good.
My software manage lists of custom object: I press a button on the View, the ViewModel start a method (on Model) that retrieve lists of data from database and I bind them on the View side (on a ListView, in WPF).
All is working good. But, even after reading a lot about MVVC pattern, I cannot understand a thing: where I should memorize these lists?
For now, I'm declaring these lists on Model and they can be retrieved by simply calling them through the ViewModel but I don't know if it's the right approach.
I need to maintain these lists and a lot of others strings (like current username and things like that) until I close the software (or I need to save them).
All data come from INI or DBs, and I don't know where I should "temporary" memorize them, if on the ViewModel (why? because its the View that interact with them) or in the Model? (isn't smarter to retain the data "near" the place where you got them?)
Also,in the future, I would like to port the software in UWP or Mono, so I should simplify myself the jump. Also, in that case, I think I will have to discharge all the works I've done on the ViewModel.
Where I should memorize all "temporary" data used by the software? In the M or in the VM?
The way I think about where to put something is like this: answer the question if it is a business (data) concern or a UI (presentation) concern. First will go in the model, the second in the view model.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have tried many options for a long time and that is the last one that comes to my mind, so I will try to ask:
I am trying to develop an MVVM project in WPF and I have downloaded a ready-to-use WPF control (GMap.NET). However, this control is not prepared to use it in MVVM and I am a newbie in that, so I do not want to modify a source code on my own. The control requires to set many parameters (not accessible through XAML, so I cannot simply bind them), and call some functions on control object. So here goes my question:
How can I access a WPF control instance from any place from the code and manage it from there?
Particularly, I want to access a View element from ViewModel part and I know that it brakes the pattern, but I have no idea how to avoid it and I am running out of time.
Hard to say without knowing the concrete control. But in general, I see 2 options for make such a control MVVM conform:
Subclass the control and add dependency properties so it can be used in XAML
Create a "container control" that wraps the unMVVMable control and provides the required dependency properties.
However, if the API of the control is complex and has not only properties, but also some methods, it may be pragmatic do break MVVM here. MVVM is not the only way to separate GUI related logic from the view. You could abstract the used functions with an interface and use the interface within your view model for example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
SITUATION
I am working on a (MVVM, Composite) WPF application, where everything should to be done in a very loosely coupled way.
When it comes to applying styles, I already have a nice little solution:
Each and every control, that is used, lives in an separate DLL, no matter if needs special styling or not.
In the constructor, each and every control, calls a static method, which delivers the right style for this control.
Example for a TextBlock:
public partial class TextBlock : System.Windows.Controls.TextBlock
{
public TextBlock()
{
InitializeComponent();
//The class ResourceCreator knows, which style to deliver
this.Style = (System.Windows.Style)ResourceCreator.FindResourceByName(
Styles.StyleNames.TextBlock);
}
}
This program design is okay so far because you never have to apply styles anywhere. The class ResourceCreator knows which style to apply to this control and of course it can switch between different styles. The control itself doesn't know, which style will be applied.
WHAT I WANT
In an MVVM application, a rule of thumb is, that there should be no logic at all in the code-behind of the View. Everything happens in the view model.
I want to break this rule only to apply styles. Any window or view should have one method in the code-behind, that iterates over the visual tree. Each detected control-type should be identified and then the appropriate style should be applied.
QUESTION
Is this a bad or good idea? Are there any facts, that I don't see, which are against this idea?
In an MVVM application, a rule of thumb is, that there should be no logic at all in the code-behind of the View. Everything happens in the view model.
You are wrong. MVVM is not about eliminating code from the views. It is about separation of concerns. It is perfectly fine to write any view-related code in the code-behind of the view.
And styles are purely view-related. So is any code that controls or interacts with the view layer that is difficult or inefficient to express in XAML, such as for example complex animations. These kind of things should not be implemented in the view model.
So you are not breaking any MVVM rules here :)
Your application logic should be implemented in the view model and your business logic should be implemented in the model. But any pure view-based functionality should be implemented in the view.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How do you structure your project for ribbon based projects, when using WPF?
I use Microsoft's Ribbon control and I wonder if I should have a single
view for the main app, but two separate view models one for the ribbon
and another for the window part below the ribbon.
You are asking a very subjective question... I'm actually surprised that it hasn't been closed yet (we have many keen question closers on this site). The answer to your question of course depends on what the application does, its size, the developer's style and preference of programming, etc.
I personally just prefer to hardcode the controls into my Ribbon rather than generating them from a view model and templates. It does make the code page large, but I'd rather have that then be confused as to what goes where and when.
I generally prefer to simply have one property of type BassViewModel in my MainViewModel class and that is data bound to a ContentControl in 'the window part below the Ribbon as you call it. Then I just set this property to the relevant view model dependant upon the users' view selection in the Ribbon.