Changing default route in ASP.NET MVC

Hello friends,

As we know that ASP.NET MVC by default takes following setting available in RouteConfig file (under App_Start folder).

routes.MapRoute(

name: “Default”,

url: “{controller}/{action}/{id}”,

defaults: new { controller = “Home”, action = “Index”, id = UrlParameter.Optional }

);

This means when you run the application, Home controller will be invoked and it’s Index method will be executed by taking parameter id (if any).

you can change this behavior, if it’s making sense to you.

For example if you want to invoke Store controller and It’s Browse method while loading the application, you just need to change few things (controller and action values) as below.

routes.MapRoute(

name: “Default”,

url: “{controller}/{action}/{id}”,

defaults: new { controller = “Store”, action = “Browse”, id = UrlParameter.Optional }

);

Optionally you may also change the id parameter but I would personally recommend not to change (to keep it generic) unless there is some unavoidable reason.

Hope you liked the post. Please share your comments.

Working with Singleton Design Pattern

Hello friends,

I am here to continue the learning series regarding Design Patterns. Today we will go through one of the popular design pattern called Singleton.

In case you have not had a look at our first article, go through the following link:

Before talking about its implementation let’s begin with some fundamental questions as in the following.

Use of the Singleton Pattern

As the name suggests, the Singleton Pattern allows only one instance of a class to be created.

Let’s start by putting some questions to understand the concept.

When do we need to have only one instance of a class?

There are many possible requirements for a instance of a class but they all tend to have the one objective that we don’t want to change the state of the object or we want to keep the class stateless.

A simple example could be that you want to load some master data at once and let the consumers of the data make a call to the Singleton class instead of each consumer making various calls by creating a new instance.

In general, in any complex enterprise application, Repository and Data Access Layer classes can be seen as a Singleton since typically we don’t want them to maintain the state in these layers.

Some other example could be cross-cutting concerns like Logging, Configuration, Caching and so forth that can also be implemented as a Singleton since we want a single and global point of access to these classes.

Apart from the core consideration explained above, I have seen that developers, mostly not so experienced sometimes, create unnecessarily instances that creates not just an overhead to memory but also impacts the overall performance of an application.

Why not Static classes?

There can be several reasons why to not use a static class however I can think of a few as follows.

  • There can be cases where you want to implement interfaces (maybe to implement IOC, I will explain IOC later) in a class that can be done in a Singleton implementation but not in the static one.
  • If required, you can use a singleton class as a method parameter whereas you cannot do that with a static class.

Special care for Singleton classes

We need to take special care for Singleton classes. The idea of a state of a class comes with some extra care that means we need to handle synchronization issues in multi-threaded environments.

Enough theory, now let’s talk about implementation.

Let’s have a look at the most basic implementation.

In the first example below, we have implemented a Singleton with Lazy loading since the instance will not be created until the caller calls the GetInstance method for the first time.

  • public class SingletonClass
  • {
  •     private static SingletonClass instance = null;
  •     private SingletonClass() {}
  •     public static SingletonClass GetInstance
  •     {
  •         get
  •         {
  •             if (instance == null)
  •             {
  •                 instance = new SingletonClass();
  •             }
  •             return instance;
  •         }
  •     }
  • }

Let’s try to fix the sync issue that may arise in multi-threaded environments. For this, we will use a double-lock mechanism.

  • public class SingletonClass
  • {
  •     private static SingletonClass instance = null;
  •     private static object lockMe = new object();
  •     private SingletonClass() {}
  •     public static SingletonClass GetInstance
  •     {
  •         get
  •         {
  •             if (instance == null)
  •             {
  •                 lock(lockMe)
  •                 {
  •                     if (instance == null)
  •                     {
  •                         instance = new SingletonClass();
  •                     }
  •                 }
  •             }
  •             return instance;
  •         }
  •     }
  • }

And in the last, Singleton with static initializations. Please note that the .NET Framework guarantees thread safety for static initialization so we don’t need extra care for sync issues however we may not get the benefit of lazy loading of objects here.

  • public class SingletonClass
  • {
  •     private static SingletonClass instance = new SingletonClass();
  •     private SingletonClass() {}
  •     public static SingletonClass GetInstance
  •     {
  •         get
  •         {
  •             return instance;
  •         }
  •     }
  • }

Conclusion:

In the article, we have gone through what singleton design pattern is, when it should be used and how it should be used.
I hope you will find this article useful. Look forward to your comments/suggestions.

Implicit and Explicit Interface Implementation using C#

Hello guys,

An interface in C# is usually used to create loosely-coupled and contract-based designs. It can contain signatures (declarations) of the Methods, Properties, Indexers and Events. The implementation of the methods/properties and so on is done in the class that implements the interface. An interface can inherit one or more interfaces, in other words it supports multiple inheritance whereas classes don’t.

Implicit interface implementation

This is the most regular or obvious way  to implement members of an interface. Here we don’t specify the interface name of the members and implement implicitly. The method can be declared at any interface (s) the class implements.
For example:
  • interface ITest
  • {
  •     void TestMethod();
  • }
  • class TestClass: ITest
  • {
  •     public void TestMethod()
  •     {
  •         Console.WriteLine(“Implicit Interface Implementation”);
  •     }
  • }
The call of the method is also not different. Just create an object of the class and invoke it.
  • class Program
  • {
  •     static void Main(string[] args)
  •     {
  •         TestClass obj = new TestClass();
  •         obj.TestMethod(); //Way to call implicitely implemented method
  •     }
  • }

Explicit interface implementation

This is another way to implement members of an interface. Here we need to specify the interface name of the members. The following example explains that.

  • class TestClass: ITest
  • {
  •     void ITest.TestMethod()
  •     {
  •         Console.WriteLine(“Explicit Interface Implementation”);
  •     }
  • }
The constraint with explicit implementation is that an explicitly implemented member cannot be accessed using a class instance, but only through an instance of the interface. Please have a look at the example below.
  • class Program
  • {
  •     static void Main(string[] args)
  •     {
  •     ITest obj2 = new TestClass();
  •         obj2.TestMethod();
  •     }
  • }
I hope you have liked the article. Please share your comments.