Home/ Questions/Q 89435
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T22:42:58+00:00

I’m making a WPF application that is comprised of Screens (Presenter + View). I

  • 0

I’m making a WPF application that is comprised of Screens (Presenter + View). I want to be able to declare these screens in a config file or SQL database. I have been trying to come up with a good solution I’ve given up and am asking how some of you design this sort of thing? I’ve been working at this for over a week and every solution I come up with stinks.

In my WPF application I have a treeview that represents screens. When the user clicks on a node, the screen is loaded. I want to be able to populate the treenodes from a config file or database. The program should not care where these are stored so I can swap out a config store for a database store. If I have the screen info stored I can also use an IOC container to instantiate the screens for me and retrieve them by name. Here is a sample of the config file schema that I have come up with:

<screen name='' title='' presenterType='' viewType=''/> <screen ...>     <screen .../>     <screen .../> </screen> <screen .../>

The latest solution I have come up with is to use a ScreenService that asks a ScreenRepository for ScreenInfo objects. Then I will be able to populate the treeview and IOC container with this information.

Does this sound like a good solution? What would you do different? And, how do you design this sort of system in your own programming?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. When you return objects out your factory method you can include a hierarchy as well. For example my shape factories have two methods One returns a list of shapes that added to a master list, Another return Shape Libraries. While User can define and alter the actual libraries I have a default set automatically generated to use for troubleshooting and initial installation. It is hierarchical.

    However A ShapeLibrary is comprised of ShapeLibraryItem. A ShapeLibraryItem has a key stored with it so it can pull the shape out of the master program list. So a button or item is clicked, it looks at the ShapeLibrary Item it is associated with. Get the key, uses the key to get the shape program and then uses the UI Interface to draw the screen.

    IF your screen has the hierarchy info embedded as one of it’s many properties then I recommend that you separate it out into a Hierarchy Item. A HierarchyList then can be created that is comprised of HierarchyLists OR HierarchyItem. I would make a IHierarchyItem interface so that HierarchyLists look like a item.

    The main difference is behavior. When you click a HeirarchyList will bring up another list (or expand, etc) a true Item will bring up a screen.

    So your assembly will have two class marked with one of two attributes. One will be the ScreenFactory, and the other will be the HierarchyFactory.

    Note you don’t have to use keys you could directly link a HierarchyItem to the shape. I use GUID keys to avoid coupling every single time. Coupling is not always bad but it isn’t always good either. Since GUID are effectively unique it works out the same.

    As for performance you will have to hundreds of ASSEMBLIES before you notice it. Remember you don’t have to have an assembly for each screen. Just group them logically into a handful of assemblies and you are good to go.

    • 0