Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Here's what I know and opinion,
Silverlight is more light a runtime environment for you application, which can be hosted in a sandbox or in the browser, or comming soon...a sandbox outside the browser.
PROs: WPF is a markup language for defining forms that provides more flexibility than WinForms. For example people love to show silly stuff like buttons embedded in pictures embedded in buttons in demos. But where WPF will have the biggest effect is likely to be in making you application look spectacular, it can give it the nicest dress at the ball, regardless of whether it works, or even does its job well. Eventually, if you have software in the commercial market you will need to put that better dress on your product or it will begin to look dated.
CONs: However, until third parties (artists and designers) start delivering cool widgets and skins for WPF, its not going to be that attractive to the average business application developer in regards to improving the appearance of their applications, as they typically aren't artist and designers, and don't have time to learn how to use the new design tools, and need to turn out new applications quickly all the time. WPF currently lacks a lot of the drag-and-drop abilities provided by WinFrom controls.
Counter point: Some gurus (Rocky Lhotka and Billy Hollis, etc) say that WPF even in buiness application development can make you more productive, but you need to invest a lot time leaning how it works and how it should be used.
Where I am...holding back as long as I can to work with WinForms, as I like its drag-and-drop and I've got a lot invested in it already, and whiz-bang is not needed for the busines form-like applications I deliver. Also, I use offshore developers, who I haven't the extra time to guide them through how to manage the complexities of this new UI. Moreover, the WPF code ends-up in your main form, not the code behind file, and it's hard enough to get everyone on the team to write well formatted and standardized code that is easy for eveyone to maintain, without having the IDE sticking markup text everywhere in that file.
But again, the gurs say WPF is the way forward, and while I hope business applications will revolt against WPF and encourage Microsoft to develop WinForms for years to come, I realize I may actually have to move to it sooner rather than later, (probably middle to late next year). In the meattime, I'm hoping Rocky will follow through with his promised eBook for later this year on using his current version of CSLA with WinForms.so that I can live without WPF for another 12 to 18 months.
DesNolan:I hope business applications will revolt against WPF and encourage Microsoft to develop WinForms for years to come, I realize I may actually have to move to it sooner rather than later, (probably middle to late next year).
I think this is a typical Microsoft thing: No clear strategy, two separated development teams (with great and fantastic developers) trying to beat each other...
Or if you put it in another way: Simply bad management!
For what it is worth, here's my take.
The long-term goal is for Silverlight to be a true subset of WPF (which means WPF would be a true superset of Silverlight). That is not the case now, and won't be the case in .NET 4.0 or Silverlight 3.0.
So now, and into the foreseeable future these two technologies have large regions of overlapping functionality, but each have unique elements that are unavailable in the other technology. Clearly Silverlight is smaller and simpler, and WPF is larger and more complex.
To mitigate some of this today, you should get the SilverlightToolkit and WPFToolkit from CodePlex. And .NET 4.0 and SL 3.0 will help, but won't completely solve the mismatch.
Given all that, my default start position is, and will be, Silverlight. I'll only fall back to WPF if there's some specific requirement (business or technical) that prevents Silverlight from meeting my needs.
This is strategic. If Microsoft does achieve the true superset/subset goal, then you can't go wrong by targeting SL, because that code is then guaranteed to run in WPF. But the reverse isn't true, so starting with WPF pretty much prevents future use of SL.
But it is also tactical. SL deploys in a simpler manner than WPF. ClickOnce is good, but it still isn't as smooth as the browser-based SL model.
And SL is smaller and simpler. I keep working in SL, and rarely do I miss anything from full .NET. Now maybe this is because I'm doing CSLA coding, and my server is .NET and my objects are mobile - but I find that SL has everything I've been needing to build my UI and business layers, and .NET provides what I need to build the data access layer.
If I needed to do Office integration or something more extensive on the client I'd obviously have to switch to WPF, but most of the apps I've been working on haven't had those requirements.
I'm 55 and pouring what's left of my so-called life into a technology that has a shorter lifecycle than me is troubling at best. I hate do-overs (since I'm not getting one).
All kidding aside, while I was leaning to WPF, Silverlight looks like the obvious choice for me because it gives me the best flexibility for an uncertain future.
OTOH, it simply doesn't look like it's ready for prime time as hand coding all kinds of code in a designer-less environment seems even less productive. Reminds me of HTML and notepad.exe.
Since Rocky has never steered me wrong, I'll guess I'll try SL. But it scares the hell out of me.
As for distinct design teams, does anyone remember the Lisa and the Mac? I don't suppose the Lisa guys were bitter or anything.
I did see (once in the 80's) a coding team of six people writing COBOL code using Edlin on PC-DOS 1.x on the 25th floor of a highrise in Manhattan (insurance industry, of course).
I told them that IBM had a full screen text editor and I thought that might help them and they looked at me like I had two heads. The ROI on those guys in that real estate must have been *pretty* small. :)