Sanju-Blogs

The article below describes the behavior of the Singleton design pattern as an anti-pattern, where it violates the basic principle of creating a single object. We all are very much aware of Singletons, one of the main Creational Design Patterns. It's a very widely and commonly used Design Pattern. Most of you are aware of the advantages and the problems solved by the pattern, but I am not going to deal with those features in this article. What most of us fail to understand is that in most of the cases, the Singleton is misused and acts as an anti-pattern. So let's try to look at the scenarios where the Singleton design pattern works as an anti-pattern. ·          Singletons are basically used as global variables. Using global variables is an enemy of encapsulation because it becomes difficult to define pre- and post-conditions for the client’s object interface. The working of the interface can be handled from within, and not from...

Repository Pattern separates the data access logic and maps it to the entities in the business logic. It works with the domain entities and performs data access logic. In the Repository pattern, the domain entities, the data access logic and the business logic talk to each other using interfaces. It hides the details of data access from the business logic. In other words, business logic can access the data object without having knowledge of the underlying data access architecture . For example, in the Repository pattern, business logic is not aware whether the application is using LINQ to SQL or ADO.NET Entity Model ORM. In the future, underlying data sources or architecture can be changed without affecting the business logic. There are various advantages of the Repository Pattern including: Business logic can be tested without need for an external source Database access logic can be tested separately No duplication of code Caching strategy for the datasource can be centraliz...

Everyone is talking about one of the latest technologies called 'Elasticsearch'. Then some of the questions comes to my mind; - What is it, is it a database - Basics of Elasticsearch - How it runs - What it does - How to use - What are the dependencies Below I will explain my understanding and is to refer for myself as needed :-) ES is a document-oriented database designed to store, retrieve, and manage document-oriented or semi-structured data. When you use Elasticsearch, you store data in JSON document form. Then, you query them for retrieval. It is schema-less, using some defaults to index the data unless you provide mapping as per your needs. Elasticsearch uses Lucene StandardAnalyzer for indexing for automatic type guessing and for high precision. Every feature of Elasticsearch is exposed as a REST API: Index API: Used to document the index. Get API: Used to retrieve the document. Search API: Used to submit your query and get a result. Put Mapping AP...

Yesterday evening in a casual talk I was discussing some technologies, I came across a new Pattern to me called 'Saga Pattern". Then I went through in the night and thought of putting across my understandings for my reference. This pattern mainly supported for Microservice implementations. If you are about to implement Microservices that implements a transaction that spans multiple services, this Saga pattern help you to solve the problem you face. If you are building a Travel booking App using Microservices; In the above diagram, a high-level business action (‘Booking a trip’) involves making several low-level actions to distinct microservices. To handle client requests, we create a single-purpose edge service (a Backend for Frontend) that provides the logic of composing calls to all the downstream services. At its core, the Travel Orchestrater - Travel Agent Service exposes APIs by composing core functionality provided by different Microservices. We all know t...

The 1st question comes to my mind when I hear about another new webserver like IIS for .NET applications. Why do we need this new webserver called 'Kestrel'? As we all know Asp.Net Core is primarily to make Asp.Net Core applications to run across multiple platforms (Windows/Unix/Linux/MAC OS). Even though we have IIS with rich in features but mostly used webserver for Windows OS only. Each webserver has a different configurations expected to startup and Kestrel will make Asp.Net Core applications have different Startup mechanisms. This is why Asp.Net Core applications use Kestrel webserver as an in-process server where the application will have same and consistent Startup (Main() and Startup.ConfigireServices() & Startup.Configure()) process even when offering cross platform support. Kestrel is an open source, cross platform, light weight and a default webserver used for Asp.Net Core applications. Asp.Net Core applications run Kestrel webserver as in-process server to ...

if your project requires references that are 32-bit or 64-bit specific (i.e. COM-interop assemblies), and you have no interest in manually editing the .csproj file, then you'll have to create separate 32-bit and 64-bit projects. Note that the following solution is should work. If you are willing to manually edit the .csproj file, then you should be able to achieve the desired result with a single project. The .csproj file is just an MSBuild script, so for a full reference, look here. Once you open the .csproj file in an editor, locate the elements. You should be able to split these elements out in to 3 distinct item groups: references that aren't platform specific, x86-specific references, and x64-specific references. Now when you set your project/solution build configuration to target the x86 or x64 platform, it should include the proper references in each case. Of course, you'll need to play around with the elements. You could even setup dummy projects where ...