\n \n What's a Model?\n \n Most applications use data. It could be a User profile or a Todo item. The record can be persisted in a database or\n a file - that is up to the developer. But software needs to represent data as a [class]. It could be in a User\n class or a Todo [class]. This [class] structure is the only way an application can use data. It is the only way it\n can be loaded into memory. It is up to the developer to figure out how to take the data from their database or\n file and fill the [class].\n \n \n Frameworks like Entity Framework can take a database record and put it in a [class]. Other technologies, like\n JSON deserialization can take the JSON emitted by a REST service (which is only a string) and populate a [class]\n with it. Whatever method a developer chooses does not matter, data just needs to be represented as a [class].\n \n INotifyPropertyChanged\n \n In XAML data binding, developers can bind properties of a [UIElement] to a Model (which is a [class]).\n The data binding framework recognizes a [class] and knows how to read its properties and present their values\n in the user interface. For example, a developer might data bind the FirstName property of the User [class] to\n the [Text] property of a XAML [TextBlock]. This would present the FirstName to in the user interface.\n \n \n XAML can data bind in three ways, called modes. [OneTime] binding reads the value of the property when the\n interface is initially rendered, but never reads it again. The other two, [OneWay] and [TwoWay] binding both\n require the class implements [INotifyPropertyChanged] so the [PropertyChanged] event is raised when property\n values change.\n \n \n This event is not raised automatically. The developer must raise the event manually in the\n setter of the property. Because of this, bindable properties cannot leverage the automatic property\n implementation syntax in C#, which looks like: public String FirstName { get; set; } = String.Empty.\n There has been talk about extending the compiler to support [INotifyPropertyChange] with a simple\n property attribute, but it is not part of C# 6 or VS 2015.\n \n One implementation\n \n The implementation of [INotifyPropertyChanged] is quite redundant because a developer would implement it\n about the same way in every Model. Because of this, the implementation is wrapped up in another class and\n used as the abstract based of every Model. This abstract base is called BindableBase and is located in\n the BindableBase.cs file in the project's Mvvm folder. This abstract base is the same in every project\n and many MVVM frameworks ship their own version (which is fundamentally identical).\n \n | \n \n This folder\n \n The following files represent the types used to implement the TODO functionality in this template.\n Each of the types in this folder are inside the [Template10.Models] namespace.\n \n \n - States.cs
\n \n \n A TodoItem can be in one of thre states: NotStarted, InProcess, and Done. These states are defined in\n the States ENUM which resides in the [States.cs] file in this folder. Developers use an ENUM to constrain\n the possible values of a property to a set list.\n \n \n - TodoItem.cs
\n \n \n A TODO list contains zero or more tasks. In this application, we call those TodoItems. This is a class\n that has the task's Title, as well as other properties like State and DueDate. A TodoItem is intended to\n be a member of a TodoList.\n \n \n - TodoList.cs
\n \n \n This TODO application allows the user to create more than one TodoList. For example, the user might create\n a \"grocery\" TODO list and a \"vacation\" TODO list. A TodoItem can be the child of only one TodoList. And,\n A TodoList can have any number of TodoItems as children.\n \n | \n
\n