Thursday, October 30, 2014

3Pillar Open Source Meetup

3Pillar Open Source Meetup

Hi Folks,

There is an open source meet up in our organization.

Please reach our office on November 14,friday to find out more about SocialAuth and Amazon Web services.



Please touch base with me for this event on given below number.


Warm Regards

Sachin Kalia

Tuesday, October 28, 2014

Func Delegate Using Lambda Expression in C#

Func Delegate Using Lambda Expression in C#

In this article I'll try to explain a cool feature introduced with .NET 3.5. Known as Func, also named by some developer as a readymade delegate.
Func encapsulates a method with two parameters and returns a value of the type specified by the TResult parameter. It has a few overloaded methods as depicted below:

If you look into the image shown above then it shows you five overloaded methods.

Definition of Func<>
I've used a delegate that contains the following syntax defined as below:
Now let's discuss how it works and accepts parameters. In the Func<> delegate there are three params being passed, the first one is of string type named "a", the second "b" is also a string type and the third is a result type that is also a string type.
If you find the definition of Func using F12 then it gives you the following details:
Internally it's a delegate that accepts two params and returns a TResult.

At the initial level of code segment I've set a description that contains some delimiters. My task is to remove all of it from the description.

  1: string description = "<b>Hi Welcome to world of .net</b> ,There are lot of new and emerging things into .net</br>"
  2:                                  + "<h1>Make it your passion to help community and cheer for every moment</h1></br>"
  4: Declaration of Func<>
  6: Func<string, string, string> replaceExtra = (a, b) => a.Replace(b, string.Empty);

The purpose of this delegate is to replace all the occurrences of delimiters like "<b>,</b>,</br><h1></h1>".

Use of replaceExtra Func<>

The code segment shown below uses the replaceExtra that takes two params (both are of string type) and returns the value as a string type also.

  1: description = replaceExtra(description, charsToReplace[0]);

Now let's run this and examine the working behavior:
When we run the program initially without using the replaceExtra Func<> delegate, it prompts the following screen:

Now I use the following lines of code and try to replace all occurrences of delimiters:

  1: description = replaceExtra(description, charsToReplace[0]);
  2: description = replaceExtra(description, charsToReplace[1]);
  3: description = replaceExtra(description, charsToReplace[2]);
  4: description = replaceExtra(description, charsToReplace[3]);

Again press F5 and see the magic of Func<>.


You can download a sample application from here:

Func Delegate Using Lambda Expression in C#

Hope you enjoyed this demonstration.

To learn more about MVC please go to the following link.
MVC Articles

Download FuncDelegate Example


Enjoy Coding and Readingclip_image017

Wednesday, October 15, 2014

Life Cycle of TempData in MVC4

Life Cycle of TempData in MVC4





The idea behind to write this article came from after looking at the “such” image on many web portal as depicted below.



I have referred an image from one of dotnet community website.

Point1. clip_image003


If you notice above shown image I sense some wrongdoings with this because it shows that we could transfer the data from controller to view using VIewBag and ViewData. Though I have noticed we could also transfer data from Controller to View using TempData .Than an above image will look like shown below. I think we should proceed and see how?




I just run an application, it calls action method “verify”. Here we set some value to TempData

  1: TempData["EmployeeRegistration"] = ObjEmp.GetEmpRegistrationsDetails(); 

as shown in image below also:


Now I access the TempData value at View level very easily like shown in image below:



So it means that TempData value persist at successive request and can transmit from Controller to View. After transferring TempData value from controller to View ,if you again try to use it at other level than it will lost its value and become null. TempData is used to pass data from current request to subsequent request from one level to another level e.g. controller to view, controller to action to another action.



If you want retain TempData value for all request than just use the below method.




Redirection of TempData from one action to another action .please follow the given below steps:



It calls and action method “details” which takes one parameter “id” and also retain its value without using keep method. which means TempData is used to pass data from current request to subsequent request.



Kindly find an attached sample and try it once.

Disclaimer: These all are some finding which I have shared with you.Please touch base with me if you feel any query or suggestion of improvement.

I wish it will help you utilize both feature at best.

To learn more about MVC please go to the following link.

MVC Articles


Enjoy Coding and Readingclip_image017

Friday, October 10, 2014

Shed Lights on Façade pattern : Just an Interface

Shed Lights on Façade pattern : Just an Interface


Façade means “The face or front”. Facade pattern works in a similar manner as its name means.

A definition as given below reference from dofactory.

Ø Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use

Ø Wrap a complicated subsystem with a simpler interface

IN a layman words “façade provides an interface to interact with sub layers to provide the desired result without interacting with sub layers directly from console”.

UML class diagram


I have used a very basic and daily used real life example to show the case. A Mobile shop.

Whenever a customer reaches to mobile shop and asks about mobile phone of Brand like Samsung but under the budget (budget could vary) . Please have a look into an image given below:



As in the image shown above, customer is asking for a phone of brand Samsung under the 15000 INR. He just asked to an interface/ façade layer “shopkeeper”. It doesn’t matter for him what happened behind the scene but he wants the mobile as he desired.

Hope scenario is cleared.

Now we jumped into a code segment and understand it practically.

This is the typical class diagram for the Façade pattern:


The classes, interfaces and objects in the above class diagram can be identified as follows:

Stock, Price, - These are subsystems.

MobileFacade- Facade class.

Structural code in C#

This structural code demonstrates the Facade pattern which provides a simplified and uniform interface to a large subsystem of classes.

Subsystems Classes Stock and Price code is depicted below:

  1: public class Price
  2:     {
  3:         public string GetMobileNameUnderPrice(string objMobileName,int price)
  4:         {
  5:             switch (price)
  6:             {
  7:                 case 8000:
  8:                     {
  9:                         return objMobileName+ " Trend";                        
 10:                     }
 12:                 case 10000:
 13:                     {
 14:                         return objMobileName+ " Ace";
 15:                     }
 16:                 case 15000:
 17:                     {
 18:                         return objMobileName+ " Grand";
 19:                     }
 20:                 case 25000:
 21:                     {
 22:                         return objMobileName+ " S3";
 23:                     }
 24:                 default:
 25:                     return objMobileName+" Guru";
 26:                     break;
 27:             }
 28:         }
 29:     }
 31: class Stock
 32:     {
 33:         public bool GetStock()
 34:         {
 35:             return true;
 36:         }
 37:     }

Kindly have a look at the MobileFacade.cs

  1: class MobileFacade
  2:     {
  3:         Stock objStock;
  4:         Price objPrice;
  5:         string strMobileDetails = string.Empty;
  7:         public MobileFacade()
  8:         {
  9:             objStock = new Stock();
 10:             objPrice = new Price();
 11:         }
 13:         public string GetMobIleDetails(string objMobileName, int price)
 14:         {
 15:             if (objStock.GetStock())
 16:             {
 17:                 strMobileDetails = objPrice.GetMobileNameUnderPrice(objMobileName, price);
 19:             }
 20:             return strMobileDetails;
 21:         }
 22:     }

  1: /// <summary>
  2:   /// MainApp startup class for Structural
  3:   /// Facade Design Pattern.
  4:   /// </summary>
  6: class Program
  7:     {
  8:         static void Main(string[] args)
  9:         {
 10:             MobileFacade objMobileFacade = new MobileFacade();
 11:             Console.WriteLine("Please enter the Amount " );
 12:             int amount = Convert.ToInt16(Console.ReadLine());
 14:             string strMobileDetail = objMobileFacade.GetMobIleDetails("Samsung", amount);
 15:            Console.WriteLine(string.Format("The mobile under the price {0} : => is {1}  ",amount, strMobileDetail));
 16:             Console.ReadLine();
 17:         }
 18:     }

If you run you application it asks you to give some amount value so that façade could find out the mobile under the price you have provided:


OutPut will be as shown below:



· The main advantages of this pattern are that you only interact with an interface to get desired result. What happens behind the scene doesn’t matter.

· There will be an entry point to each level of layered software.


· A tightly coupled system. Entry point is dependent on sub layers.

· Façade layers have to create many objects of subclasses internally to get desired output.

Disclaimer: These all are some finding which I have shared with you.Please touch base with me if you feel any query or suggestion of improvement.

I wish it will help you utilize both feature at best.

To learn more about MVC please go to the following link.

MVC Articles


Enjoy Coding and Readingclip_image009

Monday, October 6, 2014

Shed Some Light On Decorator Pattern in C#

Decorator Pattern in C#


"Design Patterns are general, repeatable solutions to common recurring problems in software development."

A "pattern" has been defined as "an idea that has been useful in one practical context and will probably be useful in others".
A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
In this article I'll try to share my thoughts of one of Structural Design Pattern named Decorator.
Structural Design Patterns are concerned with how classes and objects are combined to form larger structures.
Let's jump into this and try to swim.

The Gang Of Four (GOF) defines the Decorator pattern as "Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality."

Closed for Modification and Open for Extension
One of the main challenges we encounter in development is change. The Closed for Modification and Open for Extension principle says a new functionality can be added by keeping the original code unchanged. To explore more on this kindly visit: The Open Closed Principle of SOLID

In our applications we occasionally create an object with some basic requirements and later we'd like to add some more functionality to this object dynamically with additional subclasses, in that scenario we use the Decorator Pattern.

Let's assume we have an object that saves a stream in a Comma Separated Value (CSV) format. Later we need to add more behavior to the same object to save that stream in a bit more secure format like a PDF with a password.
Here is the class diagram of the Decorator depicted below:


The classes and/or objects participating in this pattern are:

  • Component (Pizza)
    • Defines the interface for objects that can have responsibilities added to them dynamically.
  • ConcreteComponent (ThinCrust,ThikCrust)
    • Defines an object to which additional responsibilities can be attached.
  • Decorator (Decorator)
    • This defines the interface for all the dynamic functionalities that can be added to the reference to a ConcreateComponent.
  • ConcreteDecorator (OnionPizzaDecorator, CheezPizzaDecorator,)
    • Adds responsibilities to the component.

To understand the decorator pattern let us extend the example being used here. We have a Pizza class as a base class. Later we may add more stuff, like toppings on each Pizza, for example extra cheeze, Onions and Jalapeno with Baby Corn.
I have chosen a very simple example (Pizza) because most people would be familiar with this. Though there could be the same scenario for other objects like for Ice Cream and Coffee.
Let us start by creating the component class.

  1: public abstract class Pizza
  2: {
  3: public abstract double GetPrice();
  4: }

Here is the ConcreateConponent class defines the functionality of the base class Pizza.

  1: class ThikCrust : Pizza
  2: {
  3:     private double p_Price = 250.0;
  5:     public override double GetPrice()
  6:     {
  7:         return p_Price;
  8:     }
  9: }
 11: class ThinCrust : Pizza
 12: {
 13:     private double p_Price = 200.0;
 15:     public override double GetPrice()
 16:     {
 17:         return p_Price;
 18:     }
 19: }

We are done with the ConcreateConponent and ready for our base object. Now we need to add additional functionality to the base Pizza like the toppings, cheeze and other extra stuff. Let's create a Decorator Class. The main advantages of the decorator is to continue the use of the original class.
Because there may be many reasons to change the class.

Conclusion on Change

So basically we can conclude that whenever changes are required, the possible solutions could be:

  • Change the original class

  • Subclass it and create a subclass

  • Use the Decorator Pattern and still use the original class

The Decorator class code structure is shown below that extends the base Pizza class.

Public class Decorator: Pizza
Pizza basePizza = null;

protected double p_Price = 0.0;

protected Decorator(Pizza objPizza)
basePizza = objPizza;
public override double GetPrice()
return p_Price + basePizza.GetPrice();

First, this class extends the Pizza abstract class. The reason for that is a ThikCrust with a Component will also be a Pizza and thus all the operations possible on a Pizza should also be possible on a decorated Pizza.
The classes CheezPizzaDecorator and OnionPizzaDecorator extends the Decorator class also and has its own added behavior. You can find this class implementation in the sample application.
Now our client application can create a combination of these ConcreteComponents with any Decorator. Let's look at the sample code implementation for the client.

The following will be the output:
It's very easy to understand, especially for those who are not familiar with this pattern. Hope you enjoyed this illustration.
You can download source code from here.

Decorator Pattern in C#

To learn more about MVC please go to the following link.

MVC Articles

Enjoy coding and reading.