SOLID Principles in Brief

SOLID is a term describing a collection of design principles for good code. It was invented by Robert C. Martin(Uncle Bob).

SOLID means:
a. Single Responsibility Principle
b. Open/Closed Principle
c. Liskov Substitution Principle
d. Interface Segregation Principle
e. Dependency Inversion Principle

a. Single Responsibility Principle
Single Responsibility Principle states that every class should have a single responsibility. There should never be more than one reason for a class to change.

//This class violates Single Responsibility Principle since this class is doing two
//things. It is dealing with both opening \ closing connections and with 
//data communication.
public interface IDatabase
{
    void Connect(string connectionString);
    void Close();
    object GetData();
    void SendData(object data);
}

Refactored code to follow Single Responsibility Principle and Open\closed principle:

//IDatabase class has now been refactored into two classes. The IDataManager 
//class deals with data communication.The IConnectionManager 
//class deals with opening \ closing connections. These classes now follow the 
//Single Responsibility Principle.
public interface IDataManager
{
    object GetData(IConnectionManager connManager);
    void SendData(IConnectionManager connManager, object data);
}
public interface IConnectionManager
{
    void Connect(string connectionString);
    void Close();
}

b. Open/Closed Principle
Open/Closed Principle states that software entities should be open for extension, but closed for modification.

In the example above, refactoring IDatabase into IConnectionManager, IDataManager classes allows the client application to either
a. if the client application likes to change the way it opens or closes connection, it can implement its own IConnectionManager and pass it to the IDataManager class i.e Without touching the original code, it is able to extend the functionality of the classes without actually breaking the already existing class.
b. if the client application likes to change the way its getting or sending data it can implement its own IDataManager and use it with the already existing implementation of IConnectionManager.

c. Liskov Substitution Principle
Liskov Substitution Principle states that code that uses a base class must be able to substitute a subclass without knowing it.

public class DatabaseRepository
{
    //This method violates Liskov Substitution Principle since it consumes an object 
    //of a base type but internally uses the base type's subclass. According to 
    //Liskov Substitution Principle, it should not know it is using base class 
    //or its subtypes. 
    public bool TestConnection(IConnectionManager connMngr)
    {
        if (connMngr is SqlServerConnectionManager)
        {
            // Do something...
        }
        else if (connMngr is OracleConnectionManager)
        {
            // Do something else...
        }
        else
        {
            // ...
        }
    }
}
public interface IConnectionManager
{
    void Connect(string connectionString);
    void Close();
}
public class SqlServerConnectionManager: IConnectionManager
{
    public void Connect(string connectionString)
    {
    }
    public void Close()
    {
    }
}
public class OracleConnectionManager : IConnectionManager
{
    public void Connect(string connectionString)
    {
    }
    public void Close()
    {
    }
}

d. Interface Segregation Principle
The Interface Segregation Principle states that clients should not be forced to implement interfaces they don’t use.

Existing Design
Let’s assume we have to implement a new Robot class in this design. Robots will need to implement the IWorker interface because robots works. On the other side, they don’t have to implement it because they don’t eat. If we keep the present design, the new Robot class is forced to implement the “eat” method.

public interface IWorker 
{
	public void Work();
	public void Eat();
}
public class Worker : IWorker
{
	public void Work() 
        {
	}
	public void Eat() 
        {
	}
}
public class Manager 
{
	IWorker worker;
	public void SetWorker(IWorker w) 
        {
		worker=w;
	}
	public void Manage() 
        {
		worker.Work();
	}
}

Interface Segregation Principle implemented in current design

//Following code supports the Interface Segregation Principle. By splitting the 
//IWorker interface in IFeedable, IWorkable interfaces the new Robot class is 
//no longer forced to implement the "eat" method.
public interface IWorker : IFeedable, IWorkable 
{
}
public interface IWorkable 
{
	public void Work();
}
public interface IFeedable
{
	public void Eat();
}
public class Worker : IWorkable, IFeedable
{
	public void Work() 
        {
	}
	public void Eat() 
        {
	}
}
public class Robot : IWorkable
{
	public void Work() 
        {
	}
}
public class Manager 
{
	IWorkable worker;
	public void SetWorker(IWorkable w) 
	{
		worker=w;
	}
	public void Manage() 
	{
		worker.Work();
	}
}

e. Dependency Inversion Principle
Dependency Inversion Principle states that
1. High-level modules(Manager class) should not depend on low-level modules(Worker, SuperWorker classes). Both(Manager, Worker, SuperWorker classes) should depend on abstractions(IWorker).
2. Abstractions should not depend on details. Details should depend on abstractions.

Existing Design
Let’s assume we have to implement a new SuperWorker class in this design. If we do that then we will have to change the Manager.Manage() method also which introduces risk.

public class Worker 
{
	public void Work() 
	{
	}
}
public class SuperWorker: Worker 
{
	public void Work() 
	{
	}
}
public class Manager 
{
	Worker worker;
	public void SetWorker(Worker w) 
	{
		worker = w;
	}
	public void Manage() 
	{
		worker.Work();
	}
}

Dependency Inversion Principle implemented in current design

//Following code supports the Dependency Inversion Principle. In this new design 
//a new IWorker Interface has been added. Now the Manager class doesn't require 
//changes when SuperWorkers are added since the work has been delegated to the 
//SuperWorker class.It also reduces risk since no other parts of the system need 
//to be tested.
public interface IWorker 
{
	public void Work();
}
public class Worker : IWorker
{
	public void Work() 
	{
	}
}
public class SuperWorker : IWorker
{
	public void Work() 
	{
	}
}
public class Manager 
{
	IWorker worker;
	public void SetWorker(IWorker w) 
	{
		worker = w;
	}
	public void Manage() 
	{
		worker.Work();
	}
}

Dependency Injection is about how one object acquires a dependency.
Inversion of Control (IoC) means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside source (for example, an xml configuration file).
Dependency Injection (DI) means that this is done without the object intervention, usually by a framework component that passes constructor parameters and set properties.

Dependency Injection Container is a way to auto-wire classes

Continue Reading

Database performance tuning concepts in brief

Predicates are used to used to specify a subset of rows to be returned. They are specified in the WHERE clause of a SQL statement.
In the example below “Id = 1” is a predicate:

SELECT * FROM Employee WHERE Id = 1;

Estimated Execution Plan defines how a query should actually execute
Actual Execution Plan tells what happened while a query was executed.
Table Scan/Index Scan looks at each and every row available in the table/index
Index Seek has address of each row based on the key field value. So seek directly goes to that data page and fetches the row if your predicate matches with the key field.
Key Lookup, In case of Key lookup, SQL server storage engine has to go from non-clustered index to clustered index, in order to fetch the value of non-key field of non-clustered index. This round-trip always consumes time and decreases performance.

Continue Reading

Tips to increase database performance

Here are some of the points that you should consider when you write queries:

  • Limit number of rows and columns
  • Use “Search argument able” conditions in “where” clause. They help query optimizers to use the index defined on column(s) effectively and have a higher chance of meeting index seek than index or table scan.
    “Search argument able” operators are :
    =, >, >=, <, <=, BETWEEN, LIKE (only those LIKE conditions that have a wildcard character as a suffix, eg: FirstName LIKE 'A%'
  • Do not use arithmetic operators directly on the “column name” in the “where” clause. Instead use logical workarounds to get performance benefits. eg:
    instead of

    WHERE HourlyRate * 8 <= 100

    use

    WHERE HourlyRate <= 100/8
  • Do not use functions on columns in the “where” clause. eg:
    a. Instead of

    WHERE DATEPART(YYYY,CreateDate)='2016'

    use

    WHERE CreateDate >= '01/01/2016' AND CreateDate <= '12/31/2016'
  • b. Instead of

    WHERE Left(LastName,1)='A'

    use

    WHERE LastName LIKE 'A%'
  • Use proper primary and Foreign Key constraints. They help the query optimizer select the best-suited execution plan for the query.
  • Here are some of the points that you should consider when designing indexes.

  • Try to use maximum 4-5 indexes on one table, not more. If you have read-only table, then the number of indexes may be increased.
  • Keep your indexes as narrow as possible. This reduces the size of the index and reduces the number of reads required to read the index.
  • Try to create indexes on columns that have integer values rather than character values.
  • If you create a composite (multi-column) index, the order of the columns in the key are very important. Try to order the columns in the key as to enhance selectivity, with the most selective columns to the leftmost of the key.
  • Continue Reading

    Distinct on multiple properties in a collection

    Problem:
    How do I get distinct members of a collection, based on multiple properties?

    Solution:
    Use MoreLinq to get distinct members of a collection, based on multiple properties.
    eg: For our application, each member in the household was supposed to have a unique combination of driver’s licence number and driver’s state.

     
    var query = household.DistinctBy(
                counter => new { counter.DriverLicenceNumber, counter.DriverLicenceState });
    
    Continue Reading

    Configure StructureMap for Asp.Net MVC

    Problem:
    How do I configure StructureMap for Asp.Net MVC?

    Solution:
    a. Install StructureMap using NuGet and the following command.

    install-package StructureMap.MVC5 
    

    Once StructureMap is installed, you’ll notice several additions to your web project including a new “DependencyResolution” folder.

    Dependency Injection

    b. Create a new interface. Implement this interface with a new class.

     public interface IDependency
        {
            string SayHelloWorld();
        }
        public class Dependency : IDependency
        {
            public string SayHelloWorld()
            {
                return "Hello World";
            }
        }
    

    c. Have the Controller work with this interface:

    public class HomeController : Controller
    {
        private readonly IDependency dependency;
        public HomeController(IDependency dependency)
        {
            this.dependency = dependency;
        }
        public ActionResult Index()
        {
            return Content(this.dependency.SayHelloWorld());
        }
    }
    

    d. Run your application.The “Concrete Dependency” is successfully injected in HomeController.
    Dependency Injection-Results

    We didn’t tell StructureMap how to resolve the “IDependency” interface, or let it know anything about the “Dependency” implementation. How did it figure this out?

    In the DefaultRegistry.cs file, there is a line of code that reads

    scan.WithDefaultConventions();
    

    This code will automatically attempt to resolve any interface named “IDependency” with an instance type named “Dependency”. That is, the same name, but without the “I” prefix. If instead the name of the class was “ConcreteDependency” then the code below will not work. in this case, you will have to specify the types explicitly.You would do that by adding.

    For<IDependency>().Use<ConcreteDependency>();
    

    It is commented out in the DefaultRegistry.cs code

    public class DefaultRegistry : Registry 
    {
            public DefaultRegistry() 
            {
                Scan(
                    scan => 
                    {
                        scan.TheCallingAssembly();
                        scan.WithDefaultConventions();
                        scan.With(new ControllerConvention());
                    });
                    //For<IDependency>().Use<ConcreteDependency>();
            }
    }
    
    public static class IoC
        {
            public static IContainer Initialize()
            {   
                return new Container(c => c.AddRegistry<DefaultRegistry>());
            }
        }
    
    Continue Reading

    Show traffic from only certain hosts in Fiddler

    A lot of times when we “show traffic” in Fiddler, way too much traffic gets logged. To cut the “noise” out, we want to show traffic from only certain hosts. To do this:

    • Check the “use filters” checkbox.
    • In the “Show only the following hosts” textbox, type the names of the hosts separated by colon.
    • If you have several similar hosts then you can use wildcards also.
      Example: If you want to log the requests for drive.realpage.com, photos.realpage.com then instead of listing each one of them, you can use *.realpage.com. See below for an example

    FiddlerFiltersTab

    Continue Reading

    Convert the interface of a class into another interface that the clients expects(Adapter Pattern)

    Adapter Pattern

    Adapter pattern:

        class Program
        {
            static IExpectedInterface dependency = new Adapter(new TargetClass());
            static void Main(string[] args)
            {
                dependency.MethodA();
            }
        }
        public interface IExpectedInterface
        {
            void MethodA();
        }
        public class Adapter : IExpectedInterface
        {
            public Adapter(TargetClass target)
            {
                this.target = target;
            }
            public void MethodA()
            {
                target.MethodB();
            }
            private TargetClass target;
        }
        public class TargetClass
        {
            public void MethodB()
            {
            }
        }
    

    Advantages of using a Adaptor pattern:

    • Adapter pattern lets classes work together that couldn’t otherwise because of incompatible interfaces.
    • The code is more maintainable.
    • most of the applications using third party libraries use adapters as a middle layer between the application and the 3rd party library to decouple the application from the library. If another library has to be used only an adapter for the new library is required without having to change the application code.
    Continue Reading

    Log state of a object for diagnostic purposes

    Problem:
    How do I log state of a object for diagnostic purposes?

    Solution:
    We extended the class provided at Serialize and Deserialize IEnumerable Objects by adding a ToXMLString() method. This method serializes the passed object parameter to an XML string. The object state is stored in the Data property of the exception and then logged using a logging framework of choice.

    var exception = new Exception();
    exception.Data.Add("GuestCard", new CustomXmlSerializer().ToXMLString(guestCard));
    //Log the exception using a logging framework of your choice. 
    

    Extended Class: (See Serialize and Deserialize IEnumerable Objects)

        using System.Text;
        using System.IO;
        using System.Xml;
    
        public class CustomXmlSerializer
        {
            public void WriteXml(object source, System.Xml.XmlWriter writer)
            {
                WriteXml(source, writer, null);
            }
            public string ToXMLString(object source)
            {
                var stringBuilder = new StringBuilder();
                var stringWriter = new StringWriter(stringBuilder);
                var xmlTextWriter = new XmlTextWriter(stringWriter);
                WriteXml(source, xmlTextWriter);
                return stringBuilder.ToString();
            }
        }
    
    Continue Reading

    Mock ASP.Net internals when unit testing ASP.Net MVC.

    Problem:
    ASP.NET MVC controller context depends on asp.net internals. How should these be mocked for unit tests?

    Solution:

    Here is a sample unit test class using MsTest and Moq which mocks HttpRequest and HttpResponse objects. Controller action get value from request and sets http header in response objects. Other http context objects could be mocked up in similar way.

    using System.Web;
    using System.Web.Mvc;
    using System.Web.Routing;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using Moq;
    
    [TestClass]
    public class SampleControllerTest
    {
        protected Mock<HttpContextBase> httpContextBaseMock;
        protected Mock<HttpRequestBase> httpRequestBaseMock;
        protected Mock<HttpResponseBase> httpResponseBaseMock;
    
        [TestInitialize]
        public void TestInitialize()
        {
            this.httpContextBaseMock = new Mock<HttpContextBase>();
            this.httpRequestBaseMock = new Mock<HttpRequestBase>();
            this.httpResponseBaseMock = new Mock<HttpResponseBase>();
            this.httpContextBaseMock.SetupGet(x => x.Request).Returns(
            this.httpRequestBaseMock.Object);
            this.httpContextBaseMock.SetupGet(x => x.Response).Returns(
            this.httpResponseBaseMock.Object);
        }
    
        protected SampleController SetupController()
        {
            var controller = new SampleController();
            var routeData = new RouteData();
            controller.ControllerContext = new ControllerContext(
            this.httpContextBaseMock.Object, routeData, controller);
            controller.Url = new UrlHelper(
            new RequestContext(this.httpContextBaseMock.Object, routeData), 
            new RouteCollection());
            return controller;
        }
    
        [TestMethod]
        public void IndexTest()
        {
            this.httpRequestBaseMock.Setup(x => x["x"]).Returns("1");
            this.httpResponseBaseMock.Setup(x => x.AddHeader("name", "value"));
    
            var controller = SetupController();
            var result = controller.Index();
            Assert.AreEqual("1", result.Content);
    
            this.httpRequestBaseMock.VerifyAll();
            this.httpResponseBaseMock.VerifyAll();
        }
    }
    
    public class SampleController : Controller
    {
        public ContentResult Index()
        {
            var x = Request["x"];
            Response.AddHeader("name", "value");
            return Content(x);
        }
    }
    
    Continue Reading

    Log exceptions in classic(asmx) web services using Soap Extension

    Problem:
    Log exceptions in classic(asmx) webservices without adding try-catch blocks throughout all the webservice.

    Solution:
    Exceptions can be easily logged in classic(asmx) webservices by using a Soap Extension.
    a. Create the soap extension. Override the call to ChainStream method where we get a new copy of the stream. Use the ProcessMessage switch to examine the Soap Envelope and log an exception using a logging framework of our choice(I have used Elmah logging framework here).
    b. Register the SoapExtension in the client application’s web configuration. The “type” property follows the format of
    NameSpaceName.ClassName, SoapExtension’sAssemblyName.

    namespace SoapExtensions
    {
        using System;
        using System.IO;
        using System.Web.Services.Protocols;
    
        using Elmah;
    
        public class ElmahSoapExtension : SoapExtension
        {
            private Stream oldStream;
            private Stream newStream;
    
            public string Request { get; private set; }
            public string Response { get; private set; }
    
            public override Stream ChainStream(Stream stream)
            {
                oldStream = stream;
                newStream = new MemoryStream();
                return newStream;
            }
    
            public override void ProcessMessage(SoapMessage soapMessage)
            {
                switch (soapMessage.Stage)
                {
                    case SoapMessageStage.BeforeSerialize:
                        break;
                    case SoapMessageStage.AfterSerialize:
                        Response = GetSoapEnvelope(newStream);
                        if (soapMessage.Exception != null)
                        {
                            var exception = soapMessage.Exception.GetBaseException();
                            exception.Data.Add("WebService Response", Response);
                            ErrorSignal.FromCurrentContext().Raise(exception);
                        }
                        CopyStream(newStream, oldStream);
                        break;
                    case SoapMessageStage.BeforeDeserialize:
                        CopyStream(oldStream, newStream);
                        Request = GetSoapEnvelope(newStream);
                        break;
                    case SoapMessageStage.AfterDeserialize:
                        break;
                }
            }
    
            private static string GetSoapEnvelope(Stream stream)
            {
                stream.Position = 0;
                var streamReader = new StreamReader(stream);
                var text = streamReader.ReadToEnd();
                stream.Position = 0;
                return text;
            }
    
            private static void CopyStream(Stream streamFrom, Stream streamTo)
            {
                var textReader = new StreamReader(streamFrom);
                var textWriter = new StreamWriter(streamTo);
                textWriter.WriteLine(textReader.ReadToEnd());
                textWriter.Flush();
            }
            public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)
            {
                return null;
            }
            public override object GetInitializer(Type WebServiceType)
            {
                return null;
            }
            public override void Initialize(object initializer)
            {
            }
        }
    }
    
    <?xml version="1.0"?>
    <configuration>
    	<system.web>
    		<webServices>
          <soapExtensionTypes>
            <add 
            type="SoapExtensions.ElmahSoapExtension, SoapExtensions" 
            priority="1" group="1" />
          </soapExtensionTypes>      
    		</webServices>
    	</system.web>
    </configuration>
    
    Continue Reading