- Posted by christhi on December 5, 2008
When building desktop applications one of the first things you should spend time on is how you would like to compose the application and ask a few questions such as the following:
- Will the application be developed by more than one person?
- Do you want to shell of the application to be loosely coupled from its components or modules (and of each other)?
- Do you want your modules to survive the shell?
- Do you need a seemless means of updating the desktop application to experience a web-like deployment environment?
- Do you want to support online deployments (browser based) as well as installed?
- Do you need to talk to multiple backend components that may speak other languages integrated at the client tier (e.g. portal-like)?
- Do you want a single "pane of glass" to represent one view of the system?
If you answer at least two of these questions with a yes then you should consider Prism 2.0: http://www.codeplex.com/CompositeWPF. I'm always relunctant to call this a framework for building composite applications because of the mental association composite applications get due to some of the perceived compliexities of former technologies. However, Prism is solving this problem in a much cleaner way now and I would not hesitate to suggest that any smart client application at least consider this as a starting point. Too many times I have been approached by customers with rearchitecture challenges such as having to migrate a desktop application to the web or vice versa. Now you can do both and at the same time! Building desktop applications has always been pretty straight forward so jumping to a composite framework was sometimes like pulling teeth. However compare that to the thought you must give to building true RIA applications and I think it is no less difficult to now consider how to build both at the same time. Fortunately Prism provides this and with technologies you care about; WPF and SilverLight.
I will later blog on the details of Prism 2.0 (which now supports leverage assests for building SilverLight and WPF desktop applications at the same time) so for now I just want to get on my soapbox because frankly I'm a little tired of hearing the same old fodder about how composite apps are too difficult or how the composite application block was too slow. After spending several years working with several CAB customers at the Microsoft Technology Center in Austin as "lab rat" I'm very confident on where we are today with "integrating desktop frameworks" such as Prism so I encourage you to check it out. When approached by a customer to build anything that touches the desktop it is the first framework I consider. The same benefits you see from portals such as Sharepoint you can get from integrated desktops or composite applications and portals are here to stay. Remember if done correctly any modules you build can be used independently of the framework and as such good patterns and practices will give you a little insurance policy as well as give you a good night sleep (see MVP for details on what I'm talking about).
For a little history on where integrated desktop applications have come from feel free to check out my previous MSDN article at: http://msdn.microsoft.com/de-de/magazine/cc301266.aspx and good luck.
- Posted by christhi on October 3, 2008
Some musing regarding improving performance in your CAB applications .....
For large CAB applications and extremely rich forms, we have found (at the Microsoft Technology Center via our recent client experiences) that MDI applications are very difficult to design in CAB without going throug a few hoops to make sure the app performs well.
If you need an MDI application or if your CAB application needs to create a smart part instance for every data instance e.g. one MVP per customer the please use the following tips this also applies to any large CAB applications..
1. Consider recycling your MVPs at the root workitem level instead of their individual child workitem levels to reduce the working set and speed up load times.
2. Build a global "context service" for all data to be reused from these general views and presenter.
This will provide much more flexibility to allow you to recycle your views and presenters at the root workitem level if you have to.
3. Decouple as much of your state from your presenters or controllers as possible. See #2.
4. Apply .NET application best practices like anything else e.g. implement dispose, eliminate unneeded thread locks,
watch your short term references from your long term objects in CAB there could be many long tern objects, and watch your reflection calls etc.
5. Leverage CAB as intended - don't re-invent the wheel
5a. Override simpleworkitemactivation service if you want to control activation
5b. Add Services to the rootworkitem to avoid re-creating web service proxy when you need them.
6. Push as much SmartParts.Add<> logic at load time vs during navigation to save on builder time during user activity adding anything to CAB is one of the slower activities and will affect peformance
be very strategic about where and when do perform your item collection add in the container.
7. Push as much security as load time as possible and leverage object builder strategy extensions to perform Authz as much as possible
re-evaluating security for every data instance can be very expensive. See Smart Client Software Factory's use of Module Actions for an example.
8. Watch your use of third party controls and monitor how smart parts are removed -- make sure your smart parts aren't being re-called unnecessarily.
9. Use the following steps for removing smart parts on destruction:
1. WorkItem.SmartParts.Remove(theView);
2. ((Disposable)theView.Dispose();
3. IWorkspace.Close(theView);
10. Leverage the smart client software factory classes (even if you dont' want the recipes) such as the ModuleController, you'll end up doing this anyway.
11. Group your Workspace.Show() calls in case you have to place several smart parts on parent at once.
Splitting these up may cause screen flicker if you have logic that runs between each show.
Another option is to set the view's visible property to false until you are ready to show all smart parts. Hourglass is better the than flicker for heavy forms.
12. Only use web proxy to business entity translators where performance is not an issue in that context
consider using wpgen (enable generate serialization assembly in build options in VS.NET
to prebuild the web service proxy serialization assembly and consider using the same types passed back from the web service in your contrext or data services to avoid mapping/conversions
This differs a bit from the reference implementations of the smart client software factory.
13. Make use of UI Extension Sites in all of your navigation controls including any outlook style navigation -- this will simplify your common operations and is a great way to distinquish between commands and events.