Coder Legion - Recent posts tagged entity

SEO is Dead. Entity Engineering is the Successor. Your 2026 Roadmap

Tue, 23 Dec 2025 10:31:28 +0000

Welcome to the Backlink Graveyard
Let’s face a painful truth: most of you are wasting your time on graveyard technology.

If you’re still chasing keywords, building links using 2020 tactics, or celebrating "Meta Tag optimization" you aren’t a search professional; you’re an archaeologist. Welcome to January 2026: a world where Google has ceased to be a "Search Engine" and has evolved into an AI-driven Inference Engine.

After 17 years in this industry, I’ve seen SEO die and be reborn a dozen times, but this shift is tectonic. Traditional SEO hasn't just changed; it has been replaced. Google 2026 doesn't crawl pages to find strings of text; it analyzes your existence as an Entity. If your brand isn't hard-coded into Google’s Knowledge Graph, you simply don't exist—no matter how clean your code is or how fast your site loads.

In this article, I’m going to aggravate the "marketing gurus" by explaining why your backlinks are now nothing more than white noise. I will reveal the new roadmap—Entity Engineering—the only remaining way to force Google’s AI to choose you, not just rank you.

The Elite Consensus: The SEO "Avengers" are Already There
I’m not the only one seeing the writing on the wall. When we look at the 2026 forecasts from the world’s top minds, the signal is clear:

Authority is the New Currency: Experts like Lily Ray and Barry Adams have been warning us: without E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) embedded at the Entity level, Google’s AI will ignore you. While many view E-E-A-T as a content signal, at FayzakSEO, we treat it as a Database Signal. If your authority isn't machine-readable, it’s invisible.

The Knowledge Graph Pivot: Technical visionaries like Andrea Volpini and Cindy Krum are proving that the future belongs to those who build Private Knowledge Graphs and bridge them directly to Google.

Context Over Strings: Dawn Anderson, one of the brightest minds in Information Retrieval, explains that algorithms have moved toward deep semantic understanding—they seek Context, not String Matching.

When you synthesize the predictions of Neil Patel, Kevin Indig, or Aleyda Solis, they all point North. But while they talk about the "What," my 17 years in the trenches of code allow me to show you the "How."

The 2026 Roadmap: From SEO to Entity Engineering
To survive 2026, you must stop thinking like a marketer and start thinking like a Data Engineer. Here is your roadmap:

Identity Validation: Google doesn’t trust what you say about yourself. In 2026, you need "Cross-Reference Proof." This means aggressive use of Schema Markup (JSON-LD) to link your brand to verified external entities in Google’s Knowledge Vault (Wikidata, social profiles, and authoritative publications).

Semantic Architecture: No more isolated "pages." In 2026, we build Topic Clusters that feed into each other. Every piece of code must declare the logical relationships between the entities on your site.

Structured Data Injection: Schema is no longer a "nice-to-have." It is your digital ID. Structured data has become a language that AI understands better than prose. If your JSON-LD doesn't describe the connections between Author, Organization, and Content, Google’s AI won't know how to package you as an answer in SGE (Search Generative Experience).

Engineering an Entity: The Technical Deep-Dive
To win, you must implement the Triple-Layer Entity Framework:

The Validation Layer: Nested Schema & Dynamic SameAs
Don't settle for basic Article Schema. In 2026, we use Nested Entities. Technical Example: If you are writing about Technical SEO, your JSON-LD must declare a mainEntity and use sameAs to link to the exact entity on Wikidata (e.g., Q11061). You stop being a "webpage" and become a "verified concept."

The 17-Year Pro Tip: Use the mentions and about properties within your code to reduce Semantic Distance between your brand and core industry nodes. The smaller the semantic distance in Google’s graph, the higher your perceived authority.

Vector Space Architecture (Forget Keywords)
In 2026, Gemini and other LLMs don't see words; they see Vector Embeddings in a multi-dimensional space. Instead of matching keywords, we match meanings. Entity Engineering ensures your content is positioned in the correct vector. By surrounding your core content with complementary concepts (Co-occurrence) like "Latent Semantic Indexing" and "Natural Language Processing," you prevent AI Hallucinations and force the engine to classify you as a high-confidence source.
The Private Knowledge Graph (PKG)
The future is building a structured data repository within your own site that Google can "ingest" hierarchically. This data structure defines the relationship between the Person (Author), the Organization, and the Knowledge (Service/Product). In 2026, Google doesn't "crawl" you—it performs an API Integration via your structured data.

The Final Seal: John Mueller and the Search Console Prophecy
For those still seeking official "permission" from Google, listen closely to John Mueller. Mueller has already admitted that backlinks are losing their weight as a primary signal.

But here is the real bombshell: Google has hinted that soon, we will see our Entity Relationship Map within Search Console. Not just who linked to us, but how Google perceives our position within the global Knowledge Graph. In 2026, the winners will be those who prepared this infrastructure in advance. Those who didn't just "do SEO," but engineered Authority.

My Bottom Line
After 17 years in the guts of the web, I can tell you with certainty: technologies change, but principles remain. Google has always searched for the most trusted source. In 2026, trust is measured in code, data, and entities.

The question isn't where you will rank; the question is: Will Google’s AI even recognize that you exist?

About the Author: Izzik Fayzak is a Search Architect and Technical SEO expert with over 17 years of experience. He is the founder of FayzakSEO, a boutique firm specializing in Entity Engineering and advanced search strategies for the AI era. Discover more technical deep-dives at: [fayzakseo.com]

EF Core Interceptors: Supercharge Your Data Access with the Decorator Pattern

Thu, 20 Mar 2025 08:25:11 +0000

Learn how to hook into EF Core operations using interceptors, leverage the Decorator Pattern for clean cross-cutting concerns, and see real-world examples like SQL logging and auditing.

Table of Contents

A Brief History of EF Core Interceptors
What Are EF Core Interceptors?
EF Core Interceptors and the Decorator Pattern
Top Use Cases for EF Core Interceptors
Example 1: Logging SQL Queries
Example 2: Auditing SaveChanges
Final Thoughts

A Brief History of EF Core Interceptors

EF Core interceptors were first introduced in EF Core 3.0 (released in September 2019). This version marked a significant step forward in EF Core's extensibility, allowing developers to intercept low-level database operations like commands, connections, and transactions.

Since then, Microsoft has expanded interceptor capabilities in newer versions:

EF Core 5.0: Introduced SaveChanges interceptors for tracking changes at the context level.

EF Core 6.0+: Continued performance improvements and better support for asynchronous interception.

What Are EF Core Interceptors?

In Entity Framework Core (EF Core), interceptors allow developers to hook into the execution pipeline of EF Core's operations. Think of them as middleware for your database interactions. You can intercept events such as:

SQL command execution
Connection opening/closing
Transactions
SaveChanges lifecycle

This lets you inject custom logic like logging, auditing, validation, or performance metrics without modifying your application’s core logic.

EF Core Interceptors and the Decorator Pattern

EF Core interceptors are a real-world application of the Decorator Pattern, a classic design pattern where functionality is wrapped around existing behavior to extend or alter it.

The core EF operation is the base object.
Your interceptor is the decorator.
You add behavior before or after EF Core’s operation — without altering EF’s core.

This approach promotes clean code, separation of concerns, and makes your custom behavior reusable and testable.

Top Use Cases for EF Core Interceptors

– SQL Query Logging

– Track database queries for performance or debugging.

– Auditing – Automatically log user actions and timestamps.

– Soft Deletes – Intercept delete commands and convert them to updates.

– Command Modification – Change or enrich raw SQL before execution.

– Multi-Tenant Filtering – Inject filters dynamically for multi-tenant scenarios.

Example 1: Logging SQL Queries

Let’s log every SQL command executed by EF Core.

Step 1: Create a SQL Logging Interceptor

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Diagnostics;

public class SqlLoggingInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, 
        CommandEventData eventData, 
        InterceptionResult<DbDataReader> result)
    {
        Debug.WriteLine($"SQL Executed: {command.CommandText}");
        return base.ReaderExecuting(command, eventData, result);
    }
}

Output:

SQL Executed: SELECT * FROM [Users] WHERE [IsActive] = 1

Step 2: Register the Interceptor

public class AppDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder
            .UseSqlServer("YourConnectionString")
            .AddInterceptors(new SqlLoggingInterceptor());
    }
}

Example 2: Auditing SaveChanges

Let’s implement automatic auditing of entity modifications.

Step 1: Define an Auditable Entity Base Class

public abstract class AuditableEntity
{
    public DateTime ModifiedAt { get; set; }
    public string ModifiedBy { get; set; }
}

Step 2: Implement a SaveChangesInterceptor

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly string _currentUser;

    public AuditInterceptor(string currentUser)
    {
        _currentUser = currentUser;
    }

    public override int SavingChanges(DbContextEventData eventData, int result)
    {
        var context = eventData.Context;
        if (context == null) return base.SavingChanges(eventData, result);

        var entries = context.ChangeTracker
            .Entries<AuditableEntity>()
            .Where(e => e.State == EntityState.Modified);

        foreach (var entry in entries)
        {
            entry.Entity.ModifiedAt = DateTime.UtcNow;
            entry.Entity.ModifiedBy = _currentUser;
        }

        return base.SavingChanges(eventData, result);
    }
}

Final Thoughts

EF Core interceptors are an underutilized gem in the .NET ecosystem. They let you cleanly implement cross-cutting concerns without muddying your core application code. And because they follow the Decorator Pattern, you get flexibility, maintainability, and testability.

Whether you need to log queries, audit changes, enforce soft deletes, or handle custom behavior, interceptors offer a powerful and elegant solution.

References
EF Core Documentation – Interceptors
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors

EF Core 3.0 Release Notes (Interceptors introduced)
https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-3.0/whatsnew

EF Core SaveChanges Interceptor Docs
https://learn.microsoft.com/en-us/ef/core/logging-events-diagnostics/interceptors#savechanges-interception

Decorator Pattern - Refactoring Guru (for pattern explanation)
https://refactoring.guru/design-patterns/decorator

EF Core GitHub Repository (for latest updates and issues)
https://github.com/dotnet/efcore