I've received a lot of good advice from Rocky over the past year through this forum and his blog about future direction between SL & WPF. I also read the white paper at magenic on the SL/WPF/WinRT direction. One of the big points I noticed was that the advice seemed to revolve around staying (or getting) in the best shape to make an easier transition to Win 8 / WinRT. I get that. I also get that SL 5 has pretty much closed the gap on what is possible between both SL & WPF. However, my company hasn't even finished rolling out Win 7. WinRT just isn't on the radar, so that transition isn't really a concern for this next iteration.
As my company begins a 15-month journey next month to rewrite a VB6 LOB app (with tons of info and over a hundred different screens) I am primarily concerned about performance. The app is super quick right now. Mgmt. has already stated that speed cannot be compromised. While it will also be challenging to come up with a good UI using newer metaphors that can display so much data, I'm hopeful we can successfully deal with that.
So, my question about the speed revolves around SL being (at minimum) a 3-tier app, vs WPF being easily deployed as either 2 or 3-tier with a simple config change required. While more scalable as 3-tier...we only have 400-500 users, 1/4 of which are remote around the country. How much does scalability matter when talking about that number and distribution of users? If we go SL and find performance issues from the extra hop, we're stuck. If we go WPF and find performance issues from the extra hop, we can always reconfigure to a 2-tier (client/server) deployment. Any thoughts on this matter? Am I needlessly worrying about this or focusing on the wrong thing? Thanks for any advice.
Here're some points that are true for me (our application) regarding performance.
As we will have only few concurrent users (5-50), if it wouldn't be for internet connectivity and security, I would totally go the 2-tier configuration.
The performance issues we foudn so far:
- new UI are slower than WinForms, especially DevExpress WPF (they argue with a lot of features):
to open only a view without a view model or even business objects took sometimes too long: >1 sec MS WPF, > 4 sec DevExpress (other like Telerik are in between).
- for every non-trivial UI we end with tailored Business Object graphs, otherwise you load too much or have to lazy load, which are additional server calls.
Product manager (talking to existing user base) want a better UI experience but a similar speed as in the old direct 2-tier DB access.
- Dropdowns with column data; select by typing in a combobox sometimes on two properties (either text or number)
- Filtering, sorting, grouping of datagrids
- Validating as much as possible while the user enters/modifies data
- Autom. saving and restoring of UI settings (size, filter, sort, groups, collapsed state etc)
- Larger UI (more fields due to bigger screens, or better expand/collapse section vs. old-style open a new dialog window)
All this ends in loading much more data before the user can begin work.
- We try to cache all "static" (which rarely changes) in UI client
- We use user story (screen) tailored object graphs
- We use unit-of-work to load all root object lists needed at once
Thanks, Stefan. Are you drawing a difference between SL & WPF? Or between XAML-based apps and WinForms?
A difference between WPF and WinForms. And even worse, we've apparently choosen the lamest components regarding performance (measure & layout): 6 times slower than raw Microsoft WPF.
The VB6 thing crossed my mind: if you plan to build the new app with the VB6 people, just keep in mind that they might not yet know the impact of 3-tier, creating business objects, or service calls.
The last VB6 guy left has transitioned already to CSLA / SL. The problem is that a much smaller app we recently did with SL4 (3-tier) & CSLA comes across as slower to people. The project lead has asked us why. It doesn't help that the DBAs have opted to hit a myriad of individual databases instead of using a single DB server with replicated /consolidated data. So the stored procs themselves are quite sluggish. But beyond the slow procs, I'm just not totally certain that there won't be some noticeable speed difference with SL over VB6 even if the data pulls aren't an issue. Hence my question about WPF vs SL, since we could at least configure WPF as 2-tier, if needed.
BTW - we just purchased the Telerik control suite for both SL & WPF. Hopefully that will prove a little better than the DevExpress troubles you noted.
Regarding performance (our simple tests) Telerik was nearly as or equally fast as Microsoft WPF. So, I think this is a good choice.
We wrote a log entry after every DataPortal invocation including the time needed. This helped a lot to identifiy expensive and unnecessary server calls.
I also did measure the size of an avarage CSLA object (a node in a graph). In our app the avarage is around 2kB-8kB in memory, about same size using SL MobileFormatter, and 0.1x size using BinaryFormatter (TCP/IP). I have been a bit suprised how much CSLA needs, but using a debugger it's all reasonable.
Ah, another thing we looked at it: 2-tier vs. 3-tier (times are very difficult to reproduce, because of the OS and asynchronous loading of different root objects/lists).
But it's at most 1.2. - 2.0 we could gain (we didn't use the don't serialize-in-local-portal-mode, so all data is serialized+deserialized in memory). I think we will improve something by not going through any DataPortal for children (at least to many-to-one).
My success factors from a CSLA perspective are: user story tailored object graphs, also using the unit-of-work idea. And caching of static, catalogue like data.
This is one of those almost impossible questions to answer 
If you move to a WPF UI regardless if its SL or desktop, you will need new hardware and a graphics card to ensure that the UI rendering is fast. I had the unpleasant experience of having to deploy onto PC's with no graphics cards with WPF using software rendering and it was painfully slow at times.
Remember that performance is often an illusion and there are many tricks to make users think it's fast. The new async model is going to help make your UI feel more responsive.
If you have to go WPF, I'd be looking at Silverlight - it's the closest model to the future Microsoft strategy.
We had to use software rendering already on an older WPF app and it didn't seem too bad for in our situation. Just wondering how much the extra hop costs when transferring the object graphs over the wire (using compression) vs being able to hit the database directly via 2-tier in WPF.
Very good point about perception of performance.
I must admit that the critical screens are in my opinion crazy: over 60 fields, drop downs or grids are on it. But new elements like expand/collapse regions could mislead requirement engineers and hide the amount well from our preview users.
The "scattered around the country" phrase is something that immediately leads me to think about 3-tier, at least for those users. The use of service protocols over a WAN is almost always better than the less reliable SQL Server raw communication.
It is also the case that WinRT is also a 3-tier only technology. It might not be on your planning horizon now, but it will be a factor within the lifetime of your app (assuming a typical 7-15 year app lifespan). Of course CSLA helps mitigate that 3-tier requirement, so that's always good :)
My general recommendation at this point is that either WPF or SL are fine choices. Neither of them is going to get any major dev effort inside Microsoft, because all Microsoft's energies are now focused on WinRT. In other words, they are now equivalent to Windows Forms, in that they are stagnant technologies. Or to use a more positive word, they are _stable_ technologies :)
If you use WPF, that's a fine choice. I just _strongly_ recommend building your app with some constraints:
If you do those simple things then your business layer and data layer will be positioned to support WinRT. Perhaps more important in the short-term, you'll also be able to use 3-tier deployments for those users that are remote, and 2-tier for those that are local.
One last thing is to recognize that your UI (the XAML and code-behind, perhaps the viewmodels) won't translate directly into WinRT. My view is always that presentation layers are expendable, and in this case we know the future, so we know the presentation is expendable. Plan accordingly.
Thanks for the additional advice. The main reason for considering WPF would be the option to go 2-tier for users on the LAN, if we felt it was needed. Just wondering how much of a difference that would make.
Good point about remote users on the WAN. We use the mobile formatter and we do code async.
I went through a similar process three years ago and unfortunately we ended up parking the new WPF/CSLA application in part due to not so good performance. This project was not a client/server forms-in-front-of-tables app but more of a raw processing app so your experience may be different. A couple of points:
Watch out for Telerik's/ComponentOne/Whoever's components. Do not assume that their performance matches the WPF native controls. Be careful with performance when customizing the native (or other) controls. Also, whenever possible, choose the simplest (as in less flashy) component. Take special attention to grids and charts. They can be very very slow (use paging). If you are using MVVM be on the lookout for unintended loads. That is, components and windows that are using CPU cycles even though they are not visible. If you find yourself in trouble performance-wise try dropping MVVM for that specific window and use good old events and direct command. Also, if performance is that important consider buying and using a profiler right from the start.
Finally, consider not doing the big bang approach. The business will be tempted to add new features on top of the migration since you will be offline for 15 months. Why not package parts of the old app as ActiveX controls and surface them in the new app? It will look terrible for a while but your turnaround will be a lot shorter.
I had not considered an ActiveX strategy before. Does that assume the various parts of the current VB6 app are written as user controls instead of just forms?
Yes, the VB6 application UI elements will have to be exposed as ActiveX controls. If the application is a single executable then I would convert it into one single ActiveX control to simplify things. If, on the other hand, the application is already broken down into ActiveX controls and ActiveX DLLs with a good separation of UI/Backend then you have more options. I would also investigate the various projects that exist out there to assist migration (here is a list http://msdn.microsoft.com/en-us/vstudio/ms788241).
The current plan for that project I mentioned before is to use the WPF container application as the base (the main window with the menus and toolbar) and mix the new screens that were created in WPF with the old panels that we don't have time to rebuild now. We are going to re-style the WPF components with the same look as the VB6 components (there are differences in colour here and there) because this is an off the shelf application but an internal app could get away with skipping this part. The hard part will be reconciling the new CSLA backend with the old ORM-ish one. We will probably run everything off the old one and have CSLA call into it for a while but there are some doubts there.
What killed this project was not the migration per se but the temptation to add new functionality during the migration which took 2 years. That coupled with disappointing performance of some WPF components. For example, we had to revert to Microsoft Winforms chart half way through the project because everything else was just too slow (and we tested pretty much everything that was out there).
Copyright (c) Marimer LLC