We have the need to develop an offline desktop application for a measurement equipment.
While having quite a bit of experience in C++, We are new to WPF and VS in general.
This software will have a long life cycle and is expected to receive a lot of changes and features over the years. The structure here hence should allow good flexibility but not have too much coding overhead (as we are very limited in resources, start-up).
This system can be used by a wide variety of clients with varying needs. We opted for a Dock / Tab type of user interface where each UI element can be chosen whether to be displayed and where by the user.
This question relates to the overall software structure that is recommended for a Visual Studio solution (not only the UI aspect) and if the solution proposed is good or flawed and perhaps things to improve or consider.
From the information gathered online, it seems a good approach would be to have a single solution containing several projects, the UI being the starting point (exe) and the rest being libraries.
The software itself won't be "massive" and is overall a relatively simple software. Although as given the expected long life cycle 10+ years and the modification and implementation of features all along the way, we want to start with a good architecture, without going to the extremes either.
The approach of the dock / tab UI implementation offers the advantage to code each UI element independently, and thus being able to easily replace, change or add new elements without having dependencies to the backend and perhaps have 3rd party plugins.
Having read/watched quite about the MVVM patterns and the different framework available. It seems to be appropriate for large UI application. In our situation, the trade-off of the MVVM overhead and learning curve might not be worth it given our UI segmentation to small, simple dock type window.
The software we also be partly open to our customer, notably the UI. As they are not "real" programmer, a MVVM pattern might render the task too complex for them as well.
So the preliminary decision is to not use MVVF patterns, but also not having the UI coupled to the backend either.
Given many of the Dock subwindows will have similarities, like graph display, we intend to have a few DockTemplate which can be dynamically arranged by a handler (model?) class.
Other dock window will just be plain specific and in that case the UI specific code would lie directly on the window cs code.
The UI handles only UI code and is not coupled to the backend.
The backend is also split in different specific projects.
There are two goals behind:
- Be able to completely change a specific project and ease the maintainability.
- Be able to share only specific part of the code to our customer while providing the rest as a dll library.
Here is an overview of the structure. The arrows shows the dependencies.
This does not represents the complete structure with all the class but an overview.
Is that structure approach generally good or bad for a VS solution and perhaps some point to fix, improve or pay attention at ?
One of the issue I can see is the coupling with the DataStore, but so far couldn't find a better way to do so.