File organization of a WPF project

A few months ago I started with a new project at work. The goal is to create a design tool for warehouses and the application will be running on the Windows platform. After the design choice landed on WPF I started to think about the project’s file structure. This is my first Windows application that is not build on Windows Forms but on WPF. The design tool is not that big of an application, so I think my tips in this article will suit small to medium sized applications well.

First of all, how should the application be organized on the highest level? Does the application consist of only one executable file, or one executable file and several assemblies (e.g. DLL files)? For instance, the design tool has an output functionality that formats the warehouse data to a specific protocol and then uploads it to an embedded computer. The output functionality could well be located in a separate project (i.e. an assembly) that is referenced in the main application’s project.

How should the main application’s project be organized (the “WPF”-project)? My personal opinion is that all dialog windows (or views) should be located in the main project and not in assemblies. The assemblies should handle stuff like business logic or data storage, and not user interaction. However, controls (with or without user interaction) could very well be located in assemblies. You should also keep the dialog’s business logic as plain as possible, meaning that code executed when e.g. the OK button is pressed should be fairly simple. When needed, refactor and move the code to a new class or even to another project (e.g. a business logic assembly). When I started to organize the design tool project I found the article A WPF Project Needs Structure posted on the Dr. WPF web site very useful. The article gave me a good starting point which I have adapted to suit the needs of the design tool. The project consists of a number of base folders for the logically different files used in a WPF project. The Controls folder holds the controls that for one or another reason should not be located in a separate assembly. The Resources folder consists of different types of resources, e.g. images, styles, cultural strings etc. I would suggest the use of subfolders in the Resources folder; you might even want to separate small and large images into sub folders. The Views folder holds all the views or dialogs. For most parts, I try to divide views into logical groups. The design tool use different kinds of templates for the data; I therefore have a Templates subfolder. Another approach could be to separate views into the order they are used, if that is applicable. The largest folder is Utils; this folder consists of both business logic and more WPF style functionality such as converters or validation classes.

This is how the design tool project is organized:

• Controls
• ...
• Resource
• CultureStrings
• Controls
• Views
• Common
• DataDefinition
• E.g. XSD files
• Help
• E.g. CHM helper files
• Images
• 32x32
• Icons
• Styles
• Utils
• Converters
• Validators
• ...
• Views
• Data
• Main
• Templates
• ...

Further reading:

• A WPF Project Needs Structure
• XAML Organization