Quote for the Week

"Learn to enjoy every moment of your life"

Tuesday, January 27, 2015

S.O.L.I.D Architecture principle in C# (Part 2)

Continue to Friday, January 23, 2015
-----------------------------------------------

O: Open/Closed Principle -

The Open/closed Principle says "A software module/class is open for extension and closed for modification".

Let's say you created a class that provides certain functionality. A few months later some need arises such that the class is supposed to provide some additional functionality. In such cases you shouldn't touch the source code of the class that is already built. Instead, you should be able to extend it so as to add the extra functionality.

Let's try to understand this with an example. Suppose that you are building a class that is responsible for calculating taxes on a given income. At the time of development you were told that this class will be used for tax calculation in three countries, say USA, UK and India. The following code shows a simplistic representation of such a class.


public class TaxCalculator
{
    public decimal CalculateTax(decimal amount,string country)
    {
        decimal taxAmount = 0;
        switch(country)
        {
            case "USA":
                //calculate tax as per USA rules
                break;
            case "UK":
                //calculate tax as per UK rules
                break;
            case "IN":
                //calculate tax as per India rules
                break;
        }
        return taxAmount;
    }
}

The TaxCalculator class has a method CalculateTax() that accepts the amount on which the tax is to be calculated and the country whose tax calculation rules are to be applied. Inside, a switch statement checks the country and accordingly the tax is calculated and returned to the caller.

Now, suppose that after a few months you also need to calculate tax in a few more countries. How will you take care of this additional functionality? You will change the CalculateTax() method and add additional cases inside the switch statement. That means any change in the functionality is forcing you to change the core class - TaxCalculator. This is violation of OCP.

Now, let's rewrite our code so that it follows OCP.

public abstract class TaxCalculatorBase
{
    public decimal TotalAmount { get; set; }
    public abstract decimal CalculateTax();
}
 
public class USATax:TaxCalculatorBase
{
    public override decimal CalculateTax()
    {
        //calculate tax as per USA rules
        return 0;
    }
}
 
public class UKTax : TaxCalculatorBase
{
    public override decimal CalculateTax()
    {
        //calculate tax as per UK rules
        return 0;
    }
}
 
public class IndiaTax : TaxCalculatorBase
{
    public override decimal CalculateTax()
    {
        //calculate tax as per India rules
        return 0;
    }
}

The above code creates an abstract class TaxCalculatorBase. This class defines a public property - TotalAmount - and an abstract method CalculateTax(). The CalculateTax() method doesn't have any code since it is an abstract method. The actual tax calculation happens in the derived classes - USATax, UKTax and IndiaTax. These classes provide the concrete implementation of the CalculateTax() method. Tomorrow if tax calculation is needed for a few more countries you need not modify any of the existing code. All you need to do is create another class that inherits from TaxCalculatorBase class and implement the required tax calculation logic inside its CalculateTax() method.

Friday, January 23, 2015

S.O.L.I.D Architecture principle in C#

What is SOLID?



SOLID are five basic principles whichhelp to create good software architecture. SOLID is an acronym where:-
  1. S stands for SRP (Single responsibility principle
  2. O stands for OCP (Open closed principle)
  3. L stands for LSP (Liskov substitution principle)
  4. I stands for ISP ( Interface segregation principle)
  5. D stands for DIP ( Dependency inversion principle)
Day 1:

"S" - Single Responsibility Principle.


The Single Responsibility Principle (SRP) states that:

A class should have only a single responsibility. Only one potential change in the software's specification should be able to affect the specification of the class.

This means that every class, or similar structure, in your code should have only one job to do. Everything in that class should be related to a single purpose. Our class should not be like a Swiss knife wherein if one of them needs to be changed then the entire tool needs to be altered. It does not mean that your classes should only contain one method or property. There may be many members as long as they relate to the single responsibility.

The Single Responsibility Principle gives us a good way of identifying classes at the design phase of an application and it makes you think of all the ways a class can change. A good separation of responsibilities is done only when the full picture of how the application should work. Let us check this with an example.

public class UserService  
{  
   public void Register(string email, string password)  
   {  
      if (!ValidateEmail(email))  
         throw new ValidationException("Email is not an email");  
         var user = new User(email, password);  
  
         SendEmail(new MailMessage("mysite@nowhere.com", email) { Subject="HEllo foo" });  
   }
   public virtual bool ValidateEmail(string email)  
   {  
     return email.Contains("@");  
   }  
   public bool SendEmail(MailMessage message)  
   {  
     _smtpClient.Send(message);  
   }  
}   

It looks fine, but it is not following SRP. The SendEmail and ValidateEmail methods have nothing to do within the UserService class. Let's refract it.

public class UserService  
{  
   EmailService _emailService;  
   DbContext _dbContext;  
   public UserService(EmailService aEmailService, DbContext aDbContext)  
   {  
      _emailService = aEmailService;  
      _dbContext = aDbContext;  
   }  
   public void Register(string email, string password)  
   {  
      if (!_emailService.ValidateEmail(email))  
         throw new ValidationException("Email is not an email");  
         var user = new User(email, password);  
         _dbContext.Save(user);  
         emailService.SendEmail(new MailMessage("myname@mydomain.com", email) {Subject="Hi. How are you!"});  
  
      }  
   }  
   public class EmailService  
   {  
      SmtpClient _smtpClient;  
   public EmailService(SmtpClient aSmtpClient)  
   {  
      _smtpClient = aSmtpClient;  
   }  
   public bool virtual ValidateEmail(string email)  
   {  
      return email.Contains("@");  
   }  
   public bool SendEmail(MailMessage message)  
   {  
      _smtpClient.Send(message);  
   }  
}   

Let's see remaining things on tomorrow's post.

Thursday, January 22, 2015

ObservableCollection in WPF

An ObservableCollection is a dynamic collection of objects of a given type. Objects can be added, removed or be updated with an automatic notification of actions. When an object is added to or removed from an observable collection, the UI is automatically updated. This happens because, when binding to an observable collection, WPF automatically adds a CollectionChanged event handler to the ObservableCollecion's events.

The ObservableCollection class exists in the System.Collections.ObjectModel namespace.

I will demonstrate how this works in a simple example:

I have a window with a Button, two TextBoxes and a ListView and each time you click the Button the text of the TextBox is added to the collection and the ListView is updated automatically.

UI

ObservableCollection-in-SQL-Server.jpg


Code File

public partial class MainWindow : Window
{
     private ObservableCollection<Person> person; 
     public MainWindow()
     {
         InitializeComponent();
         person = new ObservableCollection<Person>()
         {
             new Person(){Name="Prabhat",Address="India"},
             new Person(){Name="Smith",Address="US"}
         };
         lstNames.ItemsSource = person;
     }
     private void btnNames_Click(object sender, RoutedEventArgs e)
     {
         person.Add(new Person() { Name = txtName.Text, Address = txtAddress.Text });
         txtName.Text = string.Empty;
         txtAddress.Text = string.Empty;
     }
}
public class Person
{
     public string Name { get; set; }
     public string Address { get; set; }
Here a Person class has the 2 properties Name and Address.  One observableCollection object is created with a Person type and bound to the ListView. See:

lstNames.ItemsSource = person;
By doing so, we can dynamically insert, update and remove items from the ListView, as in:

person.Add(new Person() { Name = txtName.Text, Address = txtAddress.Text });

XAML File

<Grid>
         <Grid.ColumnDefinitions>
             <ColumnDefinition/>
             <ColumnDefinition Width="*"/>
         </Grid.ColumnDefinitions>
         <Grid.RowDefinitions>
             <RowDefinition Height="*"></RowDefinition>
         </Grid.RowDefinitions>
         <StackPanel Grid.Row="0" Grid.Column="0" Margin="5,5,5,5">
             <TextBlock x:Name="lblName" Text="Name"></TextBlock>
             <TextBox x:Name="txtName"></TextBox>
             <TextBlock x:Name="lblAddress" Text="Address"></TextBlock>
             <TextBox x:Name="txtAddress"></TextBox>
             <Button Grid.Column="0" Width="100" Height="20" Margin="5,5,5,5" x:Name="btnNames" Click="btnNames_Click" Content="Add"></Button>
         </StackPanel>
         <ListView x:Name="lstNames" Margin="5,5,5,5" Grid.Column="1" Grid.Row="0">
             <ListView.View>
                 <GridView x:Name="grdNames">
                     <GridViewColumn Header="Name"  DisplayMemberBinding="{Binding Name}"/>
                     <GridViewColumn Header="Address"  DisplayMemberBinding="{Binding Address}"/>
                 </GridView>
             </ListView.View>
         </ListView>
 </Grid>
The ObservableCollection is already bound to the Listview. So all we need to do in the XAML file is to specify the binding member for each column. We can do that by the "DisplayMemberBinding" attribute and "Binding" markup extension. See:

<GridViewColumn Header="Name"  DisplayMemberBinding="{Binding Name}"/>

Tuesday, January 20, 2015

Ways of Assigning value for Drop down list using jquery

You know, sometimes small things will take long time to implement. Usually this will happen if we are not familiar with them. For this, plenty of documentation is available around, we should read it before starting it. So, here I am talking about JQuery and the features of it. I know how to select a value in a drop down and populate it using plain javascript. But when comes to JQuery, for me it took sometime to find a way to do that. Below is the way on how to populate a dropdown value as selected.

$("#ddlSource option[value='1']").attr("selected", "selected");

Here, ddlSource is the ID of the HTML select [drop down list] control. The meaning of the above statement is, find the control which has the ID "ddlSource" and in it find the option which has give value and select it. "1", I am using for example. You can pass any value.
If you are using the server side controls, and want to populate the value in JQuery, then use below statement.

$("#<%=ddlSource.ClientID %> option[value='1']").attr("selected", "selected");

But this is not the right way of doing it. You can change the server side drop down values on client side, but which results you the error message "Invalid Postback or Callback event" when submitting data to server. So, take care when you deal with server side controls in javascript.

For best practice Please try to use 

<select runat="server" ID="ddlSource"></select> instead of <asp:DropDownList /> 

to avoid the invalid callback error messages. I know, the immediate question in your mind, how to get the value using <select> control in C# code. Use below code for it.

string selectedValue = Request.Form[ddlSource.UniqueID]; //UniqueID is because Form is expecting name instead of ID..

Monday, January 19, 2015

Dependency Injection in .Net

Dependency Injection (DI) is a software design pattern that allow us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

The Dependency Injection pattern uses a builder object to initialize objects and provide the required dependencies to the object means it allows you to "inject" a dependency from outside the class.

For example, Suppose your Client class needs to use a Service class component, then the best you can do is to make your Client class aware of an IService interface rather than a Service class. In this way, you can change the implementation of the Service class at any time (and for how many times you want) without breaking the host code.


We can modify this code by the DI different ways. We have following different ways to implement DI :

Constructor Injection


  1. This is the most common DI.
  2. Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when instantiating that class.
  3. Injected component can be used anywhere within the class.
  4. Should be used when the injected dependency is required for the class to function.
  5. It addresses the most common scenario where a class requires one or more dependencies.

    public interface IService
    {
        void Serve();
    }
 
    public class Service : IService
   {
        public void Serve()
       {
          Console.WriteLine("Service Called");
           //To Do: Some Stuff
       }
   }
 
   public class Client
   {
    private IService _service;
 
    public Client(IService service)
    {
       this._service = service;
     }
 
     public void Start()
    {
      Console.WriteLine("Service Started");
       this._service.Serve();
       //To Do: Some Stuff
     }
   }

   class Program
   {
     static void Main(string[] args)
     {
       Client client = new Client(new Service());
       client.Start(); 
       Console.ReadKey();
     }
  }

The Injection happens in the constructor, by passing the Service that implements the IService-Interface. The dependencies are assembled by a "Builder" and Builder responsibilities are as follows:
  • knowing the types of each IService.
  • according to the request, feed the abstract IService to the Client.

Property injection

  1. Also called Setter injection.
  2. Used when a class has optional dependencies, or where the implementations may need to be swapped. Different logger implementations could be used this way.
  3. May require checking for a provided implementation throughout the class(need to check for null before using it).
  4. Does not require adding or modifying constructors.   

  public interface IService.
  {
    void Serve();
  }
 
  public class Service : IService
 {
    public void Serve()
   {
     Console.WriteLine("Service Called");
    //To Do: Some Stuff
    }
  }
 
  public class Client
  {
     private IService _service;
 
     public IService Service
    {
      set
    {
      this._service = value;
    }
    }
 
   public void Start()
   {
      Console.WriteLine("Service Started");
      this._service.Serve();
      //To Do: Some Stuff
    }
  }

 class Program
 { 
 static void Main(string[] args)
 {
 Client client = new Client();
 client.Service = new Service();
 client.Start();
 
 Console.ReadKey();
  }
 }

Method injection

  1. Inject the dependency into a single method, for use by that method.
  2. Could be useful where the whole class does not need the dependency, just the one method.
  3. Generally uncommon, usually used for edge cases.
    public interface IService
   {
     void Serve();
    }
 
    public class Service : IService
    {
       public void Serve()
      {
        Console.WriteLine("Service Called");
        //To Do: Some Stuff
      }
    }
 
    public class Client
   {
      private IService _service;
 
      public void Start(IService service)
     {
        this._service = service;
        Console.WriteLine("Service Started");
       this._service.Serve();
      //To Do: Some Stuff
     }
   }
  class Program
  {
     static void Main(string[] args)
     {
     Client client = new Client();
     client.Start(new Service());
 
     Console.ReadKey();
    }
  }

Key points about DI

  • Reduces class coupling
  • Increases code reusing
  • Improves code maintainability
  • Improves application testing