New Posts New Posts RSS Feed: Silverlight and WF
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Silverlight and WF
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
WildHog View Drop Down
Newbie
Newbie


Joined: 03-Aug-2007
Location: United States
Posts: 9 		Post Options Post Options   Quote WildHog Quote  Post ReplyReply Direct Link To This Post Topic: Silverlight and WF
    Posted: 19-May-2009 at 6:31pm
http://msdn.microsoft.com/en-us/library/dd557867.aspx
Michelle Bustamante, of Idesign.net, has written WF Guidance for using WF as an application controller for ASP.NET, WPF and Windows Forms.  At the end she suggests WF as an application controller would carry overhead, mitigated by WF .Net 4.0 optimizations, and would be most applicable to complex UI navigation such as LOB apps.  The argument for WF 1.0 was that it was overkill for UI navigation but with WF in .NET 4.0 it is, at least in concept, viable and possible preferrable in certain scanrios.  
 
Would this also work with Silverlight...I don't believe WF is part of the .Net 4.0 subset for Silverlight...might be nice if it was?  How might this strategy be utilized with DevForce's MVC implementation?  Any thoughts?
Back to Top
WardBell View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 31-Mar-2009
Location: Emeryville, CA,
Posts: 338 		Post Options Post Options   Quote WardBell Quote  Post ReplyReply Direct Link To This Post Posted: 22-May-2009 at 6:48pm
Yikes! We're getting a little ahead of ourselves I fear.
 
I am no WF expert. I'd trust what you hear from Michelle or Bryan Noyes; they're among my "go to" people on matters WF and WCF.
 
I have been fortunate to be in their vicinity recently as they opined on these subjects. Let me net out for you what I think I have heard from them: stay away from WF for most navigation scenarios.
 
In fact, unless your boss is roasting you over an open flame because he (crazy that he is) insists on WF right now, stay away from WF 1 ... period. Wait for "WF 2 - The Reboot".
 
I know Michelle wrote that sweet little article.  But read it closely. She's talking about how WF might be useful if UI navigation is complex and you've got a ton of pages to work through. You <<might>> consider it if, in her words, your app "presents a large number of screens, or involves wizard-driven UI". Is that you? If you've got four or five transition decisions and the rest is serial flow or jumps governed only by the whim of the user ... I'd say WF is overkill. IMHO, it is overkill for the simple scenario she demos in her article (that's not a slap at the article, btw).
 
Performance shouldn't be the first consideration, nor the second or third. You first want to match the complexity of your approach to the complexity of the problem. I'm betting, based on your question, that you haven't written any serious WF yourself. You want to take on the considerable intellectual burdens of learning and supporting WF only if you have a really compelling reason to do so ... or a lot of extra time on your hands. 
 
Let's take a look at her remarks on performance anyway:
When Workflow is used in the context of a long-running process, the overhead of loading the workflow instance for a page request is not an immediate concern. When Workflow is used synchronously to drive page navigation, this overhead is more noticeable. Web sites that have very complex UI navigation may find the trade off of performance is offset by the benefit of visualizing page flow in the Workflow Designer. With the release of .NET 4.0, optimizations to the Workflow Runtime will make this an even more viable option.
The phrase "more noticeable" is an understatement. Perf will be much better in .NET 4.0 ... but that's not to say it will be good enough for smart client or RIA screen navigations. No one knows for sure. Do you want to be the first?
 
I don't believe that WorkFlow assemblies have been ported to Silverlight and I don't know if they will be for .NET 4.0. Everything I've read about Silverlight and WF has involved people invoking WF back on the server; that's not going to be a smart way to control how your user navigates within the Silverlight client.
 
I'm having a hard time understanding why you'd want to push WF down to the Silverlight client ... even it were possible. Probably a failure of imagination on my part. I think of WF as most appropriate for long running operations (more than a few seconds) ... and screen navigation does not qualify. If you've got really twisted decision logic for how to navigate your client application I'd be worrying more about whether the UI is too complex and worrying less about how to implement it.
 
And ... ah ... DevForce doesn't have an MVC implementation. MVC is a separated presentation pattern and we take no particular stance on which of the many such patterns ... and pattern dialects ... you choose.
 
We have demonstrated how DevForce collaborates well with a few of these patterns, MVP and MVVM (aka, PresentationModel) in particular; MVC has not been one of the patterns we've discussed ... not as I recall.
 
I happen to think it will work great with ASP MVC. We have a client who told me DevForce fit beautifully into his MVC solution. If you're going there, I'd certainly like to know about your journey. However, I find myself more intrigued by Silverlight these days ... and the favored pattern there (for excellent reasons) is MVVM.
 
Sorry for rambling. I hope this helps somehow,   -- Ward
Back to Top
WildHog View Drop Down
Newbie
Newbie


Joined: 03-Aug-2007
Location: United States
Posts: 9 		Post Options Post Options   Quote WildHog Quote  Post ReplyReply Direct Link To This Post Posted: 22-May-2009 at 10:12pm
Ward
 
I am the "crazy boss" and a chronic lurker of IdeaBlade.  I had scrapped a project a good while ago, mercifully killed after a consultation with Juval Lowy, and recently bumped into someone who for one reason or another re-kindled my interest, resulting in a spree of internet searches and book buys.  I should have put MVC in quotes, as I conceive MVC as the prototype of a general class of UI layer patterns including MVP and MVVM.  It wasn't but a few years ago that most programmers had little clue of UI patterns as evidenced by Fowler's 2006 article http://www.martinfowler.com/eaaDev/uiArchs.html  and personal experience.  My guess is that most programmers now know the acronyms, but still do not fully comprehend how to easily and consistently implement them.
 
And yes I was thinking ahead to WF 2.0, thinking WF 2.0 might be more responsive to act as a UI application controller and perhaps easier to program for complex UI's.  My failed WinForms project involved multiple roles and screens, but probable not to the level of complexity of applications you might feel are complex.  However, the programmers I dealt with, I believe according to Juval, had not, amongst other transgressions, separated the UI from the Business layer in a rational manner if at all.  Separation of the UI and BAL combined with Role based security concerns, navigation and UI change requests by a DFB (Dumb F Boss or Btard) seems to be a few too many balls to juggle for many folks.  So to me, the idea of WF 2.0 with the rules engine, might be a way to force separation combined with "easy" program model (after all WF looks like Lego building blocks to me:) ) and security injection.   What I gather from your response that even if WF 2.0 may be responsive enough to control flow, it would be overly complex or burdensome to implement unless 1. UI involves wizard type flow 2. complex state flow, thus obviating my reasoning for most scenarios.  In other words there are better ways to skin the app.
 
The reason I thought SilverLight may benefit from WF derives from my thoughts above.  If some WinForms, WPF and ASP.NET LOB apps may benefit from WF in the UI, why not let SilverLight have the same option for LOB apps?  Perhaps, a slimmed down version of WF to act as a UI controller which is easy and light weight for most programmers to wire up.  I may be wrong, but I think a lot of programmers appreciate the reasoning of gurus as to the benefits of MVC, MVP or MVVM, but do  not apply the patterns well or retreat to their safety zone in the heat of battle.  It seems the UI is often relegated to the junior most member, who is less likely to follow the pattern and more likely to take short cuts.  The core objectives of the UI is usability and maintainability, which requires multiple iterations improving flow and accommodating change requests, so anything that keeps focus on UI usability and maintainability while "mindlessly" enforcing a chosen UI pattern would be a big plus.  Most demos seem to show easy examples of databinding to a control, but do not demonstrate ease of navigation, ? validation, and security or other cross cuts....probable because it can't be easier than it is. Anyway, it looks like WF is not the SilverLight bullet for UI patterns. 
 
Your response will be very helpful to other programmers who may point to this post to disabuse their DFB of considering WF as a UI navigation/application controller unless there are very good reasons to use it.  I am real interested in seeing your Prism/Unity  demo.  I do know if I ever restart my project that it will be done with DevForce....I have read enough and feel EF is the future and IdeaBlade is several steps ahead....at least until Microsoft buys IdeaBlade.
 
I have a several other DFB questions that might be similarly useful to those less inclined than me to look stupid and need cover from their DFB who might be rooting around like a wildhog finding "cool" things that have an interesting odor but to those in the know it is the smell of perfumed crap.
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down