We Keep Coding

MVVM - I should maintain data in Model or ViewModel? [closed]

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.

MVC: is there a definitive answer as to where business logic belongs? [closed]

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.

What is the purpose of the Model in MVC? [closed]

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.

Correct Approach of following MVC [closed]

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.

What are advantages & disadvantages of creating multiple controllers in single project using asp.net mvc2 [closed]

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 creating a asp.net mvc2 project which contains multiple modules in the project.I am thinking to create supprate controller for each module, but i want to know what are the advantages & disadvantages out of it?

Seperate controllers means a Seperation of Concerns, you would have separate controllers to handle logic that should be separated. So you won't get a cluttered controller handling everything in your application. Besides clarity in your application, this brings the benefit that if you need to change one thing, you don't break other code handling other logic in the same place.
Naturally this separation is also present in your Views folder, so you'd have clear oversight what's going on where in your app.
Also, if you have a lot of dependencies that your one controller needs (like services getting different domain models) you would have these listed in one place, which would make it less clear what the primarily function of that controller is. It's nicer to have more controllers with less dependencies each.
Another benefit is that you get user friendly Urls without much effort:
www.domain.com\home\index
Pretty much spells out this is the homepage.
And:
www.domain.com\account\login
does so too.
Basically, make objects (controllers) for each "section" of your web app, like you would make objects for each functionality of the business logic.

i would read this article: Biggest advantage to using ASP.Net MVC vs web forms
since it already covered your question for a big part.