Will silverlight justify? - silverlight

I'm working on projects that processing a large amount of data, a lot of accouting operations and data reporting, that are shown in grids and pivots.
Currently I use devexpress web controls and everything works fine.
and my question is, will it be Justified if I move to silverlight, can this technology be used for this kind of solutions?

When you write
processing a large amount of data
I assume you mean client side processing, correct? In that case you would see an great boost in processing speed over javascript. You can see an example of that here: Silverlight C# vs Javascript.
That should make your application much more responsive, and with silverlight you could also easily use multithreading to push process heavy operation to the background.
If you're talking about server side processing, then it properly wouldn't be justified to make the move if you already got a working application. Unless you are planning on adding more "flashy" features in Silverlight.
With that being said I'm a big fan of Silverlight, and for a new application I would go with Silverlight. I use it all the time for big B2B web-based applications. Being able to code the frontend in C# over javascript just makes your life a little more enjoyable.

Related

Creating a Business Type Application Using Silverlight 3 - Is it Appropriate?

I'm considering using Silverlight for a business type application which will contain probably a dozen or so screens. The screens will contain data entry forms with edit fields, grids, lookups, calendars, etc. Typical business application type screens. I want this to run in the browser but don't want to mess with HTML, JavaScript, CSS etc. Is Silverlight 3 appropriate for this type of application? Can someone build professional level business type apps with Silverlight 3?
#Randy Minder,
Glad to hear that you want to use silverlight 3 for line of business application.
I used to develop line of business applications in ASP.NET combined with javascript/AJAX. I am currently developing my first silverlight 3 line of business application and found silverlight is better in few departments. The following are the Pro/Cons observed by me PERSONALLY.
Pros
Layout/Styling(CSS)
XAML + silverlight 3 styling is very flexible and less cluttered when compared to CSS. I am not a designer and I hate having to deal with CSS. But in the case of silverlight, I really enjoyed creating the mockup,layout & styling. The end result is awesome. This is the first application that I developed has decent & consistent look & feel. I hope you will also find silverlight xaml to be easier to deal with.
Rich Interaction & Language support
I used to use Ajax, javascript for creating rich interaction experiences like populating some data dynamically when user interacts with UI. Writing some complex UI logic in Javascript is daunting. Though there are some nice javascript libraries like Jquery, I think writing UI complex logic in C#/VB.NET/F# is much easier than to write it in javascript. Dealing with rich interactive controls in silverlight is much easier than with javascript/ ajax controls. Writing server communication code with WCF or WCF RIA service is far easier than with ajax calls.
Browser compatibility
Each browser is different from another in one or the other way, like some browser supports something and others dont. Having to deal with browser differences in javascript is also a pain. Silverlight being a plugin doesn't have to deal with browser differences. No problems dealing with layout engine differences too.
Animations/multimedia
Ofcourse with line of business applications we will not use toooo much of animations/multimedia. However we can use small animations like menu popup, sliding controls, fading transitions for when data changes etc. These are very easy to implement in silverlight than with asp.net/javascript
Validation
Validation support in silverlight is awesome you can write more validation logic in less time.
Popup messages
Popup messages are very clumsy to deal in ASP.NET and sometimes I need to store some information in hidden fields to feed text for popup messages. Hidden fields are used as javascript & ASP.NET interaction components which are difficult to maintain and end up with more code.
Good separation of presentation & model
Though you can separate these layers in ASP.NET also, silverlight enforces this by design which is good. In my team there are few developers who dont want to put effort on separation of the layers. Unfortunately they are the seniors in age and decision makers. I always hate to deal with their spaghetti code. Not to say that I am a better developer than them, I always put some effort to separate the concerns and try to learn how to manage my code. ASP.NET webforms doesnt enforce separation of presentation & model by design. Where as silverlight enforces this by design and my life became easier.
Cons
Clipboard
Users are very much used to copy the content available on ASP.NET/HTML page. Most of the silverlight 3 controls doesnt support clipboard out of the box. The only control I know that supports out of the box is textbox.
Database Communication
Database communication in ASP.NET is easier & direct communication is possible. However silverlight being client side technology it doesnt have direct access to database and a necessity of creating an additional tier is mandatory. Though WCF RIA services make the development of this additional tier easier, still WCF RIA services is in beta as of now. Though I am mentioning it as disadvantage, I did not really feel it is as REAL disadvantage because creating a WCF service is not that difficult.
Client side resource usage
Though cost of hardware reduced alot,client side hardware resources are not unlimited when compared to server side. At my work place, though PC provided have decent configuration, most of the users open lot of applications simultaneously which is required to accomplish their day to day tasks. Silverlight uses client side CPU/memory. Some of my users are complaining that the application I developed is using more CPU/memory than the asp.net equivalent. So if your users have slower PCs, consider ASP.NET or design your silverlight application more carefully.
One may say installing silverlight plugin as disadvantage, I did not face the problem because my application is a intranet application and all users installed silverlight with a single email request.
These are MY experiences with silverlight 3. The only major issue I faced was clipboard support in silverlight, I hope MSFT will address this soon.
All in all, silverlight ROCKS!!! Silverlight 3 is ready for enterprise and if you can wait for few more months Silverlight 4 will be released which has even better support for line of business applications. I dont want to develop ASP.NET applications anymore, that doesnt mean that I will quit using ASP.NET, I will use it only when necessary. I fell in love with silverlight and for a good reason. Designing part of the website is the one I used to hate most but with silverlight designing became one of my favorites.
I hope that silverlight 3 will help you in your decision making.
Absolutely. Take a look at this post about the Vancouver Olympics:
http://csharperimage.jeremylikness.com/2010/02/vancouver-olympics-howd-we-do-that.html
That's just one example of a business application in the "real world" being used to drive a massively complex operation. I posted that just to draw attention to the "business" side of Silverlight, but be sure to click the link to the original post to see the other partners and contributions to the project.
I've been building enterprise/business applications with Silverlight for over a year now. So the answer is an emphatic "Yes, you can" and "Yes, it's been done" and "Yes, it's been done on a large scale with large companies, and very successfully."
I agree #Jeremy. Make sure to use RIA Services with Silverlight , You will get a very manageable/maintainable application. Even one more benefit is that you can make the SL app Out of browser too.

Silverlight 3 automation for user training rather than unit testing?

We are developing a Silverlight LOB app. It would be great for users to be able to click a help button on the top of a page and have the app walk them through the functions of the page as though the movements and key strokes were pre-recorded.
I've not really familiar with automation on any GUI framework but googling around it seems most of it is geared towards testing. In my case, i'd want the mouse to move around the screen naturally, so a recording makes more sense. I'm pretty sure I could simulate such a recording with a very detailed timeline but this wouldnt be practical to code.
Is it possible to record an interaction like this and then have it play back purely on an SL client? I dont mind if I have to use an external tool to make the tests, but the training sessions need to run totally in Silverlight.
Its going to way way easier to create a training video using the variety of tools specifically designed for this sort of thing. Results of such tools you have probably already seen when watching demo vids for developing silverlight from site such as Channel9 and MSDN learning.
You could then simply use Silverlight's media elements to run such a video as part of your apps help system.
Creating actual automations that can be watched by a human will be much harder. Bear in that a huge advantage of video is that it can be paused and re-wound which is vital for your objective to actually be achieved well. This would be some thing like monumentally difficult to impossible to do using the automation approach.

Picking up Silverlight

I absolutely have no idea about Silverlight except that it is a Microsoft technology.
Having nearly completed a Computer Science degree, having programmed in C# for a few years in a work environment - have a good knowledge of Java and OO techniques - how hard is the road of average Silverlight programming? I've been offered some work DAMN IT!
I've mucked around with PHP, HTML and nearly no CSS..
Would I need a strong web programming background in order to pick it up?
I like Ben's answer, and he's right that a huge bonus of learning Silverlight is that you don't have to worry about the stateless model. However, there are a few parts of Silverlight that are less easy to learn:
Styling & control templates - These concepts look like CSS at first but there's a good bit more that you can do with them such as completely overriding the visual aspects of the control. Also, modifying the styles of existing controls is one thing and learning how to create your own control that can be easily styled is quite another.
Database connectivity - If you're anything like me the first thing you'll want to do after you write a "hello world" test is hook up to a Db and pull down some data. Since Silverlight can't directly connect to a Db you'll have to learn one of 3 techniques to move data between the browser and server: 1. WCF + your custom service methods + LINQ to SQL or LINQ to EF or whatever data access you choose. 2. ADO.NET Data Services (great way to start out) 3. .NET RIA Services (once you've realized that you need your data access technology to play nice with data binding and honor biz rules).
Security - You need to learn another part of the MS technology stack to get this working properly, ASP.NET Application Services. It should take more than a few hours to hook things up but it is another technology to learn.
Browser navigation, search engine friendliness & deep linking - Things you take for granted writing a traditional web app will take a bit more work in SL. You can use .NET RIA Services to handle browser navigation & deep linking, others have written about making your site friendly to search engines (and I don't know how ;).
What I'm trying to highlight here is that while learning the basics of Silverlight is easy, you'll probably run into other parts of the MS technology stack that you'll need to learn to get your work done. The beautiful thing here is that all of the technologies come from 1 vendor with a single focus and they work really well together. I shudder when I think about all the different technologies you'd need to pull off my current SL app in the open source domain.
Pick up the book "Silverlight Unleashed" and go to http://silverlight.net/GetStarted to start learning. Scott Gu's 8 part blog posting (#3 on that Getting Started web page) was one of the first things I read about Silverlight and is hugely helpful.
Unless your Silverlight app has to interact with a traditional web page, you don't need to know anything about traditional web UI technologies.
If you've done any desktop UI development you'll find Silverlight much easier to pick up than any web UI paradigm. Compared to the unholy mess that is css + html + javascript combined with ever-changing browsers and fourteen other hundred-author web "standards", Silverlight is a walk in the park.

WebForms / MVC to a Windows Forms programmer

First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.

What are the topics to ramp-up on when starting Silverlight\Web development?

I've been asked to do some work on an existing Silverlight project, mainly extending it a bit and doing bug fixes as needed. But there are a couple of ASP.Net pages too and a WCF service to deal with too. My background is desktop development with .Net so I think this is a good opportunity to start getting more involved in Web development.
So I'm trying to figure out what background knowledge I need for a project like this. Clearly I need to get familiar with Silverlight, but I'm not sure what other Web technologies, etc I need to ramp up on for this project. Obviously I would like to know as much as possible but in reality with limited time and resources I really need to focus on what I important in the near term for this project. Then expand my knowledge as things arise.
The things I'm thinking that are important in the immediate future are:
The basics of Web Development (I'm thinking this might be the most important\fundamental area to build a good foundation)
But what are consided the basics?
What is technology\language independent?
What is important for Silverlight?
The basics of ASP.Net (since there is some ASP.Net code)
What are the basics? ASP.net seems so huge, I have a 1000+ pg book here which seems daunting.
If you focus on Silverlight is knowing ASP.Net important, or is ASP.Net something I will continually run into?
How does ASP.Net MVC fit into the overall development picture and especially as related to Silverlight?
The basics of WCF
As compared what?
Any suggestions\comments on the list above?
What other topics\technologies will I run into if I continue doing Web development?
Note: Beyond this project I would focus on the Microsoft stack.
Generally speaking the amount of knowledge of ASP.Net you need to do Silverlight development is very very low.
Silverlight applications are hosted in a browser, usually via the <object> tag. This can sit on an asp.net page or a html page. The Silverlight template creates that for you, so you can forget its there and just get on with the Silverlight app.
Of course if you are integrating into an ASP.net environment (for example, islands of Silverlight sprinkled through an ASP.net site) then thats another thing. There are ways to get Silverlight talking to the HTML dom via the HTML Bridge but its not necessary. Really depends on what you are developing and integrating with. (new site vs existing)
I avoided ASP.net for as much as i could as the richness compared to desktop (WPF) just wasnt there. Silverlight changed all that. Its a Rich world on the web now!
Best place to start learning Silverlight is www.silverlight.net on the getting started part of the site. great Quickstarts and tutorials there.
Good luck
Only cursory knowledge of traditional web technologies (css, html, js, etc.) are necessary for silverlight development. As a consequence, you also don't need to understand the many cross-browser dependencies as well.
Here is my list of things that you must get a really good understanding of to be proficient at Silverlight development:
Understanding WCF (the Silverlight-supported parts) is essential. It can be a configration nightmare, but once working it is pretty stable/ reliable
You need to understand serialization used by WCF and how to debug the mysterious 404 errors. Get good at Fiddler and/or Firebug.
You must understand multi-threaded applications and how do debug them. Silverlight makes extensive use of threading to not block the UI thread. This creates numerous opportunities for race conditions that create what appear to be "magical" results. That said, it is incredibly powerful and IMHO one of the dominant reasons to use Silverlight.
What you learn about serialization and WCF will ultimately help you cache some data in IsolatedStorage. Learn about IsoStorage, it will reduce our bandwidth requirements and cost and improve your user experience
Learn about Linq - again this is one of the most powerful features of Silverlight. Combined with a smart client-side caching strategy you can offload lots of processing to the client.
Figure out how you going to support printing. SL3 does not at all and you will need a server side component. SL4 beta does, but it is not go live
Understand the Silverlight Roadmap as much as possible and plan out your roadmap to match/ sync with it as best as possible. I first built a SL2 app and I spent a lot of time building things by hand that were ultimately released in SL3. As it is getting more mature, there is less of this.
Download the Silverlight Toolkit and use it. But more importantly examine the source code, the structures, its build process. There is not better real world place to look for inspiration & best practices.
Good luck.

Resources