FAQ

Middleware Vs Filters:

The execution of request starts and we have a middleware, and another middleware, and eventually the routing middleware kicks in and then request goes into the MVC pipline.

So if you don’t require the context of MVC (let’s say you’re concerned about flow and execution, like responding to headers some pre-routing mechanism, etc.) then use middlewares.
But if you require the context of MVC and you want to operate against actions then use filters.

The main difference between them is their scope. Filters are a part of MVC, so they are scoped entirely to the MVC middleware. Middleware only has access to the HttpContext and anything added by preceding middleware. In contrast, filters have access to the wider MVC context, so can access routing data and model binding information for example.

Generally speaking, if you have a cross cutting concern that is independent of MVC then using middleware makes sense, if your cross cutting concern relies on MVC concepts, or must run midway through the MVC pipeline, then filters make sense.

MVC pipeline:

Docker:

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications.

Abstract Class Vs. Interface use case scenarios:

USE AN ABSTRACT CLASS
1). When creating a class library which will be widely distributed or reused — especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)
2). Use an abstract class to define a common base class for a family of types.
3). Use an abstract class to provide default behavior.
4). Subclass only a base class in a hierarchy to which the class logically belongs.

USE AN INTERFACE
1). When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.
2). Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance — allowing a specific type to support numerous behaviors.
3). Use an interface to design a polymorphic hierarchy for value types.
4). Use an interface when an immutable contract is really intended.
5). A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.

Factory Design pattern use case scenarios:

The factory design pattern in C# is used to replace class constructors, abstracting the process of object generation so that the type of the object instantiated can be determined at run-time.

The Factory Method pattern is generally used in the following situations:

· A class cannot anticipate the type of objects it needs to create beforehand.

· A class requires its subclasses to specify the objects it creates.

· You want to localize the logic to instantiate a complex object.

Singleton VS Transient Vs Scope:

• Same Instance

A singleton is an instance that will last the entire lifetime of the application. In web terms, it means that after the initial request of the service, every subsequent request will use the same instance. This also means it spans across web requests (So if two different users hit your website, the code still uses the same instance). The easiest way to think of a singleton is if you had a static variable in a class, it is a single value across multiple instances.

Using our example from above :

public void ConfigureServices(IServiceCollection services)
{
	services.AddSingleton<IMyService, MyService>();
	var serviceProvider = services.BuildServiceProvider();
	var instanceOne = serviceProvider.GetService<IMyService>();
	var instanceTwo = serviceProvider.GetService<IMyService>();
	Debug.Assert(instanceOne != instanceTwo);
}

We are now adding our service as a singleton and our Assert statement from before now blows up because the two instances are actually the same!

Transient services are created every time they are injected or requested. Scoped services are created per scope.

Scoped lifetime objects often get simplified down to “one instance per web request”. you can think of scoped objects being per web request. So common things you might see is a DBContext being created once per web request.

IEnumerable Vs. IEnumerator :

if you want to loop sequentially through the collection, use an IEnumerable interface else if you want to retain the cursor position and want to pass it from one function to another function then use an IEnumerator interface.

IEnumerable Vs. IQueryable :

The main difference between “IEnumerable” and “IQueryable” is about where the filter logic is executed. One executes on the client side (in memory) and the other executes on the database.

So when you have to simply iterate through the in-memory collection, use IEnumerable, if you need to do any manipulation with the collection like Dataset and other data sources, use IQueryable

Inject the service dependency into the controller:

There are three easy steps to add custom service as a dependency on the controller.

Step 1: Create the service

public interface IHelloWorldService

{

string SaysHello();

}

public class HelloWorldService: IHelloWorldService

{

public string SaysHello()

{

return “Hello “;

}

}

Step 2: Add this service to Service container (service can either added by singleton, transient or scoped)

public void ConfigureServices(IServiceCollection services)

{

….

…

services.AddTransient<IHelloWorldService, HelloWorldService>();

…

…

}

Step 3: Use this service as a dependency in the controller

public class HomeController: Controller

{

IHelloWorldService _helloWorldService;

public HomeController(IHelloWorldService helloWorldService)

{

_helloWorldService = helloWorldService;

}

}

Dictionary Vs HashTable

1. Dictionary is generic type Dictionary<TKey,TValue>
2. Dictionary class is a strong type < TKey,TValue > Hence, you must specify the data types for key and value.
3. There is no need of boxing/unboxing.
4. When you try to access non existing key dictionary, it gives runtime error.
5. Dictionary maintains an order of the stored values.
6. There is no need of boxing/unboxing, so it is faster than Hashtable.

Hashtable

1. Hashtable is non-generic type.
2. Hashtable is a weakly typed data structure, so you can add keys and values of any object type.
3. Values need to have boxing/unboxing.
4. When you try to access non existing key Hashtable, it gives null values.
5. Hashtable never maintains an order of the stored values.
6. Hashtable needs boxing/unboxing, so it is slower than Dictionary.