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 7 years ago.
Improve this question
MVVM pattern necessarily needs a database? Because, all crud examples that I found do not use a database, they all do the CRUD inside the code, with list's and obsservableCollection's.
Thanks
The answer to your question is no. The MVVM design pattern is a presentation model hence independent from a persistent data store. Consequently, you do not need a database. Read this for an introduction: WPF Apps With The Model-View-ViewModel Design Pattern and Wikipedia.
What you do need though is a data model which forms part of the MVVM design pattern. The decision to use a database (or any other datastore) for CRUD operations of your data model (or parts of it) depends on the functional requirements of the application.
No, MVVM Pattern is just a pattern(a reusable solution for a recurring problem). So it is an application necessity whether to have DAL(data access layer) or not.
MVVM consists three layers:
1. Model 2. ViewModel. 3. View
MVVM is short for Model-View-ViewModel.
Models are simple objects of classes that hold data( For example, Person, Animal or Tank classes). These classes should only contain properties and property validation. There are no responsibility for getting data, saving data, click events, complex calculations, business rules, or any of that stuff.
Views are the UI used to display data, what user see and what user interact with. In most cases, they can be DataTemplates which is simply a template that tells the application how to display a class. It is OK to put code behind your view IF that code is related to the View only, such as setting focus or running animations.
ViewModels are classes where the magic happens. They send data to View by events(INotifyPropertyChanged). This is where the majority of your code-behind goes: data access, click events, complex calculations, business rules validation, etc. They are typically built to reflect a View. For example, if a View contains a ListBox of objects, a Selected object, and a Save button, the ViewModel will have an ObservableCollection ObectList, Model SelectedObject, and ICommand SaveCommand.
MVVM Pattern allows you separate data from view. Data is just data and view is just view. No dependency between data and view, so we have other advantages such as unit testing and loose coupling.
Related
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 6 years ago.
Improve this question
I'm currently trying to refactor a C# MVC application in spite of having limited experience of the pattern. Reading around the subject, I seem to constantly blunder in to dimetric opposite opinions on best practice.
My biggest problem is that there's way too much stuff in the controllers. They work, but they're full of business logic which is hard to restructure and to test. Models are mostly just thin DTOs. So, where do I start putting this useful business logic in order to rework it and test it?
A lot of people say it should go in the model. But then you get some people saying it should go in the controller after all. And other people telling you that the principle of the model containing data and NOTHING ELSE is fundamental to the pattern.
Then you get people telling you it should go in a fourth type of class, a ViewModel. Now I've worked on MVVM in WPF and I'm familiar with this paradigm. But adding it to MVC just seems to replicate a lot of work that's done elsewhere, for no better reason than blindly following a pattern dictate.
Yet another option is to put it in some sort of helper class. This seems a common suggestion, which I won't link. But doing that seems a wasteful use of another class which has no point to exist outside of providing functions to a single controller. And that would seem a fundamental violation of OOP principles.
Is there a definitive "correct" answer to this? If so, why is there so much confusion? If not, how do you go about gauging the best solution in this morass of opinion?
To me, the M in MVC stands for view model, it contains the data needed for the view to do its work, so that the view can remain as dumb as possible.
This view model is created in the controller and passed to the view, but as you said, the controller logic should be kept small - so no business logic here.
This business logic belongs in services - which could be remote services exposed with WCF, or a web API, or just a class library with methods in your web site.
So, summarized:
the controller calls the services to get data in the form of a model. Business logic is inside these services, the model returned is just POCO.
the controller creates a view model based on the received model, which contains the properties in the format which is best for the view.
the controller passes the view model to the view, which uses the view model to build itself.
I don't believe there is a definitive "correct" answer. I believe it's all in preference and how complex your data manipulation is.
At my company we use helper classes/a service for the purpose of organization. Our controllers do not contain any functionality except for taking in a model, manipulating it, and spitting it back to the view.
We have a vast amount of data manipulation, and to do that in the controller would be a horrible mess.
Most people would agree that no logic should be in the controller. The difference is where that logic should be. For my company, it would have been ridiculous to put it in the models themselves because of the sheer volume of manipulation that takes place. If there isn't a large amount of manipulation I would put it in the models.
On the project I am currently working on, we have kept our Controllers reasonably free of Business Logic as we have separated them out into Units of Work. I believe this pattern was adopted to allow us to swap the Units of Work in and out depending on the client etc.
Where as the previous project I worked on was all in the controllers and broken down into smaller shared helpers where necessary.
I don't think there is strictly a correct way or an incorrect way. The majority of the time it seems to be down to personal preference of the developer.
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 7 years ago.
Improve this question
I have read a lot about MVC, and I have even written a modestly sophisticated data-driven MVC mobile web app in .Net, but (since I am still learning), I did not see what to put in the model. The app had a dozen or so views, a primary controller, and helper files for SQL interactions and custom data types. I was able to data bind just fine without using the model, and custom data types worked as anticipated. Please be kind, what am I missing? What is the purpose of the model, and why should I be compelled use it (other than it being a standard)?
MVC is primarily a User Interface design pattern. The Model is a container for "everything else," everything that doesn't have to do with UI.
In general, you push as much logic as you can back from the View into the Controller or a ViewModel, and you make your controllers as thin as possible by pushing as much logic as you can back into the Model. So the short answer to "what goes in the Model" is "everything that doesn't go into a View, ViewModel or Controller."
Specifically:
Domain objects, like customer
Services
Business Logic
Server-side validation
Object-Relational mappers
Database
Repositories
Simply put - "The MVC Model contains all application logic (business logic, validation logic, and data access logic), except pure view and controller logic.
With MVC, models both hold and manipulate application data."
You are not following the standard MVC pattern if you ignore the Model all together. However, as you found out - you don't need to use it. You can call into the database directly from the controllers and return types you've defined in the DAL (Data Access Layer) - which indirectly you are using as the Model in your design. This isn't good practice.
You should be compelled to follow the pattern so you achieve 'Separation of Concerns' in your application's architecture. You can find a lot of information online about this topic as it relates to the MVC pattern.
Model Definition
The View is a template that can be filled by passing a model containing data into it.
It allows the view to be customized depending on what the model contains.
How else are you filling data into your view?
Maybe jQuery gets?
In your case, the "helper files for SQL interactions and custom data types" is your model. The model is an abstraction over the true data source, eg the database.
For small projects, what you have done works just fine. As projects get larger though, binding the view directly to the database/model and not fully abstracting the model causes more and more problems.
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.