Building Line of Business Applications with Silverlight 3 – Pros and Cons

imageI’ve been hearing a lot of people talk about how Silverlight 3 can or can’t do various things lately throughout the blogosphere and Twitter.  The sad part is that some of the people giving their two cents about what Silverlight can’t do haven’t built a “real world” application so I’m not sure how their opinion carries any weight (I know because I’ve asked a few of them). Their list of cons are typically based on what they heard on Twitter or various rumors floating around.  As with any technology there are pros and cons and Silverlight is no exception.  The goal of this post is to talk through some of the pros and cons I’ve personally encountered while building a “real world”, enterprise-scale timesheet and job management application for a large electrical contracting company.  I’ll point out what has worked really well and what hasn’t so that people looking to move applications to Silverlight 3 can get an honest assessment on what can be done and what can’t be done.

The application my company is building has a lot of different screens (30+), integrates with the backend database using WCF, uses reporting services for reports and leverages many of the key features Silverlight 3 has to offer.  The existing application used by the client was written using Access Forms and is being ported to Silverlight 3 along with a bunch of new functionality.

Let’s start by going through what I personally feel are the pros and cons that Silverlight brings to the table for Line of Business (LOB) applications.

Silverlight 3 Pros

Here are some of the pros I’ve found as I’ve worked through the application:

  1. Excellent data binding support – my favorite feature.  This changes how you look at building applications and allows you to write data-centric code instead of control-centric code as with normal Web applications.  There’s a lot I could cover here but I wrote up a post awhile back that gives additional details about what I like.  Read it here.
  2. Server code and client code can written in the same language.  Business and validation rules can be shared between the client and server code base which definitely makes applications more maintainable into the future.
  3. A rich set of controls – I really like the controls available with the Silverlight SDK as well as those in the Silverlight toolkit.  There are a few (mentioned below) that can test your patience when you’re building a more involved application and not a simple demo.
  4. Support for just about any type of animation or effect you want.  Don’t need that in a LOB app?  I beg to differ.  You can get quite creative with how data is displayed with Silverlight and not be limited to simple slide, sizing or opacity animations.  I’ll show an example of what I call the “card flow” interface later in this post and show how it allows managers to get to timecards faster and easier than before.
  5. Excellent designer support through Expression Blend 3 – Visual Studio 2008 is great for coding but doesn’t provide any design-time features for Silverlight 3.  Not a big deal….you can use Expression Blend 3 which provides a great interface for designing your applications.  The new SketchFlow application can even be used to prototype applications upfront and get customer feedback more quickly and easily than in the past.
  6. Easy to integrate distributed data using WCF, ASMX, REST, ADO.NET Data Services, .NET RIA Services, etc.  The application that I’m working on leverages WCF as well as some dynamic code on the client-side to make calls to the service.  It works great and FaultExceptions can even be handled now with Silverlight 3.
  7. Desktop-style application with a web deployment model – Get the responsiveness of a desktop application that can be deployed right through the browser and even run on Macs.
  8. Support for styling of controls.  Silverlight 3 now allows styles to be changed on the fly and styles to be based on other styles.  If you don’t like how a control currently looks you can completely change it by using styles and control templates. 
  9. Out of browser support – This was a key reason why my client choose Silverlight 3.  They have a lot of remote workers that don’t always have access to the Internet and needed to be able to enter timesheets even when disconnected and then sync them later once a given employee has connectivity.
  10. Support for behaviorsBehaviors are very, very useful in Silverlight applications.  I needed to add mouse wheel scroll capabilities to a ScrollViewer control to simplify scrolling in a screen and did it within minutes by using a behavior (thanks to Andrea Boschin who created the behavior).
  11. Manipulate pixels using WriteableBitmap.  This can be used to create some very cool effects (some which may not be applicable to LOB applications…but they’re still cool).  I’m using it mainly to fill the printing hole mentioned below.
  12. Support for storing local data through isolated storage – By using isolated storage you can cache data, store data when no network connectivity is available plus more.
  13. Support for navigation – Silverlight 3 has a new navigation application template in Visual Studio that makes creating an application with multiple pages quite easy.  Each “page” can be linked to directly through deep linking and has built-in support for history.  If the client hits the back or forward button in the browser they’re taken to the appropriate Silverlight application page.  The navigation framework allows code to be placed into separate pages (or user controls) and then loaded as a particular link or menu item is clicked.  It’s a great feature that can really reduce the amount of code you have to write especially compared to Silverlight 2.

Silverlight 3 Cons

So everything’s all peachy right? Both the client and I are very happy with how things are going with the application but there have been some challenges along the way.  At the beginning of this post I said I’d mention the cons as well and I’m going to be brutally honest here with some of the areas where Silverlight 3 is missing the mark when it comes to Line of Business applications.

  1. No printing support.  Microsoft is working hard on this for future versions of Silverlight but if you can’t wait until then it’s definitely something to be aware of.  We knew about this going into the project so it was supposed to be a non issue since we could pop-up HTML overlays or open new browser windows that could be printed.  But, for one particular screen the lack of printing support is proving to be a challenge since it turns out the end user always prints the screen as they’re doing payroll work and the screen is quite complex.  I’ve come up with a work around using Silverlight 3’s WriteableBitmap but am currently sending bytes up to the server, converting them into a JPEG and then displaying the image in the browser.  Definitely a hack solution.  We’re now looking at generating dynamic Excel files on the fly at the client with a snapshot image of the Silverlight data since Excel will print the image properly and the browser doesn’t (still researching this option). If that doesn’t work we’ll just use reporting services to generate the same screen…not my preference though.
  2. Binding data to controls such as a ComboBox that is nested in other controls is harder than it should be.  I use a lot of ComboBox controls that are nested in DataGrid or ListBox rows in the application.  While I have it working fine now (after beating my head against the monitor a few times), the ComboBox control itself really needs a SelectedValue and ValueMember property for some situations and a way to more easily bind its ItemsSource to collections that may be defined outside of the current DataContext. All of this can be done via code but if you want to handle the majority of it declaratively in XAML it can be challenging in some cases especially once you start breaking parts of a page into user controls.  I ended up enhancing some code Rocky Lhotka blogged about and created my own ComboBox control that simplifies things a lot.
  3. Lack of built-in support for commanding.  What’s “commanding”?  In a nutshell it’s the ability to call a method within an object directly from XAML as an event fires instead of going through a code-behind file.  For example, when a button is clicked the click event can call directly into a ViewModel object that acts on the event.  By using commanding you can make your applications more testable. Frameworks such as Prism (and many others that have popped up) support simple button commanding and provide a code framework that can be used to build other types of commands.  The application I’m working on handles just about every event in the book (click, mouseenter, mouseleave, rowloaded, lostfocus, gotfocus, plus others) though and writing custom code just to handle events got old (so we simplified things and handle the event in the code-behind which notifies the ViewModel via events).  If you want to handle events directly in the code-behind file this is a non-issue for you, but if you want to handle them in another class it can be more challenging than it should be.
  4. Learning curve – There is certainly a learning curve associated with building Silverlight applications especially if you’re coming from building standard Web applications.  However, I think that’s the case with any technology.  I had already built several demo applications with Silverlight, co-authored a book and several articles on it and still ran into a few challenges with architecture choices along the way (we’re following the MVVM pattern).  I think it boils down to experience though so I list this one simply so that people know they will spend some time learning.  If you’re one of those people who doesn’t like to learn new things then Silverlight probably isn’t for you.  If you enjoy learning new things then I think you’ll love Silverlight once you get the hang of it.
  5. No built-in support for displaying Reporting Services reports within Silverlight – This isn’t a huge issue in my opinion since a report can be brought up in a separate browser window or displayed using an HTML overlay.  However, if you need to display the report directly in Silverlight there isn’t any built-in way to do that in Silverlight 3.  3rd party vendors to the rescue though.  Perpetuum Software now has a product that can integrate reports directly into Silverlight.
  6. The client has to have the Silverlight plugin installed.  I personally don’t view this as much of a con for internal enterprise LOB applications since it’s fairly easy for a PC manager to push out Silverlight to client PCs in many environments.  If the application will be run externally then installation of the plugin on each client has to be considered though.
  7. Sharing service types between proxy objects needs to be enhanced - When the project was initially started I wanted to use ADO.NET Data Services for some things and WCF for others.  The problem is that if both types of services reference the same type (such as Customer) then both generated proxy objects will contain a copy of that type which ultimately bloats the XAP size and leads to having to reference types by namespace down in the code versus a using statement at the top.  Although proxies can share code libraries from other projects (that's an option in the proxy generation wizard), my Model entities use .NET language features not available in Silverlight class libraries so type sharing won't work there.  It's something to keep in mind as you decide how you'll get data into your application.

There are definitely more pros than I’ve listed and probably a few more cons although I honestly can’t think of many more that I’ve had to deal with.  The bottom line is that all of the pieces are there (aside from printing) to build powerful Line of Business applications that are built using existing .NET languages.  You can make the applications look however you’d like and not have to worry if they’ll look good across different browsers.  Here’s a picture of a payroll screen in the early stages of development:


Makeover


Here’s what the screen looks like after applying a few styles to the controls and adding support for things like inline editing of data:


image


Some of the more “fun” features in Silverlight 3 can also be put to good use in Line of Business applications.  I needed to create a way for warehouse managers to easily manage multiple time cards for employees.  I ended up going with what I call a “card flow” interface (similar to cover flow in iTunes) to display the time cards.  The end user can use the mouse wheel to quickly navigate through different cards.  The selected card will slide to the middle with a cool animation and the others are angled using perspective 3D.  Here’s what the “card flow” interface looks like (I need to give credit to Jose Fajardo for blogging about the concept):

image

 

To Wrap It Up

So is Silverlight 3 ready for prime time, enterprise level Line of Business applications?  Having worked with the framework nearly every day for the past 3 months in a “real world” scenario my short answer is a big “YES”!  I don’t say this because I’ve been drinking the Kool-Aid though.  Anyone who knows me understands that I use what I feel works best for a given application (unless the client wants something specific of course).  I truly enjoy working with the framework and think it can do a lot of powerful things.

Every company is unique though so the answer really depends on what features your application needs.  Our previous client’s application was built using ASP.NET MVC and jQuery and it did everything they wanted it to do (I really like ASP.NET MVC and jQuery by the way).  However, Silverlight provides a more consistent way to develop enterprise applications that doesn’t require learning JavaScript, additional libraries like jQuery, CSS, HTML and other Web technologies.  With Silverlight you can write code using your favorite .NET language on both the client and server, debug applications like any normal .NET application, bind data in flexible ways, retrieve data from remote services, animate objects as needed, round corners and work with gradients without ever creating a .gif, .jpg or .png and have a ton of controls right at your finger tips.  I’m a big fan.

Logo

For more information about onsite, online and video training, mentoring and consulting solutions for .NET, SharePoint or Silverlight please visit http://www.thewahlingroup.com.

comments powered by Disqus

27 Comments

  • Excellent post, before this i wasnt thinking about building apps in silverlight but definately this has motivated me, is there any best example or framework available of any LOB application developed in SL so that i dont need to start from scratch.

    Thanks

  • Thanks Imran...glad you found the post helpful. As far as a best practice Silverlight 3 LOB application I really can't say that I've seen one that demonstrates a good application while also using some of the MVVM best practices. Let me think on it though and ask around...if I come up with anything I'll post it.

  • We have a need for 1-2 Silverlight / .NET resources to work for one of our clients ( large Financial services company)in the Boston area.

    I am looking for some experienced .net/C-Sharp developers, specifically ones with Silverlight experience. I really need developers who have worked with Silverlight or are strong .Net programmers.

    Need the resources to actual coding experience within Silverlight? Expression Blend and Xaml coding are not enough. We need people who have experience implementing end-to-end functionality for user controls / creating custom controls / coding http requests from within SL, eventing etc within Silverlight. and need it to be Silverlight 2.0

    Thank You,

    Jack

  • Good stuff Dan. I'm starting work on an SL3 payroll app to replace an old FoxPro for DOS app. Decided to use .NET RIA Services. I'll be following your future posts on your experiences.

  • Great post Dan.  What hangs me up the most is this: "Easy to integrate distributed data using WCF, ASMX, REST, ADO.NET Data Services, .NET RIA Services, etc."  I waste too much time trying to figure out how to feed data into my app.  I did WCF with SL2 and it worked well.  RIA Services seems to be what everyone is talking about now, but it's not RTM'd yet.  What I'd like to see is another resource like John Papa's excellent SL2 book which explains the different ways to get data into a SL application and which method is better for which situation.  But I agree that SL3 works for a LOB app and once printing is added and combobox binding is addressed (come on!), SL3 will really be rockin'.

  • Thanks for posting Jack. Silverlight developers are definitely in demand these days and it's hard to find experienced devs given how new the technology is. Contact me through the blog though and I'll be happy to pass along any names of people looking for a position like that if they come up.

  • Thanks Roger. I definitely wish I could've used .NET RIA Services but it just wasn't far enough along when we started the project. It definitely looks like the way to go though (especially for easily sharing code between the client and server environment).

  • Scott: Totally feel the pain there as far as wasting time trying to figure out how to get data into an application. I experimented with a few other options (mainly ADO.NET Data Services) before settling on pure WCF. I really wanted to mix technologies and use ADO.NET Data Services for some things and WCF for the more advanced things. However, sharing types generated by the proxy objects became a huge issue so I decided to go with WCF to eliminate the problem. .NET RIA Services looks great and we'll definitely move to that in future applications but we had to go with an RTM product of course this time around.

  • Nice one here however here are some showstopping type negatives that we all often forget.

    Basically in one item I called this 'Lack of Production Environment Characteristics'

    This means to me it is much harder to get meaningful instrumentation out of these apps, production support in general actually, and we are in a very 'bespoke' world, which is good as we can make things amazing but bad as well.. it's mostly custom craft rather than component reuse.

    Ok ok. I know you COULD do more component reuse.. but ... then the app looks bad.

    For me (my opinion) I love the application that is utterly a mind-blower. You craft something amazing.

    Line of business apps are mostly.. boring as all hell.

    THIS needs to change before Silverlight gets compelling for that target market I think.

    How? I believe this will be allow about complex data visualizations and vastly richer media expectations from a user base.

    Time will tell!

    Damon Wilder Carr

  • Hey Dan,

    Great post. As most people figured out from V1, writing floating, shiny, Silverlight game apps was fun, but it was serious LOB apps that was really what was needed to get silverlight going. I think as it continues to mature it will only get eaiser. We are finally getting that rich "Windows App" on the web. The sceenshots look great.

    Daniel

  • Hi Dan,

    Great stuff (as usual)!
    Totally agree with the pros and cons.
    I have one additional con. One big issue for me when working on a LOB application was multilanguage support. Creating a language switch in the Silverlight application and using resx files was a real pain in the you-know-what.

    Thanks,

    Rob

  • I still think the business applications are a bit limited when you can't do even simple Rich Text like HTML(display and editing).

    We can do almost anything else, and the UI is just awesome, but in the real world, generally, TEXT is KING, and video comes in 4th behind graphics and audio(although this depends on the application).

  • Excellent post.

    I was wondering which technology you are using for offline/data sync. Can you please cast more information?

  • Kevin,

    Thanks for the comments. As far as offline/data sync that part's still in development since there is a lot of caching work being done (jobs, work codes, areas, etc. have to be cached to allow for timesheet data entry to work offline). We'll be using the isolated storage feature and more than likely writing custom code for the sync at this point. There are some frameworks coming out for this I hear but I haven't had a chance to look into that side of it more for syncing.

  • Thanks for the comments Damon. Most LOB apps are definitely boring. :-)

  • Thanks for the comments Daniel...definitely getting easier and easier as Silverlight continues to mature.

  • Rob,

    We're (fortunately) not having to deal with resx files. Good to hear about your experience with them though.

  • Fallon,

    Having built-in support for rich text editing would definitely be nice. Seems like I saw some 3rd party or open source controls that enabled that scenario. Haven't actually tried them though.

  • Hello Dan, this is a great article and a great application. I am sure you cannot the source code for this application. But is there a possibility that you can write an article that gives a high level view of the approaches you took to develop this application? Basically, I was wondering if you could provide some details about what controls you used the most and what tools/addins you used if any, to generate a form and then customize it. For example, XAML power toys by Karl Shifflett is a great way to get started with generating the XAML for a form and then paste it and then customize, so that we do not have to manuaaly write Grid.Row="0", Grid.Column="0" etc for each row and column. He has some good videos to get started creating the business form. I have been playing a little bit with the DataForm control, but I am not sure if you used it as it is currently in the Preview Qualit Band right now. So I am very interested in knowing what utilities you used while developing the application. Also, it would be helpful if you can show us some best practices you followed while developing the application, liek the MVVM model etc.
    For example, when we want to show a Combo Box in a sort of DataForm, and the data for the combo box comes from another table with a foreign key reference, are there any best practices to load the data for combo box in a certain way through WCF?
    Again, it is a great application you have developed and if you can share snippets of code to show some of the things that can help developers starting in Silverlight be more productive, we will really appreciate it.
    Thanks
    Jatin

  • Jatin,

    Thanks for taking the time to add your comments. Glad you found the post useful. I've been planning to put together an MVVM type video (that focuses on out of the box stuff you can do...no reliance on other MVVM frameworks out there) so if I get some time I'll try to do that along with an article. I'm swamped right now with the application mentioned in the article...have a deadline coming up fairly soon. :-)

  • excellent! Thanks a lot!

  • Very good write-up! I really like your comment on outputing data to Excel. Even if print support were included (which it needs badly), there are always a few VPs who want everything in Excel so they can "play with the numbers." Any hopes of publishing your solution to output to Excel?

  • A nice thought, I am evaluating silver light for one of my upcoming business project, the information in your post will help me a lot. Thanks.

  • I still don't get all of they hype with Silverlight. A developer can make something look just as bad in Silverlight as in any other technology. Look and feel, along with the ability to do animation, is a poor reason to select one technology over another (and let me count the number of business users who need things done quickly vs. watching something move when clicked - or who even care for that matter).

    As far as Silverlight vs. ASP.net MVC - this is a no brainer as far as I'm concerned. With asp.net MVC you get JQuery support (you like animation and controls - they have well over 1000 of them - and Microsoft contributes to the library - no plug-in reguired), convention over configuration, a HUGE developer base, and ultimately end up with quickly built, testable, full featured apps that are easier (meaning cheaper) to support, build, and enhance. Just try hiring a Silverlight dev vs. an asp.net dev and you'll see what I mean. (Truthfully, for anyone to ignore the bottom line in developing LOB apps IMHO is missing the big picture - as cash is king in the enterprise.)

    And if you think demand is high for Silverlight devs - just look on Dice vs. ASP.net. The results speak for themselves. (Search for Flash and Air if you like too and do the comparison.)

    Another bonus - nothing beats the scalability of asp.net mvc apps.

    I guess the big thing for Silverlight is that it's accessible to .net developers. Keep in mind - developers should not design. They make horrible designers. Sorry devs, but you should probably work on your business layer while a designer works on the front-end.

    Where does that leave us - if you employ designers, you can get good looking apps in any solution - and designers are fairly inexpensive.

    Let's not forget - Flash is very capable in the LOB arena. Using AIR you get a far more functional app, across many OS's, than you do with Silverlight (primarily due to .net security). The thing to remember for any of these technologies - they have been around forever and are really nothing new. You could do this stuff in a browser for many many years now (can anyone say Macromedia Director, Active X, Java Applets, Flash)?? And yet you don't see entire apps written this way (at least not many).

    Everyone comes back to doing pure web apps due to the reasons I mentioned. I would think Silverlight, just like Flash, will ultimately find it's home in video and multimedia apps - and will be used in an Islands of Richness approach for LOB apps - primarily for data visualization.

    For people who have concerns with Data Access - I don't understand this. There are a million solutions out there for .net developers and this is really a trivial thing with asp.net.

    Either way - this is just a technology that's trying to be the new hotness. It's nice enough - however been there, done that. It's going to come down to cost and speed - and most web dev's won't write entire apps in one technology vs. another - but will find a good blend between them all.

  • Concerned.Netter,

    Thanks for taking the time to leave such as detailed opinion but at least leave your real name. I'm not a big fan of anonymous comments when a point is trying to be made. Comes across as someone who likes to rant since there's no accountability.

    If you don't have any apps that need to look and feel like a desktop apps yet be deployed through the browser then stick with MVC and jQuery. I'm a big fan of both of those as well. Having worked on a Silverlight 3 application for over 3 months now I can tell you that data binding is way better in Silverlight...not even close compared to the hoops you jump through with ASP.NET. I don't have to worry about how it looks across browsers either (this is an internal app so everyone will have the plugin...a non issue) as well and I've listed several other points in the post. For our client the out of browser feature was the main factor.

    You've obviously made up your mind so go with it man. No need to try to convince those of us who have built and released "real world" apps in ASP.NET, ASP.NET MVC and Silverlight since we've experienced all 3 options and don't need to be convinced of anything. When it comes to jobs I'm comfortable taking on any of those types of projects so I'm not real worried about the Dice stats. :-)

  • I apologize if I offended you.  The sad part is that I don't even disagree with what you have to say since it's totally valid.  However, I definitely have a problem with anonymous stuff now days and let that show too much I think.  Again, my apologies there.  I have absolutely no problem with someone disagreeing with me (don't assume you know me unless you've actually met and talked with me...if you have then you're free to tell me I'm wrong :-)) but I like to know who I'm having a discussion with and think that's a fair thing to ask.  I'm not one of those people that latches on to something and can't stand hearing anything negative about it.  Again, if you knew me you'd know that's true.
    As far as the "tweet" there was nothing wrong with that at all.  How can it be "unprofessional" to poke fun at an anonymous comment?  I'll poke fun at anything including myself (just did with my latest tweet since I realized I was doing something wrong and being an idiot).
    Contact me through the blog...let's talk directly.  I have no problem with your comments (seriously...I don't) and am happy to discuss them more once I know who you are. It's up to you....

  • @Concerned.Netter - Am I missing something? What is our concern?

    Are you concerned that Silverlight might frighten the uninformed minds of cluless developers or small children?

    Maybe you're concerned about yourself, I just don't get the concern. Those that like SL will use it, those that don't ... won't.

    Gee, isn't that simple? After all, you started your post with the unadorned TRUTH, and I agree, YOU JUST DON'T GET IT.

    Now can we move on....

Comments have been disabled for this content.