- 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.