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.


Global Structure

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.

UI Consideration

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.

Backend Consideration

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.

image1 image2

image3 image4

image5 image6


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.

  • The images are tiny when clicked, it appears you linked the thumbnails rather than the original images. – Flater Nov 13 at 7:00
  • @Flater yes I did, I didn't wanted to overload the post but didn't think it would open the thumbnails. I edited the post. – Damien Nov 13 at 7:13
  • 1
    theres too much to cover really, but my advice would be DO use MVVM, most WPF examples are setup assuming you will and some controls force it. and you seem to be missing a models library – Ewan Nov 13 at 7:45

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.