A contemporary buzz word in software development circles is without a doubt ‘SaaS’ or Software as a Service. The dust that twirled by the introduction of ‘SOA’ (Service Oriented Architecture) has just settled down a bit and yet here comes another windstorm. What SaaS precisely entails is certainly not definite, and maybe never will before it’s outdated by yet another acronym, but I will leave that aside for a moment. A lot of people consider a pure SaaS as a software system that can be scaled enormously with high efficiency and low costs.
English
I have been playing around with LINQ the last couple of weeks. Really nice stuff to work with, it changes the way you work with sets of data and the process of transforming them into other sets of data. But I don’t want to focus on the utility of LINQ here, but on the underlying paradigm shift that we might encounter and that I have been thinking about lately: drawing the analogy between application tiers and a supply chain, and giving the power back to the interface tier.
Recently I decided to investigate more in real smart clients, partly because I am just fed up with all these DHTML / AJAX workarounds. Despite how wonderfull the supporting libraries are these days, it is still in no ways comparable to a decent desktop application. Fortunately I am developing an online application in which we can get away by demanding minimal system requirements at the user’s site. Such as the use of Windows XP / Vista and the use of IE7.
The coming of the asp.net MVC framework had me thinking about the nature of markup and specifically the difference between the way ASP.NET Webforms handles this and the new ASP.NET MVC framework. I have not really used it yet, but when you come across MVC examples there is no doubt that the feel and look reminds you of the classic ASP style of writing markup: a lot of intermixing between markup and code and logic handling inside templates.
Ah, so finally Microsoft has also taken the road towards the Model-View- Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self- proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are ‘seperation of concerns’ and ‘designed for testability’. Let’s take a look at these two: Seperation of concerns.