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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
My English skill is poor because I'm not a native English speaker.
I hope you to understand.
I have written an application whose structure is MVVM in WPF.
An idea floated into my mind while writing an application.
In MVVM pattern, I know that the ViewModel must split with View and to achieve this goal we use behavior, attached property, EventToCommand of the MVVM Light, etc situationally.
But I think that using together more than two skills of the above skills to handle the event of View on the ViewModel complicates the connection structure of the whole logic.
So... I curious what it's like to drive the all logic to handle the event of View into Behavior situationally.
Perhaps the structure looks like this:
ViewModel has only a data structure to connect with View and logic related to the data structure. (Ex: TestViewModel)
The logic of the ViewModel only is written on Behavior. (Ex: TestViewModelBehavior)
Thank you for reading.
I can't understand what is your problem correctly, maybe because my English skill is poor too :) but:
I think you can inherit TestViewModel from TestViewModelBehavior or if you want to have different Behavior in each ViewModel you can inject different implementations of TestViewModelBehavior to TestViewModel.
I hope to help you.
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 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 4 years ago.
Improve this question
I have four similar apps with different branding.
App
\ Views
\ MainPage.xaml
\ LoginPage.xaml
\ YourAccountPage.xaml
\ TodoListPage.xaml
\ TodoDetailsPage.xaml
\ TodoItemView.xaml
\ Images
\ App1_logo.png
I want to make my projects easier to manage. When I make one change I must usually have 4 instances of Visual Studio up and do the same change in all projects, or risk forgetting it.
I do API calls and display data in .xaml.cs files.
I have already separate projects for models and service implementation. But it's not straightforward with XAML files.
You are giving very little information on the context of your application. Since you are using XAML I'm assuming you intend to use MVVM.
I think your problem is that you call data and do API calls in code behind (xaml.cs). Aggregating data to display is what a view model is for.
You should design your view with the thought in mind that the data you need will be provided for you by the view model (it does not matter how yet). If need be, imagine that you told some other developer exactly what kind of data you need, i.e. a list, sorted by timestamp. How that other dev aggregates that data is not your concern.
Avoid doing logic in the view as this will cause a coupling of your business logic with your view which will lead to exactly the problem you have right now.
Once your view is decoupled from the logic you could make a library with just the views.
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 9 years ago.
Improve this question
I am working in MVC from last one year. I am following the MVC approach i.e simple appraoch and not Repository patterns. Now, I come to know about the advantages of using Repository with dependency injection and I feel it follows the oops in right way.
That is my thinking.
In one of my sample/test project I started working with repositor and have few questions about it:::
1) when we use EDMX , suppose I have a table names "Users", it automattically
creates a class named as "users" which contains all the fields as properties.
What I usually follow is I create a model layer and add a class in that model layer of name
"myUsers" that will contains same properties as the class users have.Now, I will bind the view
page with "myUsers" so that it cannot deal directly with DAL.
and Whenever I post something from my view page , the object comes in "MyUsers" model,
and here I again do something like this.
Users=MyUsers(I do this by doing this for each property like::
Users.Name=MyUsers.Name
and then I save it in Database.
I use above approach and in my applications I have used the above approach.
Now my question is
Can I bind my view page directly with "Users" class? As I see some applications,
it is happening. It reduced much work and also overheads in application.
What is correct approach ? to deal directly with DAL or there should be models
in between them?
"Correct approach" is subjective. We like to create ViewModels that exist purely to show domain objects in a view because it means we can separate view logic from the domain. We may not always want to show / load every property of a domain object. As another example, we put DataAnnotations attributes for validation on our ViewModels.. but we leave the domain objects as nice little POCO's.
Manually mapping them like you are is an incredible waste of time though. There are frameworks that do that for you.. such as:
Automapper
ValueInjector
According to me, this is the correct architecture.
Let me explain the answer in comments below.