Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>Summary</h2> <ul> <li>The usage of all patterns is situational, and the benefit (if there is any) always lies in reduced complexity.</li> <li>MVVM guides us how to distribute responsibilities between classes in a GUI application.</li> <li>ViewModel projects the data from the Model into a format that fits the View.</li> <li>For trivial projects MVVM is unnecessary. Using only the View is sufficient.</li> <li>For simple projects, the ViewModel/Model split may be unnecessary, and just using a Model and a View is good enough.</li> <li>Model and ViewModel do not need to exist from the start and can be introduced when they are needed.</li> </ul> <h2>When to use patterns and when to avoid them</h2> <p>For a sufficiently simple application every design pattern is overkill. Assume you write a GUI application that displays a single button which when pressed shows "Hello world". In this case, design patterns like MVC, MVP, MVVM all add a lot of complexity, while not adding any value whatsoever. </p> <p>In general, it is always a bad decision to introduce a design pattern just because it somewhat fits. Design patterns should be used to reduce complexity, either by directly reducing overall complexity, or by replacing unfamiliar complexity with familiar complexity. <strong>If the design pattern cannot reduce complexity in either of these 2 ways, do not use it.</strong></p> <p>To explain familiar and unfamiliar complexity, take the following 2 sequences of characters:</p> <ul> <li>"D.€|Ré%dfà?c"</li> <li>"CorrectHorseBatteryStaple"</li> </ul> <p>While the second character sequence is twice the length of the first sequence, it's easier to read, faster to write, and easier to remember than the first sequence, all because it's more familiar. The same holds true for familiar patterns in code.</p> <p>Be conscious of the fact that some patterns may not be familiar to all developers who are going to work with the code in the future. In terms of the previous example, the following sequence may or may not be easier to remember than either of the sequences above, depending on the experience and training of the person remembering it: "3.14159265358979323846264338327950". In some cases where more advanced design patterns are involved, it only makes sense to use a design pattern if the maintenance developers are already familiar with it.</p> <h2>MVVM</h2> <p>That said, let's dive into the topic of MVVM by means of an example. MVVM guides us how to distribute responsibilities between classes in a GUI application (or between layers - more about this later), with the goal of having a small number of classes, while keeping the number of responsibilities per class small and well defined.</p> <p>'Proper' MVVM assumes at least a moderately complex application, which deals with data it gets from "somewhere". It may get the data from a database, a file, a web service, or from a myriad of other sources. </p> <h3>Example</h3> <p>In our example, we have 2 classes <code>View</code> and <code>Model</code>, but no <code>ViewModel</code>. The <code>Model</code> wraps a csv-file which it reads on startup and saves when the application shuts down, with all changes the user made to the data. The <code>View</code> is a Window class that displays the data from the <code>Model</code> in a table and lets the user edit the data. The csv content might look somewhat like this:</p> <pre><code>ID, Name, Price 1, Stick, 5$ 2, Big Box, 10$ 3, Wheel, 20$ 4, Bottle, 3$ </code></pre> <p>New Requirements: Show price in Euro</p> <p>Now we are asked to make a change to our application. The data consists of a 2-dimensional grid which already has a "price" column, containing a price in USD. We need to add a new column which shows prices in Euro in addition to those in USD, based on a predefined exchange rate. The format of the csv-file must not change because other applications work with the same file, and these other applications are not under our control. </p> <p>A possible solution is to simply add the new column to the <code>Model</code> class. This isn't the best solution, because the <code>Model</code> saves all the data it exposes to the csv - and we do not want a new Euro price column in the csv. So the change to the <code>Model</code> would be non-trivial, and it would also be harder to describe what the Model class does, which is a <a href="http://en.wikipedia.org/wiki/Code_smell" rel="noreferrer">code smell</a>.</p> <p>We could also make the change in the <code>View</code>, but our current application uses data binding to display the data directly as provided by our <code>Model</code> class. Because our GUI framework doesn't allow us to introduce an additional calculated column in a table when the table is data bound to a data source, we would need to make a significant change to the <code>View</code> to make this work, making the <code>View</code> a lot more complex.</p> <p>Introducing the ViewModel</p> <p>There is no <code>ViewModel</code> in the application because until now the <code>Model</code> presents the data in exactly the way the Csv needs it, which is also the way the <code>View</code> needed it. Having a <code>ViewModel</code> between would have been added complexity without purpose. But now that the <code>Model</code> no longer presents the data in the way the <code>View</code> needs it, we write a <code>ViewModel</code>. <strong>The <code>ViewModel</code> projects the data of the <code>Model</code> in such a way that the <code>View</code> can be simple.</strong> Previously the <code>View</code> class subscribed to the <code>Model</code> class. Now the new <code>ViewModel</code> class subscribes to the <code>Model</code> class, and exposes the <code>Model</code>'s data to the <code>View</code> - with an extra column displaying the price in Euros. The <code>View</code> no longer knows the <code>Model</code>, it now only knows the <code>ViewModel</code>, which from the point of the <code>View</code> looks the same as the <code>Model</code> did before - except that the exposed data contains a new read only column.</p> <p>New requirements: different way to format the data</p> <p>The next customer request is that we should not display the data as rows in a table, but instead display the information of each item (a.k.a. row) as a card/box, and display 20 boxes on the screen in a 4x5 grid, showing 20 boxes at a time. Because we kept the logic of the <code>View</code> simple, we simply replace the <code>View</code> entirely with a new class that does as the customer desires. Of course there is another customer who preferred the old <code>View</code>, so we now need to support both. Because all of the common business logic already happens to be in the <code>ViewModel</code> that is not much of an issue. So we can solve this by renaming the View class into <code>TableView</code>, and writing a new <code>CardView</code> class that shows the data in a card format. We will also have to write some glue code, which might be a oneliner in the startup function. </p> <p>New requirements: dynamic exchange rate</p> <p>The next customer request is that we pull the exchange rate from the internet, rather than using a predefined exchange rate. This is the point where we revisit my earlier statement about "layers". We don't change our <code>Model</code> class to provide an exchange rate. Instead we write (or find) a completely independent additional class that provides the exchange rate. That new class becomes part of the model layer, and our <code>ViewModel</code> consolidates the information of the csv-Model and the exchange-rate-Model, which it then presents to the <code>View</code>. For this change the old Model class and the View class do not even have to be touched. Well, we do need to rename the Model class to <code>CsvModel</code> and we call the new class <code>ExchangeRateModel</code>.</p> <p>If we hadn't introduced the ViewModel when we did but had instead waited until now to do so, the amount of work to introduce the ViewModel now would be higher because we need to remove significant amounts of functionality from both of the <code>View</code> and the <code>Model</code> and move the functionality into the <code>ViewModel</code>.</p> <h2>Afterword on Unit Tests</h2> <p>The primary purpose of MVVM is not that the code in the Model and the ViewModel can be put under Unit Test. The primary purpose of MVVM is that the code is broken up into classes with a small number of well defined responsibilities. One of several benefits of having code consisting of classes with a small number of well defined responsibilities is that it is easier to put the code under Unit Test. A much larger benefit is that the code is easier to understand, maintain, and modify. </p>
    singulars
    1. This table or related slice is empty.
    1. POWhy use MVVM?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USPeter
    1. USPeter
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy use MVVM?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload