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.

Using the MVVM pattern with Unity Engine as front end [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 5 years ago.
Improve this question
I plan to make some applications that will let me organize tasks from home or from somewhere else. For this I need a database server (a virtual one running at home), a backend part (the business logic) and the front end (the view). At school we learned the MVVM via WPF, but to be frank I use it only when it is explicitely required.
There are a lot of benefits in favour of Unity like
Artist friendly
Can compile to mobile, web and desktop
Fast development (in my case at least)
Has a lot of built in features I can harness.
Now, even as simple as I will make an app like this, sometimes I might want to extend it, improve it or change some components entirely.
I know how to use MVVM in WPF but I only have some vague ideas for the Unity implementation which I would like someone skilled to overview.
The front end (Unity) would take care of sound management, fancy animations and the UI itself. But UI button events cannot access directly the database, so I thought of building some bridge classes. Say I want to delete a reminder, as an easy example. In an OnButtonClicked() method I would just call a BridgeClass's PleaseDeleteThis(MyReminder) and inside that method there's the backend solution that actually finds that reminder by id and removes from the database, then sends an everything all right flag back to the front end app so I know it was successful.
What I thought of is that using these bridge classes I wouldn't have to worry about what happens if I change the database server or the front end, as all they have to know is communicating with the bridge. I know the example was over simplified, but how doable would this one be regarding the component integrity and the MVVM pattern?

MVVM has been successfully used by AAA software houses to build games. The makers of Shipbreakers (aka Homeworld: Deserts of Kharak) wrote their code such that the View was a MonoBehavor I believe, VM and M were POCO classes written external to and independent to Unity so as to speed development. They can have their own Views for prototyping external to Unity.
They also wrote their own debugging visualisers and property editors for Unity.
https://www.youtube.com/watch?v=q9aeNtKKXeo
MVVM is about at the 19:18 mark though I do recommend to watch the whole thing as there are some other great things in there.

How to improve Project structure in c# web application [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 7 years ago.
Improve this question
I am working on C# web application and i build various application with simple project structure like image is given below.
Basically i want to know about the best project structure of large web application on C#? or is above project structure(in the image) is right way to build an web application ?
Now i want to improve my project structure. So where should i start improve myself to build an lage web application.

There's no "best way", but there are some "worst ways". I see that you are using some of the "worst ways". Here are a few of them:
Do not use web site "projects". They are not projects. They're just whatever happens to be in a particular directory tree. I notice that you have ~1.pdf in your project, or did you just happen to have it in the same folder? Use Web Application Projects instead - use File->New Project.
Do not use App_Code. App_Code is for a small number of code files which are compiled at runtime. No other kind of "project" has code compiled at runtime. This is a bizarre corruption of computer programming.
At the very least, create separate folders for the different parts of your code which are not in code-behind. You can start with a single folder (maybe called "My_Code", not App_Code), and when you start to get "too many" files in that one folder, start separating the files based on their function. Keep one class per file, and it will become obvious quickly that different sets of classes have different sets of functions. For instance, you'll find you have a set of classes related to database access. Put those into a "DataAccess" folder.
Better, once you find that you have many such folders, move each of the folders out into their own class library project. This way, you don't have to jump right into a complex project structure - the structure can evolve over time.
And if you wind up in ten years with only three classes in My_Code, then you have saved yourself the waste of creating tiny class libraries.
You may have too much code in your code behind. I can't see it, but projects which have the first two symptoms usually have the third. Your codebehind should only have code in it that directly involves user interface - for instance, it can call a method to fetch data to bind to a data bound control, but the code to fetch the data should be in a different class, not in the codebehind. This different class should not be in App_Code, as I say in #2.
Are you using source control? I don't see any source control icons on your project icons. Use source control. Visual Studio Online is free for up to five users, and allows you to use either TFS or Git for source control, as well as providing work item tracking, automated builds and quite a bit more. For free.

I don't think there is really a correct way to structure a project. It depends on what the goals of the project our and your plans for implementation. Each project is different and have will different requirements.
I would go with the most logical approach for your particular project. Whether that's grouping similar components together or grouping whole sub-systems together.
You should carefully analyze your requirements up front before you even begin development and plan your structure accordingly. Having a good plan before you begin coding will save you a bunch of hassle down-stream if things aren't working out and you need to restructure.
I would suggest reading a book like Code Complete, it'll give you excellent tips on how to plan and structure your projects. You can find it here: Code Complete

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.