DEV Community: Aezan

Design Patterns Explained in C# & nopCommerce

Aezan — Wed, 21 Jan 2026 06:18:15 +0000

When we work on large applications, we often face similar problems again and again. Design patterns help us solve these recurring problems using proven and reusable approaches.

A design pattern is not a piece of code that you copy and paste. Instead, it is a general solution or idea that you can adapt to your own project based on its needs. You follow the concept of the pattern and implement it in a way that fits your application.

Types of Design Patterns

There are mainly three types of design patterns:

Creational patterns – focus on object creation
Structural patterns – focus on class and object composition
Behavioral patterns – focus on communication between objects

In real-world applications, these patterns are not used in isolation. They are often combined to build scalable and maintainable systems.

A good real-world example of this is nopCommerce.
nopCommerce uses many design patterns across different layers of its architecture.

In this article, I will explain common C# design patterns by showing how they are actually used inside nopCommerce.

nopCommerce is divided into three main layers:

Nop.Core
Nop.Data
Nop.Services

I’ll explain two design patterns from each layer.

Nop.Core

Nop.Core contains the core abstractions and infrastructure of nopCommerce.

Design patterns used:

Singleton Pattern
Observer Pattern

Singleton Pattern

The Singleton pattern is a creational design pattern that ensures a class has only one instance and provides a global access point to that instance.

Singleton in nopCommerce

In nopCommerce, there is a custom Singleton class. This implementation is slightly different from the classic GoF Singleton. It works more like a central registry for shared instances during the application’s lifetime.

Core Singleton Implementation

namespace Nop.Core.Infrastructure
{
    /// <summary>
    /// A statically compiled "singleton" used to store objects
    /// throughout the lifetime of the app domain.
    /// </summary>
    /// <typeparam name="T">The type of object to store.</typeparam>
    public partial class Singleton<T> : BaseSingleton
    {
        private static T instance;

        /// <summary>
        /// The singleton instance for the specified type T.
        /// </summary>
        public static T Instance
        {
            get => instance;
            set
            {
                instance = value;
                AllSingletons[typeof(T)] = value;
            }
        }
    }
}

How this works

Singleton stores a single instance of type T

The instance is stored in a static field

All singleton instances are tracked using a shared dictionary

This ensures one shared instance per type for the entire app domain

This approach gives nopCommerce a consistent and controlled way to manage shared objects across the system.

Observer Pattern

The Observer pattern is a behavioral design pattern that allows objects to subscribe to events and get notified automatically when something changes.

Observer in nopCommerce

nopCommerce uses the Observer pattern heavily through its event system. This is especially useful when entities are:

Inserted
Updated
Deleted

Instead of tightly coupling logic everywhere, nopCommerce publishes events and lets consumers react to them.

This keeps the code modular, decoupled, and maintainable.

Core Components of the Observer Pattern in nopCommerce

Events – represent something that happened

Event Publisher – publishes events

Event Consumers – handle the events

Example: Entity Deleted Event

namespace Nop.Core.Events
{
    public partial class EntityDeletedEvent<T> where T : BaseEntity
    {
        public EntityDeletedEvent(T entity)
        {
            Entity = entity;
        }

        public T Entity { get; }
    }
}

This event carries the deleted entity so consumers know exactly what was deleted.

nopCommerce also provides:

EntityInsertedEvent<T>

EntityUpdatedEvent<T>

Event Publisher Interface
namespace Nop.Core.Events
{
    public partial interface IEventPublisher
    {
        Task PublishAsync<TEvent>(TEvent @event);
        void Publish<TEvent>(TEvent @event);
    }
}

The publisher sends events to all subscribed consumers, either synchronously or asynchronously.

Nop.Data

Nop.Data is responsible for data access in nopCommerce.

Design patterns used:

Builder Pattern
Repository Pattern
Builder Pattern

The Builder pattern is a creational pattern that helps construct complex objects step by step. It allows different representations of an object using the same construction process.

Builder in nopCommerce

In nopCommerce, the Builder pattern is commonly used with FluentMigrator to define database schemas in a readable and structured way.

Example: BlogPostBuilder

using FluentMigrator.Builders.Create.Table;
using Nop.Core.Domain.Blogs;
using Nop.Core.Domain.Localization;
using Nop.Data.Extensions;

namespace Nop.Data.Mapping.Builders.Blogs
{
    /// <summary>
    /// Represents a blog post entity builder
    /// </summary>
    public partial class BlogPostBuilder : NopEntityBuilder<BlogPost>
    {
        public override void MapEntity(CreateTableExpressionBuilder table)
        {
            table
                .WithColumn(nameof(BlogPost.Title)).AsString(int.MaxValue).NotNullable()
                .WithColumn(nameof(BlogPost.Body)).AsString(int.MaxValue).NotNullable()
                .WithColumn(nameof(BlogPost.MetaKeywords)).AsString(400).Nullable()
                .WithColumn(nameof(BlogPost.MetaTitle)).AsString(400).Nullable()
                .WithColumn(nameof(BlogPost.LanguageId)).AsInt32().ForeignKey<Language>();
        }
    }
}

Why this is Builder Pattern

The object (table schema) is built step by step

Fluent syntax improves readability

The construction logic is separated from usage

This is a good example of Builder + Fluent Interface working together.

Repository Pattern

The Repository pattern abstracts data access logic and provides a clean API for the business layer.

In nopCommerce, repositories:

Hide database details

Improve testability

Promote separation of concerns

Repositories are commonly used with:

Dependency Injection
Unit of Work
Service Layer

Example: Repository Used Inside a Service

public partial class BlogService : IBlogService
{
    private readonly IRepository<BlogComment> _blogCommentRepository;
    private readonly IRepository<BlogPost> _blogPostRepository;

    public BlogService(
        IRepository<BlogComment> blogCommentRepository,
        IRepository<BlogPost> blogPostRepository)
    {
        _blogCommentRepository = blogCommentRepository;
        _blogPostRepository = blogPostRepository;
    }

    public virtual async Task DeleteBlogPostAsync(BlogPost blogPost)
    {
        await _blogPostRepository.DeleteAsync(blogPost);
    }
}

Here:

Repository handles data access

Service handles business logic

Nop.Services

Nop.Services contains the business logic layer.

Design patterns used:

Service Pattern
Dependency Injection Pattern
Service Pattern

The Service pattern organizes business logic and acts as a bridge between:

Presentation layer

Data access layer

This makes the application:

Easier to maintain

Easier to test

Easier to understand

Service Interface and Implementation

public partial interface IBlogService
{
    Task DeleteBlogPostAsync(BlogPost blogPost);
    Task<BlogPost> GetBlogPostByIdAsync(int blogPostId);
}

public partial class BlogService : IBlogService
{
    private readonly IRepository<BlogPost> _blogPostRepository;

    public BlogService(IRepository<BlogPost> blogPostRepository)
    {
        _blogPostRepository = blogPostRepository;
    }

    public async Task DeleteBlogPostAsync(BlogPost blogPost)
    {
        await _blogPostRepository.DeleteAsync(blogPost);
    }

    public async Task<BlogPost> GetBlogPostByIdAsync(int blogPostId)
    {
        return await _blogPostRepository.GetByIdAsync(blogPostId, cache => default);
    }
}

The service defines what the system can do, while repositories handle how data is accessed.

Dependency Injection Pattern

Dependency Injection (DI) is used everywhere in nopCommerce.

Instead of creating dependencies manually, they are injected through constructors.

public partial class BlogService : IBlogService
{
    private readonly IRepository<BlogPost> _blogPostRepository;

    public BlogService(IRepository<BlogPost> blogPostRepository)
    {
        _blogPostRepository = blogPostRepository;
    }
}

Benefits of DI

Loose coupling
Easier unit testing
Better maintainability
Cleaner architecture

nopCommerce uses DI in:

Services
Factories
Controllers
Repositories

Disadvantages of Design Patterns

While design patterns are powerful, they are not always the best solution.

Common disadvantages

Complexity – can make code harder to understand

Learning curve – requires solid understanding

Overengineering – patterns used where simple code is enough

Rigidity – may reduce flexibility

Increased development time – more planning and structure

Misapplication – wrong pattern causes bad architecture

Dependency complexity – harder to refactor

Documentation overhead – patterns must be well documented

Design patterns should be used as tools, not rules.

Conclusion

nopCommerce is a great real-world example of how C# design patterns are used in production systems.

Patterns like:

Singleton
Observer
Builder
Repository
Service
Dependency Injection

help keep the codebase scalable, testable, and maintainable.

The key lesson is not to use patterns everywhere, but to use them when they actually solve a problem.

Thanks for reading!
You can find me on GitHub
and LinkedIn

I Created an MCP Server and Why I Think MCP is Overrated

Aezan — Fri, 07 Nov 2025 07:42:45 +0000

Sometime ago, I created an MCP server with C#. It was just a basic project I was trying to learn how MCP works, and I followed this Microsoft blog
to get started. At that time, MCP was booming, and I wanted to explore AI development using my favorite language, C#. So, I decided to create a simple Google Sheets MCP integration just to see how it works.

This blog is not a step-by-step tutorial on how to create an MCP server, but more about what I think of MCP after building one.
So, MCP or Model Context Protocol is an open-source protocol that allows you to expose your methods and functions to AI agents. Basically, it lets the AI directly access your code or functions. That’s why developers get excited about it: it feels like connecting your codebase directly to an intelligent assistant.

Now, about why I don’t really love MCP. I don’t hate it — it’s just “okay” for me. AI is powerful, but it’s still not fully accurate or secure. If you’ve worked with AI before, you know how easily it gets confused or stuck repeating the same thing. MCP depends heavily on natural language, which makes it even more unreliable in real use cases.

For example, let’s say you build a simple MCP tool that just adds two numbers. When you connect your AI agent and ask, “Can you add 1 + 1?”, there’s a high chance the AI will just respond with “2” directly instead of calling your MCP tool — unless you explicitly tell it to use the tool. That’s the issue: MCP sounds great in theory but doesn’t always behave as expected in real workflows. It’s more suited for AI coding experiments or vibe coding sessions rather than serious projects where you’re writing the logic yourself.

Another thing I noticed while experimenting is that MCP feels more like a bridge technology something that fills the gap between AI tools and real-world codebases, but not something most developers actually need daily. It looks impressive in demos, but when you implement it, you realize it doesn’t really solve a new problem; it just repackages an old one with a different label.

I also think the hype around MCP mostly comes from how Big Tech markets it rather than how developers use it. Everyone loves to say “AI agents can now run your code,” but in practice, 90% of the time it’s faster and safer to just expose an API or run a script yourself. MCP adds another layer that looks fancy but doesn’t necessarily improve your workflow. There are also more developers building MCP tools than actual users. It’s mostly used by vibe coders or enthusiasts rather than everyday developers writing real-world code. People love the idea of AI and anything with “AI” in it gets instant hype but that doesn’t mean it’s always practical.

That said, I still respect the idea behind MCP. It’s a good step toward standardizing how AI tools interact with software, and I can see it becoming useful once AI models get more consistent and reliable. Maybe in the future, MCP will make more sense but for now, it feels more like a presentation feature than a production feature.

Thanks for reading!
You can find me on GitHub
and LinkedIn

I Created a BitTorrent Client with Blazor and c#

Aezan — Sun, 03 Aug 2025 07:27:43 +0000

Some time ago I completed the CodeCrafters BitTorrent challenge, and after that I rewrote the torrent client in Blazor to understand it more deeply and also as a portfolio project. So I chose Blazor rather than going with .NET MVC.

I took on this project to enhance my C# skills and logic, and I learned more about how cryptography works, networking, TCP handshake, and obviously how BitTorrent files work.

This article isn’t a deep dive, but rather a quick overview of how I built the BitTorrent client and how it works under the hood.

1. BitTorrent Encoding

BitTorrent files are decoded using bencoding, and you have to decode this format to get the file contents. Bencoding supports 4 types, and they are encoded like below:



Integers are encoded as i<base10 integer>e.
Zero is encoded as i0e.

Byte Strings are encoded as <length>:<contents>.
The length is the number of bytes in the string, encoded in base 10.
A colon (:) separates the length and the contents.
The string "bencode" is encoded as 7:bencode.

Lists are encoded as l<elements>e.
A list containing the string "bencode" and the integer -20 is encoded as l7:bencodei-20ee.

Dictionaries are encoded as d<pairs>e.
A dictionary with keys "wiki" ? "bencode" and "meaning" ? 42 is encoded as d7:meaningi42e4:wiki7:bencodee.

2. BitTorrent File Content

A BitTorrent file contains a dictionary with keys like:

announce
announce-list
comment
created by
creation date
encoding
info

What we mainly need is the info dictionary, because inside that the pieces we will download are stored.

3. Peers

We use peers to download the file. To find peers, we use the tracker available in the announce dictionary field. We read the tracker URL from announce and send a GET request there, and in the response we get the list of available peers, including their IP and port. Then we use those peers to download the pieces.

We can also use just one peer to download, but it is recommended to use multiple peers in parallel to improve speed. There are many dead peers as well as slow peers, so we should make sure the peer is working properly and that we are using the right peers.

4. TCP Handshake

BitTorrent uses TCP to make the communication between client and peer. We make the connection with the peer, and after a successful handshake the peer will return messages like bitfield, unchoke, etc. Then we have to send messages like interested or request any specific piece to download.

If somehow a piece is not downloaded, you can make a download piece later queue with the piece index, and then request all the pieces again with a new peer or try again with the same peer (I have to implement this too 💀).

5. Download File

Now you have successfully established the connection with the peer. What you have to do next is download the file in BitTorrent, but it is not that simple. There are many things you have to take care of, like making sure you got the piece data correctly by comparing it with the expected piece data from the info dictionary.

You have to match that, and as I wrote before you have to make sure you are using multi-peer downloading and properly assign each peer to each piece.

If you got this far, pray that your file was not corrupt or a pending piece, otherwise all your hard work is useless.

Anyway, this is just my learning project to increase my skills, and I think it helped me a lot no doubt, but it was not too easy. This post is not about the full details or how the code works, but just about the under-the-hood process of how it works.

✨ Here’s the full source code on GitHub if you want to take a look.