MVVM architecture: one model - several view models + place for data access
<p>I'm quite confused about the architecture of my MVVM application (formerly WinRT, now targeting UWP) concerning data access. I'm quite unsure how to propagate changes across the UI and where to put access to the data layer.</p>

<p>Here's the basic architecture:</p>

<ol>
<li><strong>Model layer:</strong> contains models that only have auto properties (no navigation properties that reference other models, just Ids; so they are basically just representations of the database). They don't implement INotifyPropertyChanged.</li>
<li><strong>Data acccess layer:</strong> A repository that uses sqlite-net to store models in a database. It exposes the basic CRUD operations. It returns and accepts model from the model layer.</li>
<li><strong>ViewModels</strong>: 

<ul>
<li><strong>ViewModels for the Models</strong>: They wrap around the models and expose properties. Sometimes I two-way bind content of controls (e.g. TextBoxes) to properties. The setters then access the data layer to persist this change.</li>
<li><strong>PageViewModels for Views</strong>: They contain ViewModels from above and Commands. Many Commands have become very long as they do the data access, perform domain specific logic and update the PageViewModels properties.</li>
</ul></li>
<li><strong>Views (Pages)</strong>: They bind to the PageViewModels and through DataTemplate to the ViewModels for the models. Sometimes there is two-way databinding, sometimes I use Commands.</li>
</ol>

<p>I now have several problems with this architecture:</p>

<p><em>Problem 1:</em> One model can be represented on the screen at several palaces. For example, a master-detail view that displays a list of all available entities of a type. The user can select one of them and its content is displayed in the detail view. If the user now changes a property (e.g. the model's name) in the detail view, the change should be immediatelly reflected in the master list. What is the best way of doing this? </p>

<ol>
<li>Have <strong>one ViewModel for the model</strong>? I don't think this makes much sense, as the master list needs only very little logic, and the detail view much more.</li>
<li>Let the <strong>model implement INotifyPropertyChanged</strong> and thus propagate the change to the ViewModels? The problem I have with this, is that the data layer currently doesn't guarantee that the objects it returns for two read operations on one model id are identical - they just contain the data read from the database and are newly created when they are read (I think that's the way sqlite-net works). I'm also not really sure how to avoid memory leaks happening because of all the PropertyChanged event subscriptions from the ViewModels. Should I implement IDisposable and let the PageViewModel call its children's Dispose() method?</li>
<li>I currently have a <strong>DataChanged event on my data access layer</strong>. It is called whenever a create, update or delete operation occurs. Each ViewModel that can be displayed simultaneously listens to this event, checks whether the changed model is the one its the ViewModel for and then updates its own properties. Again I have the problem of the memory leak and this becomes slow, as too many ViewModels have to check whether the change is really for them.</li>
<li>Another way?</li>
</ol>

<p><em>Problem 2:</em> I'm also not sure whether the place I access data is really well chosen. The PageViewModels have become extremely convoluted and basically do everything. And all ViewModels require knowledge of the data layer with my architecture.</p>

<p><strong>I've been thinking of scrapping data access with sqlite-net and using Entity Framework 7 instead.</strong> Would this solve the problems above, i.e. does it guarantee object identity for one model when I use the same context? I also think it would simplify the ViewModels as I rarely need read operations, as this is done through navigation properties.</p>

<p>I've also been wondering whether having two way databinding is good idea at all in a MVVM application, as it requires the property setter to call the data access layer to persist the changes. Is it better to do only one-way binding and persist all changes through commands?</p>

<p>I'd be really happy if someone could comment on my architecture and suggest improvements or point to good articles on MVVM architecture that focus on my problems.</p>