This is just some random notes on ASP.NET vs. Silverlight business applications.
One of our major problems is getting reusability of components.The n-tier architecture is great at separating concerns – problem is that works against a modular application where we want to add functionality independently and discretely.
To explain: we have our core application (in this case, called Anvil). It’s got a database and some business logic and a front end in ASP.NET. So far so good – except we need to support “pluggable” products into this application where the functionality is outside of the existing application:
|Element||Main application||Product X|
|Data layer||SQL server table||Reuses this (XML data for additional attributes)|
|Business Layer||IProduct interface||Product implementation and business logic|
|Presentation||ASP.NET website and controls||?|
There isn’t an issue in creating a product DLL which can link to the parent application using an Interface (in this case let’s say IProduct).
The problem arises when we hit the presentation layer (in this case it’s currently ASP.NET). We can’t embed ASCX controls in a DLL* so this means we have to put part of the Product X functionality in the website. That immediately compromises the logical design.
We have to put the controls into the website in the main application. This means I might as well forget modularity and move the code for ProductX into the main application so it’s monolithic again.
If this were a Windows Forms application this would be easy: I’d create controls in the ProductX.DLL and the ‘ProductX’ instance would know how to display itself. I could combine the business logic (ProductX class and methods) along with a pre-packaged set of UIs to handle them.
Unfortunately this is a distributed application delivered via the web so Windows Forms is not an option! It was for this reason I’d been looking at two alternatives: MVC (specifically, Razor) and Silverlight.
MVC can improve matters quite a lot by making it possible to embed Razor controls in the DLL for product X. This does mean I can get away from putting the logic into the existing web.
However when experimenting with MVC routing seems rather constrained, and getting MVC to compile and use Razor views seemed rather like a hack than a natural, supported approach.
Yes there are lots of cool controls and libraries like jQuery etc. to help, but the fundamental issue remains: the medium (html/web) isn’t really designed for this. HTML5 is a step in the right direction, but but this gets us to about the level of functionality that Visual Basic had in the 1990s, and I’d have to require clients to upgrade browsers to run my application. So it’s not a solution that works right now.
The other option I’d been looking at for so long was using Silverlight. The downside to Silverlight is that I’d be excluding a small segment of the audience – mainly iPads and Linux users. As I this is a vanishingly small percentage of my customer base it was something I could overlook.
The key advantage of Silverlight is the richness of the client. So many times in ASP.NET (or any other Html-based application) you’re spending a lot of time fighting the nature of the medium. Date control? Input validation? Cross-site scripting attack? Lack of state?
Html is great at presenting data, but as an application platform it really, really sucks.
Silverlight has the added bonus of the overlap to WP7 phones so there could be a lot of reusability in WP7 phone apps too – although not an immediate benefit to us.
So now we have to put together some proof-of-concept mock-ups and start learning what we need to know!
Update April 2012: We’ve ceased new development on Silverlight given Microsoft’s lack of clarity on Silverlight’s future.
That uncertainty, plus the increasing importance of mobile and tablets means we now have to include these in our plans. That rules out Silverlight, and leaves just HTML.
However, I’ve got upto speed on MVC now and that, plus excellent libraries like KnockoutJS mean we can have the responsive UI we want without going down the RIA path.
* yes it is possible to embed ASCX files in DLLs but you still have to copy the source into the web application – hardly an elegant, modular solution – it’s just a hack with messy manual workarounds