Architecting The Bussiness Logic Layer in C# WPF Using MVP, MVC, &/or MVVM (& MVCVM & MVPVM)-CodePudding

This is a multi-step question, but everything is related and falls under the category of architectural patterns in C# when using WPF (Windows Presentation Foundation).

The main idea of these architectural patterns, no matter what language you are using, is to separate the UI from the Data from the Logic. These are 3 different layers.

1. IS IT SAFE TO SAY that since the UI Layer equates to the View Layer, the Data Layer equates to the Model Layer, the Logic Layer is represented by either a Presenter, Controller, or ViewModel?

I DO understand that the ViewModel (MVVM) DOES NOT directly replace Controller (MVC); however, is is correct to categorize them both as the Logic Layer? Same with the Presenter?

2. MVP vs. MVC vs. MVVM vs. MVCVM vc. MVPVM

I have read the answers to this question, but my question is also about MVP, Base Classes, Code-Behind, and the role of the Business Logic Layer. I do like the insight that MVC & MVVM is not an either/or choice, hence parts of my title. I'd also appreciate more help understanding MVCVM & MVPVM. I have also read this stack overflow article, but the picture in the question seems contradictory and the answer is different than the answer I need.

Ideally, answers will have as many of the following as possible:

Flow Diagrams
Similarities & Differences
Pros & Cons
Code Examples

3. Are these statements about MVVM correct?

From the articles I have read, I have surmised that:

The ViewModel binds to the View and the ViewModel has data and commands the View must adhere to
The ViewModel doesn’t know what View is displaying it or where its data is coming from
The ViewModel removes code from XAML code to make XAML editing more independent

4. In MVC, if the Model updates the View how is the Controller (Logic Layer) separating them?

Doesn't it leave the Data Layer & database more vulnerable to attacks from the user via the UI when the Controller isn't the middle man between all communications? Shouldn't the Model update the Controller, which updates the View, instead of the Model directly communicating with the View?

5. Where do Base classes come into play in all this?

6. Where do Code-Behind (.xaml.cs) files come into play as well?

Based on my research, it seems as though with WPF, a View Layer consists of both a .xaml file to display the view and a .xaml.cs file to manipulate the View. This manipulation of the View does not involve logic and therefore does not encroach on the Logic Layer. The code-behind file is only meant to define certain behavior such as animations and other UI component functionality. This functionality is similar to how Javascript can define certain behavior for HTML (not including when JS is used for logic).

Thank you so much in advance for your help!

CodePudding user response：

Here's how I look at things.

MVC can use MVVM in that the ViewModel also has actions which affect the view (which is bound to the ViewModel). This is known as Strong Type Binding in MVC and is a wonderfully elegant pattern once all the kinks are worked out. Make sure to keep an eye on the model state. The model state gives a view into the "automated binding" of the MVC on entry to the controller. Ever wonder how JSON becomes a strong type? It's all done prior to the entry to the controller. ModelState tracks all of that stuff and gives valuable information for debug.

The concept of MVP is simply "I am going to through my new model information into the template to the presentation layer. The template simply auto-fills as a result. No state, just bind to the data and present it.

The ViewModel removes code from XAML code to make XAML editing more independent

I think you meant XAML/code behind, the XAML part is just the template. But yes , it farms off the model and actions to other code and cleans up code behind.

The ViewModel doesn’t know what View is displaying it or where its data is coming from

The ViewModel doesn't know the view; however, it's usually the interface to getting the data. It's true it doesn't know where it's coming from; as in the instance of Entity Framework (the where being configured in Entity Framework via connection strings). The developer must know how to hook up the backend data layer e.g. connection strings, are we using EF or straight SQL, or even Mongo.

The ViewModel binds to the View and the ViewModel has data and commands

So glad you mentioned "and commands", weather it's WPF or MVC, the ViewModel command part is critical.

Where do Base classes come into play in all this?

This is a major tripping point for zillions of developers thinking they understand inheritance. Base Classes define the commonality of any super class. The tripping point is that any Super Class must absolutely adhere (very strictly) to the is-a rule. e.g. a Car class has tires, but tires are not a car. The word "has" is a clue that the tires will be a property; which is contained, in the car. Now should the base class have a tire property? The answer is yes if the base class is just for super classes that have tires, yet it is still a property of the base class which means the tires are contained in the base class, and the base class is inherited by a Car Type.

Remember the Gang of Four in 1987 said "Favor composition over inheritance", this means you want properties or injectable parameters, not inheritance from a base class.

Where do Code-Behind (.xaml.cs) files come into play as well?

In the early days before MVVM they did everything. Later on, as MVVM became more popular and MVVM frameworks appeared, we saw that the MVVM Frameworks were implementing the concept of Model First boot up, the code behind in that architecture did all the wiring between the XAML and ViewModel, in particular the binding aspect.

Finally with the advent of Async first programming techniques, we can now look at even event handlers as mini MVC architecture. Why? because we know that there's the event handler will change some state. Sometimes based on getting data (which now can be done in the async event handler). The model is modified via a Task, and upon exit of the await is no available to the view to bind at will. It's the exact same pattern as MVC.

BTW, all of this is applicable to the front end as well. Typescript has made it so similar to C# there's very little differences. The front-end folks will go on and on about pure functions; however, OOPers; by following the single responsibility principle have been writing pure functions for over 25 years now.

CodePudding user response：

Your answer to 1. is "No". All your other questions seem predicated on 1 being "Yes".

A short and simple illustration: your View includes an accordion with panels in a collapsed/expanded state. So your ViewModel must include some state information, a boolean property, for those view panels. Your viewmodel is a model of the view. It has nothing to do with the business logic or data access layers.

The patterns you presented deal with Presentation. You may enhance or decorate data or business logic entities into presentation models.