ExDM Add documentation to the selected parts of the code #369

- working on the MVVM in the README.MVVM.md document

ExDataManagement/GraphicalData/README.MVVM.md

@@ -179,12 +179,32 @@ The next topic is a layered model called MVVM. It stands for model, view, view-m
 
 In other words, we will talk about the program architecture keeping in mind that the program is only a sequence of characters. Here, unfortunately, I often encounter the practice of disregarding the principles of layered program structure, because it complicates, and limits, and it is easier and possible to live without it, etc. Let us note that we have three significantly different worlds here. The first is the model mentioned in the topic, i.e. MVVM. We don't see any signs of his presence yet, but he appeared in the context of engineering a graphical user interface. The second one is a typical program architecture, which also distinguishes three layers, but this time called presentation, logic, and data. The third world lacks of layers. If these worlds exist there are probably some reasons behind each of them, even trivial ones, such as lack of knowledge. To rule out a lack of knowledge, let's take a closer look at this topic.
 
-Let's start with the fact that our sample program has three projects. The first one with the View suffix is ​​based on Framework 4.61, so it is dedicated to a specific implementation of the .NET library. This limits the portability on other hardware and system platforms, but there is no option because WPF is a technology dedicated to Windows. The remaining projects are based on .NET Standard. .NET Standard is an abstract definition of the .NET library, i.e. it does not contain any implementation, only abstract definitions. Thanks to this, projects based on the .NET standard are portable and once the library is compiled, it can be implemented on any system platform for which there is a .NET implementation. Without going into details, we can illustrate the relationship between these projects as follows. There is a legend for those curious about what the individual arrows mean. Now, for the sake of simplicity, we are only interested in the direction of these arrows.
-
 ### 6.2. Layer Implementation using project concept
 
+Let's start with the fact that our sample program has three projects. The first one with the View suffix is ​​based on Framework 4.61, so it is dedicated to a specific implementation of the .NET library. This limits the portability on other hardware and system platforms, but there is no option because WPF is a technology dedicated to Windows. The remaining projects are based on .NET Standard. .NET Standard is an abstract definition of the .NET library, i.e. it does not contain any implementation, only abstract definitions. Thanks to this, projects based on the .NET standard are portable and once the library is compiled, it can be implemented on any system platform for which there is a .NET implementation. Without going into details, we can illustrate the relationship between these projects as follows. There is a legend for those curious about what the individual arrows mean. Now, for the sake of simplicity, we are only interested in the direction of these arrows.
+
 ### 6.3. MVVM as Sub-layers of the Presentation Layer
 
+The MVVM  is a design pattern commonly used in Windows Presentation Foundation to structure the code and separate concerns. Hence, we have the word presentation in the name, in the context of the general architecture, we can assume that the layers of the MVVM model contribute to the presentation layer of a general architectural model. Based on this detailed analysis, let's try to answer a more general question: what is a layer, and how to implement it?
+
+Before examining the gathered examples, first I must remind you that the algorithm development is far beyond the scope of our discursion. Second, to make the discursion practical we must apply the layered pattern to the program text but not to the thinking process. The main goal is to apply the layered pattern rules directly to the program text as a result of the implementation of the algorithm derived from a research process. To promote a practical approach, I propose investigating this issue in the context of the semantics and syntax of a selected programming language. Although we are using a concrete development environment, the main hope is that the proposed approach is easily portable. All the examples in concern have been added to the `Graphical Data` folder. Check out the solution `ExDataManagement`solution to follow me in this respect.
+
+We already proved that theoretically a layered program design pattern is very beneficial. Simplifying, by design, layered program design pattern applies to the program as one whole - keeping in mind - that the program is just a text. A program is just a text compliant with a selected programming language. Hence the pattern including the layers and layers relationship must be expressed using terminology defined by the language itself. Further discussion may depend on the selection of a concrete programming language. Therefore, according to the rules the further discussion is conducted using CSharp as the programming language and Visual Studio as the development environment.
+
+Languages offering object-oriented programming usually use the custom types definitions as building blocks that take responsibility to implement the algorithm/data in concern. It is also the case for the CSharp programming language. Additionally the layered architecture is also abstract term and therefore must be implemented somehow. To implement the layers I propose sets of custom-type definitions. Answering the question of what is a layer, the answer is it is a set of custom types. In maths, sets are a group of well-defined entities called members of the set. In the proposed case the well-defined entity is a custom type - a language construct. The set notion is derived from the mathematical theory and is well known from the background school education, hence we may skip deep diving into this theory. The only important thing is how to recognize the membership. There must be a boundary that we can use to distinguish if a type belongs to the selected set or not. To make the layer unambiguous it must be assumed that any type belongs only to one set, to one layer. This way we can convert the discussion about mathematical sets to an examination of types grouping. Now we must answer a question about how to recognize the membership of a type. In other words the fact of being a member of a selected group.
+
+The namespace construct could be a relief to help make up a boundary of the set and finally of a layer. Namespaces are used to organize and provide a level of separation of program parts and to avoid name collisions. The namespace unique name could be used as a prefix of an identifier of the definition to make the full name unique in the program scope. On the other hand, the namespace can also be considered a container or an organization unit of definitions. This concept perfectly fits the concept of grouping or more formally enforcing set membership of types.
+
+This concept is illustrated in the figure below where we have three main layers created using the proposed method. It was generated from the text gathered in the `Graphical Data` folder. This image has been created using a code analytic tool embedded in the development environment. After removing not important parts, thanks to this image we can distinguish three layers, called View, ViewModel, and Model. It is also worth notifying that internally inside the layer circular dependencies are perfectly OK. Let me recall that only between layers we must have unidirectional top-down dependencies.  As a side effect of using the embedded tool to analyze the architecture of the program text, there are different kinds of arrows. We may safely neglect this. This tool is not a subject of our examination.
+
+![MVVM Layered Architecture](.Media/MVVMLayeredArchitecture.png)
+
+Minimizing the number of projects in a solution reduces maintenance costs and reduces dependency hell, so if portability is not a goal it may not be worth forcing separate projects. However, here we are dealing with a scenario where portability is critical, so separating projects is justified. The purpose of implementing layers using projects may be to minimize the program area dependent on technology by limiting the dependency on one project only. Let me give you an example. There is no doubt.  A graphical user interface should be implemented differently for desktop devices equipped with a high-resolution monitor and for smartphone devices. So let's try to put forward the thesis that layers can be implemented using projects.
+
+From the point of view of the development environment, a project is just an organizational unit within the solution. Solution and project are concepts related to the tool like Visual Studio, and not to the program text consistent with the selected programming language. This would indicate that using projects to implement layers is not a good idea because it has no direct connection with the programming language. However, we must consider an important feature of a solution project - the project is also a compilation unit. Therefore, its content must be consistent and compliant with a programming language. It can be treated as the boundary of a set of type definitions. Unidirectional and hierarchical top-down relationships can be implemented using the References/Dependencies project branches, as shown in the figure below. Additionally, in the case of projects compared to namespaces, type definitions visibility control can be employed, which should further facilitate the implementation of a layer as a set of type definitions and hierarchical unidirectional relationships between layers.
+
+![MVVM Layered Architecture Using Projects](.Media/MVVMLayeredArchitectureProjectBased.png)
+
 ### 6.4. Diagram View
 
 ### 6.5. Porządkowanie diagramu
@@ -212,13 +232,9 @@ Let's start with the fact that our sample program has three projects. The first
 
 ## Model warstwowy
 
-### Model Warstwowy Wprowadzenie
-
-Zacznijmy od tego, że nasz program przykładowy ma dwa projekty. Pierwszy z przyrostkiem View bazuje na Framework 4.61, więc jest dedykowany dla konkretnej implementacji biblioteki .NET. To ogranicza pole manewru w zakresie jego wykorzystania na innych platformach sprzętowych i systemowych, ale wyjścia nie ma, bo WPF jest technologią dedykowaną dla Windows. Drugi projekt bazuje na .NET Standard. .NET Standard jest abstrakcyjną definicją biblioteki .NET, tzn. nie zawiera żądnej implementacji, a jedynie abstrakcyjne definicje. Dziki temu projekty bazujące na .NET standard są przenośne i raz skompilowana biblioteka może być realizowana na każdej platformie systemowej, dla której istnieje implementacja .NET. Nie wchodząc w szczegóły, zależność pomiędzy tymi projektami możemy zilustrować w następujący sposób. Dla dociekliwych co oznaczają poszczególne strzałki jest legenda. Na potrzeby tej lekcji nas będzie interesował tylko zwrot tych strzałek.
 
 ### Czy projekt może być warstwą
 
-Odpowiadając na pytanie co to jest warstwa, spróbujmy zatem postawić tezę, że warstwy powinny być zaimplementowane z wykorzystaniem projektów. Zauważmy, że w poprzedniej lekcji używałem tego samego programu przykładowego, ale wszystko było w jednym projekcie i działało. Generalnie minimalizowanie liczby projektów prowadzi do zmniejszenia kosztów utrzymania, więc jeśli przenośność nie jest wartością dodaną, to może nie warto wydzielać na siłę osobnych projektów. Tu jednak ćwiczymy scenariusz, w który przenośność jest krytyczna, więc rozdzielenie projektu na dwa jest konieczne. Wydzielenie części programu do  osobnego projektu - z punktu widzenia jego semantyki, więc działania - nic nie zmieniło. Tu trzeba podkreślić, że projekt to tylko jednostka organizacyjna w ramach solution. Solution, czyli rozwiązanie i projekt to pojęcie związane z narzędziem jakim jest Visual Studio, a nie z semantyką programu. Tak, czy inaczej używanie projektów do implementacji warstw to nie jest dobry pomysł. Tu jednak ważne zastrzeżenie, tylko dzięki odpowiedniej architekturze programu wydzielenie jego fragmentu do osobnego projektu nie było trudne. Natomiast warunkiem koniecznym, aby ten proces w ogóle był możliwy jest, aby referencje, czyli odwołania do definicji typów były wyłącznie hierarchiczne, ponieważ tylko takie można zdefiniować dla projektów. Z rysunku oraz z gałęzi references i Depencies widać, że w tym przypadku jest to spełnione.
 
 ### MVVM jako podwarstwy warstwa prezentacji