Friday, March 25, 2011

Overview of Microsoft® Visual Studio® LightSwitch™

If you have been introduced to Microsoft Visual Studio LightSwitch then you might be having one question, “What is LightSwitch really building under the covers?” Is it mere two tier application wrapped in some fancy UI or anything more? This question is very valid and answer is that LightSwitch applications are built on a standard three tier architecture where each tier runs independent of each other and performs the role within its boundaries.

The presentation tier is responsible for human interaction with the application. Its primary concern is data visualization and editing. The logic tier processes requests from a client to fetch data, update data, or to perform other operations. This tier’s primary role is to shield direct access to the data from unwanted or invalid reads and updates. This helps to ensure the long-term integrity and security of the data. The data storage tier is responsible for durable storage of the application data.

Following is the architectural representation of a standard three tier application:

Following is a more concrete representation of three tier architecture in context of Microsoft Visual Studio LightSwitch application.

If you carefully look into all these three tiers you will have enough reasons to be excited. On presentation tier you are getting Silverlight 4.0 based UI. Office automation will let you export you data directly to Excel. Logic tier or application tier or middle tier is built on a set of technologies. There is ADO.NET Entity Framework for access to SQL Server and SQL Azure. There is WCF Data Services for access to SharePoint 2010 via the OData protocol. And if this was not enough there is a shim to talk to an in-memory WCF RIA DomainService for extensibility. Then on the storage front you have SQL Server, SQL Azure and as I mentioned above, using WCF Data Services you can also consume SharePoint based data.

Is it not something more than what you had wished for? I am placing my bet on LightSwitch. Are you?

Thursday, March 24, 2011

Introducing Microsoft® Visual Studio® LightSwitch™

Here comes another development tool from Microsoft. Microsoft Visual Studio LightSwitch is an extension of Microsoft Visual Studio product line and it is squarely aimed to cut down development time drastically. I am sure you would have worked on many applications where there were just some tables and all you had to develop was CRUD functionality. For this kind of applications you don’t need to split your applications in tiers and layers and you don’t need to apply many other architectural principles.

Business value will be better realized if you can turn around such application with minimum of lines and yet with elegant user interface and ability to choose kind of deployment scenarios (web/desktop or cloud). Microsoft Visual Studio LightSwitch is aimed to fill such gap and it will immensely help LOB application development. I believe Jason Zanders did better job Introducing you to Microsoft Visual Studio LightSwitch then I could have done. Go through the Jason’s post and get awestruck! Once you are out of that awe download LightSwitch and start a brand new journey.

Thursday, March 17, 2011

ILSpy, Free Alternative to .Net Reflector

If you ever worked on .net, I am sure you definitely would have used .Net reflector. After all it is such a useful tool to dissemble and see the code. On top of it, it was free. Well it is no more free? Company that maintains the code base of .net reflector has decided to discontinue free version and started charging a fee for it.

Once the news about .net reflector got out, open source community started working on free alternatives of .net reflector. One prominent alternative that is taking shape is ILSpy. It is still not there where it can replace .net reflector, but it is quite good considering the time it has been in development. Give it a try!

Monday, March 14, 2011

Interface or Abstract class

If you are one among who were searching for an answer to the question that what is difference between abstract class and interface then Abstract class Vs Interface provides you enough arsenal. However if you were looking for when to use which one, I will give you two SOLID reasons you should not use abstract classes and instead use interfaces.

SOLID principles are five majorly used guidelines that how should you design your classes. One such SOLID principle is Interface Segregation Principle (ISP). Another principle is The Liskov Substitution Principle (LSP). Interface segregation principle cannot be followed if you are leaning on abstract class. Substitution principle is itself a big problem and if try to work your way out of Substitution principle then you cannot rely on abstract classes. Let's see these two things in detail.

ISP – Many a times you will get into the argument that if an Abstract class is having all its methods as abstract then it is as good as an Interface. Technically yes, but there is more to it than just being technically correct. ISP tells me that make my interfaces as fine grained as I can make them. My interfaces should not be fat. This is so that my clients need not implement something that they were not interested in. Now take an example – Some behaviors of advance nature in Car object:

  1. Air Bag
  2. Alloy Wheels
  3. Power Steering
  4. ABS

Put these guys together in one interface and we have a fat interface, which not all client might be interested to implement. It will look something like this:

interface IAdvanceFeatures
{

AirBag();

AlloyWheel();

PowerSteering();

ABS();

}

Now if you need to apply ISP on it and implement it using abstract classes, then following would be the scenario:

abstract class AirBag
{
AirBag();
}

abstract class AlloyWheels
{

AlloyWheels();

}

I just separated only two features. But wait a minute. In my infinite wisdom I recalled that many modern programming languages stop you from multiple inheritance. Bingo… now you are in a soup where you want to use ISP but abstract classes are not letting you do it. This is one place where abstract class is bad guy.

LSP – Liskov Substitution Principle tells you that "Derived classes must be substitutable for their base classes". This means we should be able to use any of child class object in place of base class object. But in real time will you be able to create such inheritance hierarchy where child class can be substituted for base class. Not really because child class might have specialized something in such manner that it misbehaves when we put it in place of base class. I agree that such a behavior can be called a programming blunder but such is life. What are our alternatives? Our alternative is design by contract. Now contract can be in form of abstract class or interface. But as we established earlier there are limitations (having more than one abstract class) and you wouldn't want to have LSP on the cost of ISP. Would you? So option for abstract class is again stricken out. Sorry abstract class.

In a nutshell if you are trying to implement ISP and trying to stick to design by contract, abstract class is not a choice for you.

Saturday, March 05, 2011

SaaS Maturity Model

A simple blog post on SaaS maturity model.