Announcement of Presenters and Views
I am creating a WPF application composed of screens (Presenter + View). I want to be able to declare these screens in a config file or SQL database. I was trying to come up with a good solution that I passed and I ask how do some of you develop this kind of thing? I've been working on this for over a week and every solution I come up with stinks.
In my WPF application, I have a tree that represents screens. When the user clicks on a node, the screen loads. I want to be able to populate treenodes from a config file or database. The program doesn't have to care where they are stored, so I can change the configuration store for the database store. If I have information about the screen, I can also use the IOC container to instantiate for me and get them by name. Here is an example of a config file schema that I ran into:
<screen name="" title="" presenterType="" viewType=""/>
<screen ...>
<screen .../>
<screen .../>
</screen>
<screen .../>
The last solution I came up with is to use a ScreenService, which requests a ScreenRepository for ScreenInfo objects. Then I can populate the IOC tree and container with this information.
Does this sound like a good solution? What would you do differently? And how do you create such a system in your own programming?
source to share
When you return objects from your factory method, you can include a hierarchy as well. For example, my form factories have two methods. One returns a list of shapes added to the main list, other return form libraries. While the user can define and modify the actual libraries, I have a default set automatically generated for use in troubleshooting. It is hierarchical.
However, ShapeLibrary is composed of ShapeLibraryItem. The ShapeLibraryItem has a key stored with it so that it can pull the shape out of the main programs list. So, when a button or element is clicked, it looks at the ShapeLibrary element it is associated with. Get the key, uses the key to get the shape program, and then uses the UI to draw the screen.
If your screen has hierarchy information built in as one of many properties, then I recommend that you split it into a hierarchy item. Then a HierarchyList can be created, which consists of HierarchyLists OR HierarchyItem. I would make an IHierarchyItem interface to make the HierarchyLists look like an item.
The main difference is behavior. When you click on HeirarchyList, you will open another list (or expand it, etc.), True Item will display the screen.
Thus, your assembly will have two classes with one of two attributes. One will be ScreenFactory and the other will be HierarchyFactory.
Note that you do not need to use keys that you could directly bind to the HierarchyItem. I use GUID keys to avoid connecting every time. Grip isn't always bad, but it's not always good. Since the GUID is truly unique, it works the same way.
In terms of performance, you will need to have hundreds of ASSEMBLIES before you notice this. Remember, you don't need to have an assembly for every screen. Just group them logically into multiple assemblies and you're good to go.
source to share
In general, you need to use the Factory pattern for these types of situations. Your combination of ScreenService, ScreenRepository and Screeninfo sounds like you've nailed it. Here is a general overview of what a Factory Pattern is. You can use the Wikipedia article as a starting point to see if there are any deviations or aspects that you missed.
I have developed and maintain a CAD / CAM application that has several libraries of predefined parametric shapes where the user can enter multiple dimensions and calculate the shape to be cut. Each form has its own screen setting. I use a similar pattern for you when running my applications.
I go through the form library directory for each assembly, select the Factory class, which has a method that retrieves the list of shapes, loads it into the main list. When the user clicks on a toolbar button or selects from a list, the software then uses a key to pull the correct shape out of the list that the IShapeScreen interface provides. The shape manipulating shapes uses this interface to draw the correct input screen for this shape.
This method has worked for almost ten years without any significant problems, and it is just as important not to leave me with "Oh, I wish I had done this when I developed it." So I think you are on the right track.
Note that you may not need to use a text configuration file. Using attributes, some of the interfaces you define, and the .NET reflection API you can just throw the DLLs into a directory, the software can scan that directory and pull in the objects you want correctly. In the screen objects of your case. However, if you want a human to edit the configuration, a text file is required. I am assuming you are using the .NET API when you checked .NET.
source to share
Sorry I should have mentioned I am using .NET 3.5. I am so used to posting on the ASP.NET forum that I forgot about.
I like scanning the idea of assemblies, but I would like it to be defined as a hierarchy to populate the tree structure. Also, what is the performance score of using reflection to scan assemblies versus a config file or database? Is this a noticeable difference or so small that no one can tell?
The application I am creating must be used internally by our company. It should be hierarchical for navigation, so our screens can be easily found. Scanning the build folder would be nice, because we could make a module through it and into that folder, and the application will automatically pick it up. This will lead to the problem of presenting screens in a hierarchical manner. In addition, we would like to implement authorization so that users only see the screens they are allowed to use.
Thanks for the answer. I love to see others do things. It helps me understand a lot of these design concepts since I'm just getting started on the design patterns path (just ordered the PEAA book). Anyone else please share your thoughts. It might also help someone else like me who stumbled upon this question.
source to share