As I design the Visual Studio project structure for my new open source Contact Manager, which I am writing for a local religious organization pro bono, I have to keep a few things in mind:
- My vision statement of “create a contact management system for the web, desktop, and phone utilizing the same code-base. It should be extensible so that additional modules, such as a donation module, can be easily added reusing the existing infrastructure and components”.
- The contact manager utilizes user information – these are components that will be reusable across future modules as well as applications. We’ll want to place these components in a Gwn.Global.xxxxx projects (figure 1).
- The desktop and web applications can access the business [and thus data access layers] directly – important because the client wants to have an on-site SQL database as well as a “cloud” based SQL database (they will be synchronized). The desktop app will be configured for the on-site database and the web application for the cloud database (figure 3)
- The mobile applications: tentatively Google Kotlin for Android, and Apple Swift for IOS, will be mainly presentation layers consuming a service layer for the cloud database (figure 2).
The use of MVVM over MVPVM has been a debate that I usually have with team members during initial planning, in some cases I win, other times I lose – I’m a team player so when the decision is made, I roll up my sleeves and make it work.
While planning/diagramming the project structure that I will use for this solution, it quickly became apparent why the Model-View-Controller (MVC) Presentation Model had architects of the day wanting to evolve to the Model-View-Presenter (MVP) – Martin Fowler discusses it in his article on GUI Architectures.
Before continuing… What does Presentation Model have to do with MVVM? This tidbit of information is the contextual glue that bridges the gap between our early architects with todays – we lack a common core of experience so we missed this important lesson. John Gossman, the founding father of MVVM noted that MVVM is a WPF-specific version of the PresentationModel Pattern, versus the ApplicationModel pattern which permitted the view model to access the view – seen as a “a bit of dirty work”. The PresentationModel pattern does not allow access to the view as it would prevent the reuse of the view model with other views, which is a well understood MVVM pattern rule.
When we view the power of separated presentation, we have to do so within the context of MVP versus MVVM, because as our early architects taught us – MVP solves the problems of MVC. One such problem rears its ugly head in the diagram below – at least if we were to use MVVM for this project, which is not my preference. With MVVM, our ViewModel[s] would be tightly coupled to our business logic layer and data transfer objects - we could not reuse them in any other module [without pulling in the kitchen sink]. In contrast the MVPVM ViewModel and View are completely decoupled and these components can be easily reused. Note on the right that my Gwn.Global.Presentation project is planning to include all reusable views and view models for user specific information [which makes sense as user information is reusable].
Ironically, Microsoft’s ASP.NET MVC is the same pattern as MVPVM (presentation layer in figure 1), the irony being that ASP.NET MVC and SmallTalk MVC have nothing in common as the “controller” has a total different meaning, yet they adopted the newer MVP pattern using an old pattern name. Martin Fowler says the following about this in his article on GUI architectures:
“Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.”
The lesson you don’t want to miss here - a rose by any other name is still a rose. Microsoft didn’t use MVVM, aka PresentationModel pattern, for its ASP.NET MVC framework - they used the MVP [VM] pattern.
Figure 1 draft project structure
Figure 2 mobile service layer
Figure 3 desktop/website