We Keep Coding

Understanding application flow with MVVM

I am having a hard time understanding how MVVM is used in case of more complex applications. All the examples I can find are extremely basic Apps.
Let's say I have a "Package Delivery" application. To perform a delivery I have to do 3 steps:
Scan the package
Enter any damages or problems with the package
Let the recipient sign on the device
All this information gets validated on the device and then sent to the backend.
In MVC I would implement this like this:
The DeliveryController handles all of the logic. This includes navigation between pages, fetching of API data and validating all of the data once it is all collected.
The controller acts as the "Connection" between the Views and collects all the information and brings it together.
But how would this be done in MVVM? Where would all the data be brought together? Most implementations of MVVM I can find do something like this:
In this, the data entered in each View would have to be passed to the next ViewModel until the end of the chain is reached. At that point the SignatureViewModel would do the validation and make the API call. That seems very weird and like it would get very confusing, since data would just be "passed through" multiple ViewModels just to have it at the end of the chain.
Another option I see would be that each ViewModel handles it's own data:
Here for instance the DamagesViewModel would validate and send the data it's own View handles. The big issue with this is that data does not get sent as a whole. Also there can not be any validation of the entire data before it is sent.
My last idea would look like this:
This adds a DeliveryViewModel that essentials acts like the DeliveryController does in MVC. It would handle which ViewModel to navigate to next, handle what API calls to make and validate all the data once it is entered.
To me (as someone who has mostly used MVC) this last options seems most sensible. But I also feel like it might miss the point of MVVM.
How is this usually done in MVVM? I would really appreciate any pointers. Links to articles that explain this well are much appreciated.
Also if anyone knows of any publicly available repositories or projects that have this kind of pattern in them, I would love to see them.

Even when using MVVM I still use some form of a controller and consider ViewModels as basically transformation of data to facilitate the view.
So for me there is still a service or controller layer that completely separates the middle and back end tier from the rest of the architecture.
View models come into play depending on the consumer/app - fetches data from the service tier, transforming the data, validating etc for the purpose of a consumer/app/etc.

I have struggled quite a bit with the same thing. Especially since I’ve used MVC quite a lot.
I think the most important thing to consider is that MVVM is not meant to solve exactly the same things as MVC. You can still implement a controller outside of this pattern to complement it. It also changes quite a lot the general design of the application.
One mean to do it that I have used is to implement the controller as a singleton that can be shared between VewModels. This controller can per example be injected into the ViewModels using dependency injection.
Viewmodels could then for exemple subscribe to events coming from the controller to update.
But this is one way to solve this problem among others.

MVVM is a way to organize code. It’s one way to separate your user interface from your logic.
I have found a blog where you can have a look where MVVM architecture is described perfectly.Though here writer demonstrates MVVM for windows form app but at least you can get some idea about architectural design of MVVM.
https://scottlilly.com/c-design-patterns-mvvm-model-view-viewmodel/
Also please have a look into this repo.
https://github.com/MarkWithall/worlds-simplest-csharp-wpf-mvvm-example

C#' MVVM Observable Proxies aka Android LiveData?

I am developing a C# wpf mvvm application in which the Model Data is represented by hierarchies and my ViewModels have to observe Parts of the hierachies in between. I would like to come up with a design that makes the application easier to maintain when the structural hierarchies of the Model change.
Example:
The Model has a hierarchy A->B->C->D. The ViewModel wants to get change notifications of D and B. At some point another ViewModel sets A to a completly new value and all other observing ViewModels have to be notified that their respetive D and B are no longer valid.
My design idea so far:
I flatten the hierachy of the models by replacing the direct reference with an unique Identifier like GUID. When a ViewModels wants to get an instance of D it actually has to ask a Repository to get an observable Proxy of D. When a write to A occurs, the observable Proxy gets notified about it and therefore the ViewModel also gets notified. The life cycle of the obervable proxy is bound to the ViewModel thats using it, e.g. the ViewModel decides when the observable proxy will be disposed.
Is there maybe already a pattern that solves this problem in C# MVVM? I saw that Android Jetpack introduced LiveData and it looks very similar to what i am trying to do.

TLDR: Anemic Domain Model, entities that reference other entities with unique keys and messagebus is the way to go.
After studying the problem I came up with a few proven solutions.
According to DDD (Domain Driven Design): Its OK to reference other aggregates by Index but not object reference. Aggregates should only be accessed via the aggregate root and encapsulate logic and child entities inside the aggregate root. This is OOP and you end up with easy to use objects that overtime become fat filled with methods and fields because, well just look at the WPF framework UserControl when you enter 'this.' and an accordeon of fields, methods and events reveals to you. One could argue that you can use inheritance and move methods out with mediators to reduce your 5kloc OOP source files, but mediator is just procedural style programming in disguise which leads me to...
The Anemic Domain Model. Entities are just data containers without behavior (methods) and only have fields that are simple or reference other entities by keys. On top of the dumb entities are the 'services' which are just stateless collections of methods that run on the dumb entities. Every write operation by a service will trigger some kind of messaging, either a message bus or other.
The anemic domain model pattern is very popular in games industry right now, but they call it 'Data oriented Design' or DOD. DOD boils down to lots of dumb data component objects where some methods run on them with the goal to achieve easy parallelism and cache coherence. In my opinion thats just old school procedural C programming with handles and it makes sense for high performance applications.

How to do backend coding of HTML element in Visual studio?

Hi after creating a button in HTML in Visual studio, how can i do its backend c# coding? Normally while using webforms double click will open coding class but how to acheive this in Visual studio for HTML element?

I think you can use the MVC pattern. To be more familiar with, you can read this documentation https://www.asp.net/mvc.
Few words about MVC pattern:
Define MVC in layman’s terms
Remember you’re technically minded and close to the code. MVC to you
is as clear as day, but saying to the business ‘Model, View,
Contoller’ could give them the impression that you are suffering from
some form tourette syndrome. MVC won’t mean much to the business even
after you define them in relation to the code. To get the business to
understand why this is the answer and least of all what it is, can be
more of a task than expected in my experience. Even some fellow
developers have difficulty understanding this on occasion.
To get the listener to understand what MVC is and why it works what I
have tried in the pass is to apply MVC to a different industries where
the listeners have had more involvement. An example that has worked
for me in the past in a comparison to the property or even the
vehicles. Most people have had dealing’s with builders, carpenters,
plumbers, electricians or have watched the flood of property shows on
the TV. This experience is a good platform to use and to explain why
separation such as MVC works. I know you’re probably thinking that
won’t work as it’s not the same as in software, but remember you’re
not trying to train the business to become developers or have an in
depth understanding of MVC, simply explaining to them that separation
in production is required and that’s what an MVC structure offers.
To give an example of how you could describe this I have very briefly
explained how separation works in property. Keep in mind this is
focused on using the system not developing which could be a completely
different angle of explanation.
View
The view in MVC is the presentation layer. This is what the end user
of a product will see and interact with. A system can have multiple
views of all different types ranging from command line output to
rendered HTML. The view doesn’t consist of business logic in most
clear designs. The interface is fit for purpose and is the area of
interaction. Therefore you could simply output HTML for consumers to
interact with or output SOAP/XML for businesses to interact with. Both
use the same business logic behind the system otherwise known as the
models and controllers.
In the world of property you could think of the view as the interior
of a property or the outer layer of a property that the inhabitants
interact with. The interior can be customised for purpose and the same
property can have many different types of tenants. For example a
property of a particular design could contain residential dwellings.
The same internal space could easily be used as office space, where
although in the same property has a different purpose. However the
property structure is the same. Therefore the environment in which the
users interact does not interfere with the structure of the building.
Controllers
The controller is where the magic happens and defines the business
application logic. This could be where the user has sent a response
from the view, then this response is used to process the internal
workings of the request and processes the response back to the user.
Taking a typical response where a user has requested to buy a book.
The controller has the user id, payment details, shipping address and
item choice. These elements are then processed through the business
logic to complete a purchase. The data is passed through the system
into the model layer and eventually after the entire request satisfies
the business definitions, the order is constructed and the user
receives their item.
If we compare this to a property, we could compare the ordering of a
book online to turning on a light switch. A tenant will flick the
switch to on just like ordering a book. The switch itself is an
element in the view layer which sends the request to the controller
just like clicking a checkout button on a web site. The business logic
in this case is what the electrician installed and are embedded within
the property designs. The switch is flicked, which completes the
circuit. Electricity runs through all the wires including the fuse box
straight through to the light bulb. Just like the user receiving a
book, in this case the tenant receives light. The whole process behind
the scenes involving the electricity cabling is not visible to the the
tenant. They simply interact with the switch within the space and from
there the controller handles the request.
Models
The models in MVC are the bottom most layer and handle the core logic
of the system. In most cases this could be seen as the layer that
interacts with the data source. In systems using MVC, the controller
will pass information to the model in order to store and retrieve
data. Following on from the example above controller definition, this
is where the order details are stored. Additional data such as stock
levels, physical location of product of the book amongst many things
are all stored here. If that was the last book in stock ordered, the
next request for this item may check if it’s available and disallow
the order as the item is no longer available.
Sticking with out example of turning on a light switch, this level in
our structure could be the electricity supply. When the tenant flicks
the switch, the internal circuit must request electricity to power the
request which is similar when the user requested data from the
database, as in data is needed to process a request. If the dwelling
isn’t connected to an electric supply, it cannot complete the process.
Business benefits from using MVC
After you get the message across explaining what MVC is, you will then
have to see what benefits can be obtained from it. I’m not going to go
into a huge amount of detail here are I’m sure you can apply benefits
more accurately which are directly related to you actual situation. To
list just some of the common benefits of an MVC based system here are
a few examples:
Different skill levels can work on different system levels. For example designers can work on the interface (View) with very little
development knowledge and developers can work on the business logic
(Controller) with very little concern for the design level. Then they
simply integrate together on completion.
As a result of the above separation projects can be managed easier and quicker. The designer can start the interfaces before the
developer and vice versa. This development process can be parallel as
opposed to being sequential therefore reducing development time.
Easy to have multiple view types using the same business logic.
Clear route through the system. You clearly know where there different levels of the system are. With a clear route of the system,
logic can be shared and improved. This has added security benefits as
you clearly know the permitted route from the data to the user and can
have clear security checks along the route.
Each layer is responsible for itself. (Relates to point 1) This means that you can have clean file structure which can be maintained
and managed much easier and quicker than a tightly couple system where
you may have lots of duplicate logic.
Having a clear structure means development will be more transparent which should result in reduced development time,
maintenance problems and release cycles if applied properly.
Source: http://www.strongandagile.co.uk/index.php/a-really-simple-explanation-of-mvc/

Another option is keep programming using WebForms, for that, you have to choose the right application:

MVVM - Patterns and Practicality

I've been using MVVM for a while now with WPF. And i've learnt a lot over the course of development (going from never using it, to having a couple of applications developed in it)
However, recently I had some comments directed at the code which made me wonder if i'm doing things the right way. My current setup works (roughly) like this:
Model - Responsible for storing the data, data validation using
IDataErrorInfo and dirty tracking
ViewModel - Responsible for getting the data (from a repository like
pattern) and formatting it for a view's consumption (things like
filtering, ordering) also responsible for command handling from the
view (save, load, filter changes etc)
View - The usual UI stuff
Now it was mentioned to me that i should NEVER have business logic inside the model, and that the model should be as thin as possible, the viewmodel should be responsible for handling things such as data validation and dirty tracking.
I've seen comments and criticism on both sides of this, with people against and for putting logic in the model, What i have yet to see is any actual reasons for these sweeping statements. So id love to know if there is an actual reason i should be refactoring my setup.
Also, given that i do move the logic to the viewmodel, I can see the need for having multiple viewmodels where i currently have a single, for example:
Person - Model
PersonViewModel - Handles the dirty tracking, data validation etc
PersonsViewModel - Handles getting a collection of PersonViewModels,
filtering etc
PersonsView - The UI
This seems a little redundant, but perhaps i'm misunderstanding something. What I'm really looking for is some actual reasons for doing this one way or another, or if this is another argument like the use of code-behind in MVVM (pure opinion with little reasons etc)

High level description of MVVM:
View: User Interface
Model: Business logic and data (e.g Domain Model+Repositories, or Transaction Script+POCO entities, etc)
ViewModel: Data exposted to view in such form, that is easily consumable from view. Wikipedia's definition says: The view model is an abstraction of the view that exposes public properties and commands.
I like the Practical MVVM Manifesto (archived version) principes: Simplicity, Blendability, Designability, Testability.
This is very high level and abstract description and that's why you may find a lot of variations of MVVM. Whatever mvvm style you choose, keep in mind the responsibilities and principles and you should be ok. Try to avoid complexity. MVVM is not a silverbullet and you cannot cover all scenarios with single design pattern. One mvvm implementation may be suitable for one application but not for another. I, for example, build my mvvm architecture from scratch for each new project to ensure the best fit
When is comes to responsibilities:
Take validation as an example:
validation logic that password and repeat password inputs should be equal is clearly presentation logic and should be present in viewmodel. On the other side, there may be business rule, that password must contain at least one special character. This logic should reside in Model, however you may expose it in viewmodel to be easily consumable from view. It's a business logic, but you may need to present it somehow.
if you have application that only uses webservice to retrieve and store then your model will be probably just the data access components.
Here is couple of resources:
Wikipedia: https://en.wikipedia.org/wiki/Model_View_ViewModel.
MVVM is variation of Martin Fowler's MVP pattern, you may find it useful as well: http://martinfowler.com/eaaDev/PresentationModel.html
MSDN (Pattern and practices): https://msdn.microsoft.com/en-us/library/hh848246.aspx

I like to think of the Model layer as anything that has nothing to do with how the app is hosted (i.e. independent of WPF). It is one or more dlls that represent the business domain and the operations that need to be performed in it. If it would make sense to take theses same dlls and use them in a web application, windows service e.t.c then it is usually a sign that the split between Model and ViewModel is appropriate.

There's no simple answer to your question. The simplest answer is that the model and view model should contain the code that you should unit test. The separation between model and view model is a little less distinct. I like to keep the model as simple as possible and limit it to whatever is exchanged with the server tier. The view model should encapsulate the model, and provide any addition functionality (both business logic and abstract presentation logic) so that you can keep the presentation layer as simple as possible (declarative, in the case of WPF XAML).

I see it this way:
Model - Object that can be passed around. A Common type between different layers for communication.
ViewModel - Specifically created for Views. This should contain UI logic, for example, Data Annotations etc will go here. You might also call your web service methods here (assuming your actual business logic sits in a facade layer, or your database logic sits in a different layer/project) to populate the Views, dropdowns etc. You might end up with multiples of these per view, depending on your design.
View - UI Only.
I am not afraid to put external calls in the ViewModel

ObservableCollection in the service layer of the WPF MVVM application

Examples of WPF MVVM apps I've seen on the Internet consider VM a layer which interacts with a service layer which either uses "old" events from an external library, or interacts with web using HTTP or whatever. But what if I build all M, V, VM, service and other parts myself? How to properly build interaction between the service layer and the viewmodel layer? Can I just put ObservableCollection<OrderModel> into the service and return it as is from the viewmodel for the view, or is it considered a bad approach and there're better alternatives?

You can do this - of course you can. The primary reason to do such a thing would be to reduce duplication across multiple WPF applications.
However, a challenge you might have in some scenarios, depending on your service layer/data layer implementation, is long-running services that in turn use database connections. ObservableCollections are enticing from the point of view of having the service layer automatically synchronising changes made by an application to a data store; however it gets complicated when you want to communicate changes that originate from the data itself (i.e. in response to some other process that creates/modifies data).
The service layer can't really replace the instance (i.e. in the case of large-scale changes), since it is no longer the sole owner of the reference - but even if it could, replacing the instance would pretty much break any binding the UI has to the collection.
So you stick to trying to keep the one instance up to date. If your services are bound to a database, then unless you code-up some form of long-running monitoring process within your service, the only simple way to keep an ObservableCollection up to date after it's been dished out would be to hold database connections/contexts (in the case of Linq to Sql or EF) open - because otherwise related objects etc are not going to be able to retrievable (unless you force all objects to be read in one go - which is not scalable).
Okay, so it's possible to write some form of management layer which can manage the connections for you - but in addition to the inevitable polling, or perhaps SQL Server notifications that you might use, I believe the code might get quite complicated.
That said, it really does depend - that particular issue is one to look out for, but it might be that you have an architecture and environment in which such things simply don't matter.
My advice, if you want to try it - go ahead. For me? I've thought about it - and beyond adding INotifyPropertyChanged to some domain models, I stick to the idea that an application has it's own VM. Multiple applications might share the same VM - but that won't be internal to the service layer itself.
A service layer provides access to data and business logic in a typically one-shot way. Classes in the VM pattern are intended to have a much longer lifespan - and trying to code a long-running service layer is notoriously very hard to do - especially if you want it to try and solve all the problems that all future applications might present. Inevitably you will end up coding services or VM types within the service layer for a single application only - in which case it might as well have gone in that App's codebase.

I'd be tempted to use an ObservableCollection only from the point at which the "observable" aspect is relevant, which is generally the VM exposing something to the V. Further down the stack (i.e. the M) I'd be tempted to stick with more generic things like lists and collections (unless you specifically need for things to be otherwise). Its easy enough for the VM to create an ObservableCollection based on any old IEnumerable in any case.
A reasonable question though, especially as ObservableCollection's placement in the System.Collections namespace would seem to suggest that Microsoft don't particularly think of this as a specialized class (and certainly not wpf-specific).

I wouldn't do that for a number of reasons. They're documented here: Common mistakes with an observable collection
The author goes through several mistakes people make with them, including using them in the service layer.