Forem: nikosst

Strategy Pattern Θεωρία, Χρήση και Πρακτική Εφαρμογή

nikosst — Thu, 30 Apr 2026 13:38:11 +0000

Τι είναι τα Design Patterns και γιατί υπάρχουν

Τα design patterns δεν είναι “μαγικές συνταγές”. Είναι δοκιμασμένες λύσεις σε επαναλαμβανόμενα προβλήματα σχεδιασμού λογισμικού. Προέκυψαν γιατί οι προγραμματιστές αντιμετωπίζουν ξανά και ξανά τα ίδια αρχιτεκτονικά διλήμματα: ευελιξία, επεκτασιμότητα, καθαρός διαχωρισμός ευθυνών.

Το βασικό τους όφελος:

Μειώνουν την πολυπλοκότητα
Αυξάνουν τη συντηρησιμότητα
Δημιουργούν κοινή “γλώσσα” μεταξύ developers

Το Strategy Pattern ανήκει στα behavioral patterns και ασχολείται με το πώς αλλάζει η συμπεριφορά ενός αντικειμένου δυναμικά.

Τι είναι το Strategy Pattern

Το Strategy Pattern επιτρέπει να ορίζεις μια οικογένεια αλγορίθμων, να τους ενθυλακώνεις (encapsulate) και να τους κάνεις εναλλάξιμους.

Με απλά λόγια:
Αν έχεις πολλές διαφορετικές “στρατηγικές” για να κάνεις το ίδιο πράγμα, δεν γράφεις if/else παντού αλλά τις απομονώνεις.

Το πρόβλημα που λύνει

Φαντάσου αυτό:

if(type == "credit")
    PayWithCredit();
else if(type == "paypal")
    PayWithPaypal();
else if(type == "crypto")
    PayWithCrypto();

Προβλήματα:

Παραβίαση του Open/Closed Principle
Δύσκολη συντήρηση
Δύσκολο testing
Κακή επεκτασιμότητα

Η ιδέα του Strategy Pattern

Αντί να έχεις conditional logic, κάνεις:

“Δίνω” στο αντικείμενο μια στρατηγική και αυτό τη χρησιμοποιεί.

Δομή

Το pattern έχει 3 βασικά μέρη:

Strategy Interface
Concrete Strategies
Context

Παράδειγμα σε C#

Strategy Interface

public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

Concrete Strategies

public class CreditCardPayment : IPaymentStrategy
{
    public void Pay(decimal amount)
    {
        Console.WriteLine($"Paid {amount} with Credit Card");
    }
}

public class PaypalPayment : IPaymentStrategy
{
    public void Pay(decimal amount)
    {
        Console.WriteLine($"Paid {amount} with PayPal");
    }
}

Context

public class PaymentContext
{
    private IPaymentStrategy _strategy;

    public PaymentContext(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }

    public void SetStrategy(IPaymentStrategy strategy)
    {
        _strategy = strategy;
    }

    public void ExecutePayment(decimal amount)
    {
        _strategy.Pay(amount);
    }
}

Χρήση

var context = new PaymentContext(new CreditCardPayment());
context.ExecutePayment(100);

context.SetStrategy(new PaypalPayment());
context.ExecutePayment(200);

Γιατί να το χρησιμοποιήσεις

Καθαρός Κώδικας

Δεν έχεις if/else παντού.

Open/Closed Principle

Προσθέτεις νέα στρατηγική χωρίς να αλλάξεις υπάρχοντα κώδικα.

Testability

Κάθε στρατηγική μπορεί να γίνει unit test ανεξάρτητα.

Επαναχρησιμοποίηση

Οι στρατηγικές είναι plug-and-play.

Runtime ευελιξία

Αλλάζεις συμπεριφορά δυναμικά.

Πότε να το χρησιμοποιήσεις

✔ Όταν έχεις πολλές παραλλαγές μιας λειτουργίας
✔ Όταν βλέπεις πολλά if/else ή switch
✔ Όταν θέλεις να αλλάζεις behavior στο runtime
✔ Όταν θέλεις καθαρή αρχιτεκτονική

Πότε ΔΕΝ χρειάζεται

❌ Όταν έχεις 1-2 απλές επιλογές
❌ Όταν προσθέτει άσκοπη πολυπλοκότητα
❌ Όταν δεν υπάρχει πιθανότητα επέκτασης

Real-world παραδείγματα

Payment systems (PayPal, Stripe, Crypto)
Compression algorithms (zip, rar)
Sorting strategies
Authentication methods

Strategy Pattern σε συνδυασμό με Dependency Injection

Γιατί να το συνδυάσεις με DI

Το Strategy Pattern από μόνο του λύνει το πρόβλημα των if/else.
Αλλά αν κάνεις αυτό:

var context = new PaymentContext(new CreditCardPayment());

έχεις ακόμα ένα πρόβλημα:

Ο κώδικας σου γνωρίζει τις υλοποιήσεις (concrete classes)

Αυτό σημαίνει:

Tight coupling
Δύσκολο testing (χωρίς mocking εύκολα)
Παραβίαση του Dependency Inversion Principle

Τι σου δίνει το Dependency Injection

Με DI:

Δεν δημιουργείς αντικείμενα στα δίνει το framework
Δουλεύεις με interfaces
Μπορείς να αλλάξεις behavior χωρίς να πειράξεις business logic

Με απλά λόγια:

Το Strategy Pattern βρίσκει πώς να αλλάξει behavior
Το DI αποφασίζει ποιο behavior θα χρησιμοποιηθεί

Παράδειγμα σε ASP.NET Core

var builder = WebApplication.CreateBuilder(args);

// Register strategies
builder.Services.AddScoped<IPaymentStrategy, CreditCardPayment>();
builder.Services.AddScoped<IPaymentStrategy, PaypalPayment>();

// Register context & service
builder.Services.AddScoped<PaymentContext>();
builder.Services.AddScoped<PaymentService>();

var app = builder.Build();

Service που χρησιμοποιεί το Strategy Pattern

public class PaymentService
{
    private readonly PaymentContext _context;

    public PaymentService(PaymentContext context)
    {
        _context = context;
    }

    public void Pay(string type, decimal amount)
    {
        _context.ExecutePayment(type, amount);
    }
}

Παράδειγμα χρήσης (π.χ. σε Controller ή minimal API)

app.MapPost("/pay", (PaymentService service, string type, decimal amount) =>
{
    service.Pay(type, amount);
    return Results.Ok("Payment completed");
});

Request παραδείγματα

POST /pay?type=credit&amount=100
POST /pay?type=paypal&amount=200

Το DI δίνει όλες τις στρατηγικές
Το PaymentContext επιλέγει σωστή με βάση το type
Το PaymentService δεν ξέρει τίποτα για implementations
Μηδέν if/else, full extensibility

Αν τώρα προσθέσεις:

public class CryptoPayment : IPaymentStrategy
{
    public string Key => "crypto";

    public void Pay(decimal amount)
    {
        Console.WriteLine($"Paid {amount} with Crypto");
    }
}

και κάνεις:

builder.Services.AddScoped<IPaymentStrategy, CryptoPayment>();

Να θυμάσαι..

Το Strategy Pattern είναι ένα από τα πιο χρήσιμα patterns γιατί:

Διαχωρίζει το τι κάνεις από το πώς το κάνεις
Σου δίνει ελευθερία να αλλάζεις behavior χωρίς να “σπας” τον κώδικα
Σε φέρνει πιο κοντά σε καθαρή αρχιτεκτονική (clean architecture)

Το Strategy Pattern μόνο του είναι καλό.

Με Dependency Injection γίνεται enterprise-grade εργαλείο.

Σου δίνει:

ευελιξία
επεκτασιμότητα
καθαρότητα
testability

nikosstit@gmail.com

Architecture Layers, Security Boundaries και Best Practices

nikosst — Wed, 29 Apr 2026 14:22:03 +0000

Κάθε API που εκτίθεται στο διαδίκτυο δέχεται δεδομένα από πηγές που δεν ελέγχει πλήρως. Για παράδειγμα, ένα απλό JSON endpoint που περιμένει λίγα KB μπορεί να δεχτεί ένα payload δεκάδων MB. Αν αυτό το request φτάσει μέχρι το parsing ή το model binding, το σύστημα έχει ήδη πληρώσει κόστος σε μνήμη και CPU. Αυτό σημαίνει ότι το σύστημα πρέπει να είναι προετοιμασμένο όχι μόνο για “σωστά” requests, αλλά και για:

λανθασμένα payloads
υπερβολικά μεγάλα δεδομένα
κακόβουλη χρήση

Ένα από τα βασικά εργαλεία για την αντιμετώπιση αυτών των περιπτώσεων είναι τα request size limits.

Δεν πρόκειται για απλή ρύθμιση. Είναι μηχανισμός προστασίας που πρέπει να τοποθετηθεί σωστά στην αρχιτεκτονική.

Η ανάγκη για όρια

Αν δεν υπάρχει κανένα όριο στο μέγεθος ενός request, το σύστημα εκτίθεται σε πραγματικά προβλήματα.

Πρώτον, υπάρχει ο κίνδυνος εξάντλησης πόρων. Ένα μεγάλο request μπορεί να καταναλώσει μνήμη και CPU, ειδικά όταν πρόκειται για JSON που πρέπει να γίνει parsing ή για αρχεία που πρέπει να διαβαστούν.

Δεύτερον, υπάρχει ο κίνδυνος επιθέσεων. Ένα API χωρίς limits μπορεί να δεχτεί συνεχόμενα μεγάλα requests και να οδηγηθεί σε κατάσταση όπου δεν μπορεί να εξυπηρετήσει νόμιμους χρήστες.

Τρίτον, ακόμα και χωρίς κακή πρόθεση, ένας client μπορεί να στείλει λάθος δεδομένα λόγω bug. Το σύστημα πρέπει να προστατεύεται και από αυτό.

Τέλος, υπάρχει και η επιχειρησιακή διάσταση. Δεν έχουν όλα τα endpoints τις ίδιες ανάγκες. Ένα endpoint για avatar δεν πρέπει να δέχεται το ίδιο μέγεθος δεδομένων με ένα endpoint για document upload.

Τι είναι το request size limit

Είναι ένα όριο στο μέγεθος του body ενός HTTP request. Αν το request ξεπεράσει αυτό το όριο, απορρίπτεται πριν επεξεργαστεί περαιτέρω.

Η απόρριψη γίνεται με HTTP status:

413 Payload Too Large

Το σημαντικό δεν είναι μόνο ότι απορρίπτεται, αλλά πού απορρίπτεται.

Η έννοια των layers

Ένα request δεν φτάνει απευθείας στον controller. Περνά από πολλαπλά επίπεδα.

Client
  ↓
Reverse Proxy / Gateway (IIS, Azure, nginx)
  ↓
Kestrel (web server)
  ↓
ASP.NET pipeline (Middleware)
  ↓
API endpoint
  ↓
Controller

Κάθε επίπεδο έχει τη δυνατότητα να εφαρμόσει limit.

Η σωστή αρχιτεκτονική δεν βασίζεται σε ένα σημείο, αλλά σε διαδοχικά επίπεδα ελέγχου.

Τα επίπεδα και ο ρόλος τους

Reverse Proxy / Gateway

Αυτό είναι το εξωτερικό όριο του συστήματος.

Σε αυτό το σημείο το request μπορεί να απορριφθεί πριν φτάσει καν στην εφαρμογή. Αυτό σημαίνει ότι δεν καταναλώνονται application resources.

Είναι το πιο αποδοτικό σημείο για να απορρίπτονται υπερβολικά μεγάλα requests.

Kestrel (server level)

Ο Kestrel είναι ο web server που τρέχει την ASP.NET Core εφαρμογή.

Σε αυτό το επίπεδο ορίζεται ένα γενικό όριο για όλη την εφαρμογή, λειτουργώντας ως μηχανισμός προστασίας:

αποτρέπει μεγάλα requests πριν μπουν στο pipeline
καλύπτει όλα τα endpoints
λειτουργεί ως safety net

Το όριο αυτό εκφράζει το τι μπορεί να αντέξει τεχνικά το σύστημα, όχι απαραίτητα το τι επιτρέπεται επιχειρησιακά.

Ωστόσο, σε cloud περιβάλλοντα όπως το Azure, οι περιορισμοί του Kestrel δεν αποτελούν πάντα το τελικό σημείο ελέγχου. Ένα request μπορεί να έχει ήδη περάσει από upstream managed layers (π.χ. gateways, front ends) που εφαρμόζουν δικούς τους περιορισμούς, ενώ σε ορισμένα hosting μοντέλα (όπως Azure Functions in-process) το HTTP pipeline δεν ελέγχεται άμεσα από τον προγραμματιστή.

Συνεπώς, τα application-level limits θα πρέπει να αντιμετωπίζονται ως ένα επιπλέον επίπεδο προστασίας και όχι ως η μοναδική γραμμή άμυνας.

ASP.NET / API επίπεδο

Σε αυτό το επίπεδο βρίσκονται τα endpoints.

Εδώ εφαρμόζονται limits μέσω μηχανισμών όπως:

[RequestSizeLimit(...)]

Τα limits αυτά εκφράζουν επιχειρησιακούς κανόνες χρήσης και όχι τεχνικούς περιορισμούς του συστήματος. Δηλαδή καθορίζουν τι επιτρέπεται ανά endpoint, ανεξάρτητα από το τι μπορεί να αντέξει συνολικά η εφαρμογή.

Παραδείγματα:

avatar upload: 3 MB
document upload: 25 MB
JSON request: 512 KB

Τα endpoint-level limits λειτουργούν συμπληρωματικά με τα υπόλοιπα επίπεδα (π.χ. Kestrel, gateway), επιτρέποντας πιο granular έλεγχο ανά use case.

Ωστόσο, όπως και με τα application-level limits, οι περιορισμοί αυτοί δεν εγγυώνται ότι το request θα φτάσει στο endpoint, καθώς μπορεί να απορριφθεί νωρίτερα από upstream layers.

Hosting Model & Azure Plan: Ποιος ελέγχει πραγματικά το pipeline;

Σε Azure περιβάλλοντα, ειδικά όταν χρησιμοποιούνται Azure Functions, το ποιος ελέγχει το HTTP request pipeline δεν είναι πάντα προφανές και εξαρτάται από δύο βασικούς παράγοντες: το hosting model και το deployment plan.

Στο in-process model, το application εκτελείται μέσα στο ίδιο process με το Functions runtime. Αυτό σημαίνει ότι το HTTP pipeline διαχειρίζεται πλήρως από την πλατφόρμα και δεν υπάρχει άμεσος έλεγχος στον underlying server (π.χ. Kestrel). Οι ρυθμίσεις που θα εφαρμόζονταν σε ένα τυπικό ASP.NET Core application δεν έχουν απαραίτητα το ίδιο αποτέλεσμα.

Αντίθετα, στο isolated worker model, το application τρέχει σε ξεχωριστό process και μπορεί να αξιοποιήσει ASP.NET Core integration. Σε αυτή την περίπτωση, υπάρχει δυνατότητα ελέγχου του request pipeline (middleware, filters, limits), προσεγγίζοντας τη συμπεριφορά ενός κλασικού Web API.

Βασικές διαφορές στην πράξη (isolated vs in-process)

Η ουσιαστική διαφορά μεταξύ των δύο μοντέλων δεν είναι μόνο το process isolation, αλλά το επίπεδο ελέγχου και παραμετροποίησης του HTTP pipeline. Στο in-process model, το request περνά αποκλειστικά μέσα από το Functions runtime, το οποίο ορίζει τη ροή εκτέλεσης και επιβάλλει περιορισμούς πριν το application code αποκτήσει έλεγχο. Αυτό σημαίνει ότι δεν υπάρχει πραγματικό ASP.NET Core pipeline, ούτε δυνατότητα χρήσης middleware, και κατά συνέπεια οι έννοιες όπως Kestrel-level limits ή request filtering δεν εφαρμόζονται με τον ίδιο τρόπο. Αντίθετα, στο isolated model, το application μπορεί να “χτίσει” το δικό του pipeline μέσω ASP.NET Core integration, επιτρέποντας την εισαγωγή middleware, custom handling και πιο granular έλεγχο στη ροή των requests. Παρ’ όλα αυτά, ακόμη και σε αυτή την περίπτωση, το pipeline δεν είναι πλήρως αυτόνομο, καθώς προηγούνται πάντα managed layers της πλατφόρμας που ενδέχεται να επιβάλλουν δικούς τους περιορισμούς.

Ωστόσο, το Azure plan επηρεάζει σημαντικά το επίπεδο ελέγχου:

Στο Consumption plan, το request περνάει από managed infrastructure layers της πλατφόρμας πριν φτάσει στο application, επιβάλλοντας περιορισμούς ανεξάρτητα από το application configuration.
Στα Premium ή App Service plans, το περιβάλλον είναι πιο κοντά σε παραδοσιακό hosting, επιτρέποντας μεγαλύτερο έλεγχο στο HTTP pipeline και καλύτερη αξιοποίηση του ASP.NET Core stack.

Σε κάθε περίπτωση, είναι σημαντικό να σημειωθεί ότι τα upstream layers (Azure infrastructure, reverse proxies, gateways) ενδέχεται να εφαρμόζουν αυστηρότερους περιορισμούς από αυτούς που ορίζονται στο application. Αυτό σημαίνει ότι ένα request μπορεί να απορριφθεί πριν φτάσει ποτέ στο ASP.NET Core pipeline, ανεξάρτητα από τις ρυθμίσεις που έχουν οριστεί σε επίπεδο middleware ή API.

Κατά συνέπεια, πριν βασιστούμε σε application-level περιορισμούς, είναι απαραίτητο να κατανοήσουμε αν το περιβάλλον εκτέλεσης μας επιτρέπει πραγματικά να τους εφαρμόσουμε και ποιο layer έχει τον τελικό έλεγχο στην αποδοχή ή απόρριψη ενός request.

Σημείωση για συμβατικά Web Applications (App Service)

Σε αντίθεση με τα serverless σενάρια (π.χ. Azure Functions), σε ένα τυπικό ASP.NET Core Web Application που φιλοξενείται στο Azure App Service, η εφαρμογή εκτελείται πάντα πάνω στον Kestrel. Ακόμη και όταν υπάρχει IIS (σε Windows environments) ή άλλο reverse proxy μπροστά, αυτά λειτουργούν ως ενδιάμεσο layer που προωθεί τα requests, ενώ ο Kestrel παραμένει ο πραγματικός web server που εκτελεί το ASP.NET Core pipeline. Συνεπώς, server-level ρυθμίσεις (όπως request size limits) εξακολουθούν να υφίστανται στο application runtime, ακόμη και αν δεν είναι πάντα άμεσα ορατές ή πλήρως ελέγξιμες από τον προγραμματιστή.

Ρόλος του Azure Front Door στο request pipeline

Σε cloud αρχιτεκτονικές, ένα επιπλέον επίπεδο που συχνά προηγείται του application είναι το Azure Front Door. Το Front Door λειτουργεί ως global entry point και reverse proxy, δρομολογώντας τα requests προς τα backend services. Σε αυτό το επίπεδο μπορούν να εφαρμοστούν περιορισμοί όπως request size limits, rate limiting, WAF κανόνες και άλλοι μηχανισμοί προστασίας. Καθώς βρίσκεται πριν από το application και τον web server, έχει τη δυνατότητα να απορρίπτει requests πολύ νωρίς, μειώνοντας σημαντικά το load που φτάνει στο σύστημα. Ωστόσο, όπως και με κάθε upstream layer, οι περιορισμοί του Front Door υπερισχύουν των downstream ρυθμίσεων, καθώς ένα request που απορρίπτεται σε αυτό το επίπεδο δεν φτάνει ποτέ στο ASP.NET Core pipeline.

Πώς συνεργάζονται τα επίπεδα

            [ Internet ]
                  │
            [ CDN / WAF ]
      "Early rejection"
                  │
         [ Reverse Proxy ]
    "HTTP body/header limits"
                  │
           [ Kestrel/IIS ]
     "Transport/server limits"
                  │
            [ Middleware ]
  "Request inspection & logging"
                  │
          [ MVC / Controllers ]
     "Business validation"
                  │
              [ Services ]

Το request περνά διαδοχικά από τα επίπεδα και σταματά στο πρώτο που θα παραβιάσει.

Αν ένα request είναι μεγαλύτερο από το όριο του proxy, δεν φτάνει ποτέ στον Kestrel.

Αν περάσει τον proxy αλλά είναι μεγαλύτερο από το Kestrel limit, απορρίπτεται εκεί.

Αν περάσει και τα δύο αλλά παραβιάζει το endpoint limit, απορρίπτεται στο API επίπεδο.

Αυτό δημιουργεί μια αλυσίδα προστασίας.

Στην πράξη, το πιο περιοριστικό upstream layer είναι αυτό που καθορίζει το τελικό αποδεκτό μέγεθος request, ανεξάρτητα από τις ρυθμίσεις των downstream επιπέδων.

Γιατί δεν αρκεί ένα μόνο επίπεδο

Αν βάλουμε limit μόνο στο API:

το request έχει ήδη φτάσει στον server
έχουν δεσμευτεί πόροι
η προστασία έρχεται αργά

Αν βάλουμε μόνο στο Kestrel:

προστατεύεται το σύστημα
αλλά δεν εκφράζονται business rules

Αν βάλουμε μόνο στο proxy:

προστατεύεται η είσοδος
αλλά δεν υπάρχει έλεγχος ανά endpoint

Καμία μεμονωμένη λύση δεν καλύπτει πλήρως το πρόβλημα.

Η σωστή προσέγγιση είναι ο συνδυασμός επιπέδων, όπου κάθε layer αναλαμβάνει διαφορετικό ρόλο: προστασία υποδομής, έλεγχος πόρων και εφαρμογή επιχειρησιακών κανόνων.

Όσο πιο νωρίς απορριφθεί ένα υπερβολικό request, τόσο λιγότερους πόρους καταναλώνει το σύστημα.

Ένα request που απορρίπτεται στο edge ή στο reverse proxy δεν φτάνει ποτέ σε parsing, model binding ή business logic.

Διαχωρισμός ευθυνών

Η αρχιτεκτονική γίνεται πιο καθαρή όταν ξεχωρίζουμε τι ανήκει πού.

Το Kestrel limit είναι infrastructure concern. Εξαρτάται από:

το περιβάλλον εκτέλεσης
το διαθέσιμο memory/CPU budget
το expected load του συστήματος

Για αυτό τον λόγο πρέπει να είναι configurable και environment-specific, συνήθως μέσω ρυθμίσεων όπως το appsettings.

Αντίθετα, τα API-level limits αποτελούν business rules. Ορίζονται στο application layer και εκφράζουν τι επιτρέπεται λειτουργικά ανά endpoint ή use case, ανεξάρτητα από το υποκείμενο infrastructure.

Ο σωστός διαχωρισμός είναι αυτός που επιτρέπει στο σύστημα να παραμένει σταθερό τεχνικά, ενώ οι επιχειρησιακοί κανόνες εξελίσσονται ανεξάρτητα από την υποδομή.

Μην βασίζεσαι αποκλειστικά στο frontend validation.

Κάθε layer πρέπει να θεωρεί το request μη έμπιστο.

Τι προστατεύουν οι περιορισμοί μεγέθους

Οι περιορισμοί μεγέθους δεν προστατεύουν μόνο από μεγάλα uploads.

Προστατεύουν επίσης από:

memory exhaustion
υπερβολικό JSON parsing
επιθέσεις μέσω oversized payloads
κατάχρηση file uploads
αυξημένη κατανάλωση CPU και bandwidth

Logging και Filtering: Middleware vs Controller Layer

Η τοποθέτηση του logging και των request validations (όπως έλεγχοι μεγέθους ή απορρίψεις requests) αποτελεί κρίσιμη αρχιτεκτονική απόφαση. Σε γενικές γραμμές, οι cross-cutting concerns όπως το logging, το error handling και οι βασικοί τεχνικοί περιορισμοί (π.χ. request size limits) ανήκουν στο επίπεδο του middleware. Σε αυτό το σημείο του pipeline, το request μπορεί να καταγραφεί και να απορριφθεί νωρίς, πριν ενεργοποιηθούν μηχανισμοί όπως routing, model binding ή controllers, μειώνοντας το κόστος επεξεργασίας και βελτιώνοντας την απόδοση του συστήματος.

Σε αυτό το στάδιο έχουμε ήδη πρόσβαση σε HTTP metadata όπως headers, Content-Length και stream δεδομένων, χωρίς να έχει εκτελεστεί ακόμα model binding ή business logic.

Αυτό επιτρέπει την έγκαιρη απόρριψη προβληματικών requests πριν καταναλωθούν επιπλέον πόροι της εφαρμογής.

Αντίθετα, η υλοποίηση αυτών των ελέγχων σε επίπεδο controller ή filter έχει νόημα όταν απαιτείται γνώση του συγκεκριμένου endpoint ή επιχειρησιακών κανόνων, όπως διαφορετικά όρια ανά use case ή domain-specific validation. Ωστόσο, σε αυτή την περίπτωση το request έχει ήδη διανύσει σημαντικό μέρος του pipeline, γεγονός που καθιστά την απόρριψη λιγότερο αποδοτική από πλευράς πόρων.

Συνεπώς, η βέλτιστη προσέγγιση είναι ο διαχωρισμός ευθυνών: το middleware αναλαμβάνει τους τεχνικούς και οριζόντιους ελέγχους (logging, βασικά limits, error handling), ενώ το application layer επικεντρώνεται στους επιχειρησιακούς κανόνες. Σε περιβάλλοντα με αυξημένες απαιτήσεις (π.χ. cloud deployments με πολλαπλά ingress layers), αυτός ο διαχωρισμός συμβάλλει σε καλύτερη απόδοση, καθαρότερη αρχιτεκτονική και ευκολότερη συντήρηση.

Ένα σωστό παράδειγμα

Reverse proxy / Azure: 100 MB
Kestrel: 100 MB

Endpoints:
  avatar: 3 MB
  document: 25 MB
  import: 50 MB
  JSON: 512 KB

Σε αυτή τη διάταξη:

το σύστημα προστατεύεται συνολικά
κάθε endpoint έχει σαφή όρια
τα layers συνεργάζονται σωστά

Τι επιστρέφει το API όταν απορρίπτει ένα request

Στις περισσότερες περιπτώσεις, όταν ένα αίτημα υπερβαίνει το επιτρεπτό μέγεθος, το API ή το reverse proxy επιστρέφει:

HTTP 413 Payload Too Large

Σε application-level validations μπορεί να χρησιμοποιηθούν και άλλα status codes, όπως:

400 Bad Request
422 Unprocessable Entity

ανάλογα με το είδος του περιορισμού.

Να θυμάσαι..

Το request size δεν ελέγχεται από ένα σημείο, αλλά από μια αλυσίδα επιπέδων όπου κάθε layer μπορεί να επιβάλει τα δικά του όρια.

Δεν έχει σημασία μόνο το τι έχεις ορίσει στον κώδικά σου, αλλά και το πού εκτελείται η εφαρμογή και ποια infrastructure layers προηγούνται.

Στην πράξη, ο πραγματικός έλεγχος του request size είναι πάντα συνδυασμός:

infrastructure constraints
runtime behavior
application-level business rules

Ο σωστός σχεδιασμός δεν είναι να επιλέξεις ένα επίπεδο, αλλά να τα ευθυγραμμίσεις ώστε να συνεργάζονται χωρίς αντιφάσεις.

Δεν αρκεί να υπάρχει limit.
Σημασία έχει σε ποιο layer εφαρμόζεται.

Πηγές

Microsoft – Kestrel limits (core reference)

Microsoft – Default limits & layering

Microsoft – RequestSizeLimitAttribute (API layer)

Multiple layers

IIS / Hosting layer (proxy level)

Σημαντικό τεχνικό insight (override behavior)

nikosstit@gmail.com

Γιατί το parallelism δεν σώζει τα αργά queries

nikosst — Thu, 23 Apr 2026 12:54:02 +0000

Εισαγωγή

Όταν ένα query κάνει timeout, στην ουσία το σύστημα σου λέει: «δεν μπορώ να περιμένω άλλο». Το timeout δεν είναι το πρόβλημα. Είναι ένας μηχανισμός προστασίας. Στις περισσότερες περιπτώσεις, όταν ένα query κάνει timeout, το πρόβλημα δεν είναι ότι “η βάση είναι αργή”. Είναι ότι το query κάνει περισσότερη δουλειά απ’ όση χρειάζεται. Το πραγματικό πρόβλημα είναι ότι το query είτε κάνει υπερβολική δουλειά, είτε το κάνει με λάθος τρόπο, είτε το σύστημα δεν αντέχει το φορτίο εκείνη τη στιγμή.

Σε αυτό το σημείο πολλοί developers σκέφτονται: «ας το κάνω parallel για να τρέξει πιο γρήγορα». Η σκέψη είναι λογική, αλλά όχι πάντα σωστή. Για να καταλάβουμε γιατί, πρέπει πρώτα να δούμε τι σημαίνει πραγματικά parallel execution.

Τι είναι το parallel execution

Σε έναν SQL Server, ένα query δεν εκτελείται πάντα από έναν μόνο πυρήνα CPU. Αν ο optimizer κρίνει ότι το query είναι αρκετά “βαρύ”, μπορεί να το σπάσει σε κομμάτια και να το εκτελέσει σε πολλούς πυρήνες ταυτόχρονα.

Για παράδειγμα, αν έχεις έναν μεγάλο πίνακα Orders και εκτελέσεις:

SELECT SUM(Amount)
FROM Orders

η βάση μπορεί να χωρίσει τα δεδομένα σε τμήματα και να τα επεξεργαστεί παράλληλα. Στο τέλος, τα αποτελέσματα ενώνονται και δίνουν το τελικό άθροισμα.

Αυτό είναι το parallelism. Δεν κάνει το query πιο “έξυπνο”. Το κάνει πιο “δυνατό”. Με άλλα λόγια, το parallelism προσπαθεί να ολοκληρώσει την ίδια δουλειά γρηγορότερα χρησιμοποιώντας περισσότερους πόρους CPU.

                Query
                   │
         ┌─────────┴─────────┐
         │                   │
      Thread 1           Thread 2
         │                   │
      Scan Part A        Scan Part B
         │                   │
         └─────────┬─────────┘
                   │
             Gather Streams
                   │
               Final Result

• περισσότερη CPU
• thread coordination
• CXPACKET / CXCONSUMER waits
• πιθανό faster elapsed time

Το βασικό λάθος: parallel ≠ optimization

Tο parallel execution δεν μειώνει τη δουλειά που πρέπει να γίνει. Απλώς τη μοιράζει.

Αν ένα query είναι κακοσχεδιασμένο, θα παραμείνει κακοσχεδιασμένο, απλώς θα εκτελείται σε περισσότερους πυρήνες. Το parallelism μπορεί να μειώσει τον elapsed time, αλλά δεν μειώνει τη συνολική δουλειά ούτε το συνολικό resource consumption.
Παράδειγμα:

SELECT *
FROM Customers
WHERE Name LIKE '%john%'

Αυτό το query δεν μπορεί να χρησιμοποιήσει index και αναγκάζει τη βάση να σκανάρει όλο τον πίνακα. Αν το κάνεις parallel, απλώς μοιράζεις το scan σε πολλούς πυρήνες. Δεν μειώνεις το πρόβλημα.

Αντίθετα:

SELECT *
FROM Customers
WHERE Name LIKE 'john%'

επιτρέπει τη χρήση index και μειώνει δραματικά τη δουλειά που πρέπει να γίνει. Αυτό είναι optimization.

Τι είναι το MAXDOP και τι ελέγχει

Το MAXDOP (Maximum Degree of Parallelism) είναι το εργαλείο που σου δίνει έλεγχο στο parallel execution. Ορίζει πόσους πυρήνες μπορεί να χρησιμοποιήσει ένα query.

Η σύνταξη είναι απλή:

OPTION (MAXDOP 1)

σημαίνει ότι το query θα εκτελεστεί σειριακά, δηλαδή σε έναν πυρήνα.

OPTION (MAXDOP 4)

σημαίνει ότι μπορεί να χρησιμοποιήσει μέχρι 4 πυρήνες.

OPTION (MAXDOP 0)

σημαίνει ότι αφήνεις τη βάση να αποφασίσει μόνη της.

Το σημαντικό εδώ είναι ότι το MAXDOP δεν είναι “boost”. Είναι περιορισμός.

Το MAXDOP δεν αναγκάζει ένα query να γίνει parallel. Απλώς ορίζει το μέγιστο επίπεδο παραλληλισμού που επιτρέπεται αν ο optimizer επιλέξει parallel plan.

Σημαντικό: Το MAXDOP 1 δεν κάνει απαραίτητα ένα query πιο γρήγορο σε απόλυτο χρόνο. Το βασικό του όφελος εμφανίζεται κυρίως σε production περιβάλλοντα με πολλούς ταυτόχρονους χρήστες, όπου τα parallel workers ανταγωνίζονται μεταξύ τους για CPU και μπορούν να επηρεάσουν αρνητικά το συνολικό throughput του SQL Server. Σε localhost ή σε περιβάλλον με έναν μόνο χρήστη, αυτό το contention συνήθως δεν υπάρχει, οπότε το parallel execution μπορεί να είναι εξίσου γρήγορο ή και ταχύτερο.

Κριτήρια Παραλληλισμού και Σημασία του MAXDOP 1

Πότε το SQL Server Χρησιμοποιεί Πολλαπλούς Πυρήνες;

Το SQL Server αυτόματα αποφασίζει να χρησιμοποιήσει παραλληλισμό (πολλαπλούς CPU πυρήνες) όταν το εκτιμώμενο κόστος εκτέλεσης (estimated execution cost) ενός query είναι μεγαλύτερο από 5. Αυτή η τιμή ονομάζεται "Cost Threshold for Parallelism" και είναι η default ρύθμιση του SQL Server.

Το threshold αυτό δεν είναι “χρόνος εκτέλεσης” ούτε απόλυτη μονάδα μέτρησης. Είναι εσωτερικό cost metric του optimizer που χρησιμοποιείται μόνο για σύγκριση execution plans.

Για queries που ξεπερνούν αυτό το όριο, ο SQL Server ενεργοποιεί παραλληλισμό χρησιμοποιώντας 4-8 threads (ανάλογα με το Max Degree of Parallelism configuration του server), προσπαθώντας να επιταχύνει την εκτέλεση μοιράζοντας τη δουλειά σε πολλαπλούς πυρήνες.

Το πρόβλημα: Για τα OLTP queries της εφαρμογής μας (GetEmployeeById, GetCitiesFiltered, κλπ.), που έχουν 3-8 Includes και επιστρέφουν 1-50 rows, το estimated cost συχνά είναι 6-15 (λόγω των joins), οπότε ενεργοποιείται παραλληλισμός χωρίς να είναι αναγκαίος. Αυτό προσθέτει 20-40% overhead λόγω:

• CXPACKET waits: Τα threads περιμένουν το πιο αργό thread για συγχρονισμό
• Thread coordination: Κόστος δημιουργίας και διαχείρισης πολλαπλών threads
• Context switching: Εναλλαγή μεταξύ threads στον CPU

Μέχρι εδώ είδαμε τι κάνει το parallelism. Για να καταλάβουμε όμως γιατί ο SQL Server αποφασίζει να το χρησιμοποιήσει, πρέπει να δούμε πώς ο optimizer εκτιμά το κόστος ενός query.

Πώς Αξιολογεί πραγματικά ο SQL Server Query Optimizer το Κόστος ενός Query

Ο SQL Server Query Optimizer χρησιμοποιεί ένα cost-based μοντέλο, αλλά όχι με τον απλοϊκό τρόπο που συχνά παρουσιάζεται. Το “estimated cost” δεν είναι πραγματικός χρόνος εκτέλεσης ούτε υπολογίζεται με σταθερό formula (π.χ. base cost + joins). Είναι ένα σχετικό metric, βασισμένο κυρίως σε εκτιμήσεις (estimates) για το πόσα rows θα επεξεργαστούν και τι πόρους (CPU/I/O) θα χρειαστούν τα διαφορετικά execution plans.

Στην πράξη, ο optimizer:

εκτιμά πόσα rows θα επεξεργαστεί
επιλέγει τρόπους πρόσβασης στα δεδομένα (seek/scan)
αποφασίζει join strategies
και συγκρίνει διαφορετικά execution plans

Σημαντικό: το cost χρησιμοποιείται μόνο για σύγκριση μεταξύ plans, όχι ως απόλυτη ένδειξη απόδοσης, και μπορεί να είναι λάθος αν τα statistics δεν είναι accurate.

Τι επηρεάζει πραγματικά το cost (χωρίς oversimplification)

Αν και δεν υπάρχει “επίσημο formula”, στην πράξη το cost επηρεάζεται κυρίως από:

Cardinality (rows) → ο πιο σημαντικός παράγοντας (multiplicative effect)
Τύπος πρόσβασης δεδομένων → seek vs scan
Join complexity → αριθμός joins και είδος (nested loop, hash, merge)
Execution tree depth → nested includes / subqueries
Filters & predicates → ειδικά σε non-indexed columns
Aggregations / sorting → GROUP BY, ORDER BY αυξάνουν σημαντικά το cost

seek vs scan

Στις βάσεις δεδομένων όπως το SQL Server, η διαφορά μεταξύ seek και scan αφορά τον τρόπο πρόσβασης στα δεδομένα.

• Index Seek
Στοχευμένη πρόσβαση μέσω index για εύρεση συγκεκριμένων rows.

Παράδειγμα:
SELECT * FROM Users WHERE Id = 10;

• Index/Table Scan
Ανάγνωση μεγάλου μέρους ή ολόκληρου του πίνακα για εύρεση δεδομένων.

Παράδειγμα:
SELECT * FROM Users WHERE Name LIKE '%nikos%';

Συνήθως τα seeks είναι πολύ πιο αποδοτικά σε μεγάλα datasets, γιατί μειώνουν δραματικά τον όγκο δεδομένων που πρέπει να διαβαστεί.

Ρεαλιστικό παράδειγμα (όχι “μαγικά νούμερα”)

Ένα απλό OLTP query:

PK seek (πολύ χαμηλό cost)
3 απλά joins σε indexed FKs
μικρό result set (π.χ. 1 row)

Estimated cost: ~2–3
Δεν θα γίνει ποτέ parallel (κάτω από threshold)
Ένα πιο σύνθετο query:

scan ή range seek
5–6 joins
authorization filter (subquery)
μεγαλύτερο intermediate dataset

Estimated cost: ~8–12
Πιθανό parallel plan

Ένα reporting query:

`full scan μεγάλου πίνακα
GROUP BY + aggregations
δεκάδες χιλιάδες rows `

Estimated cost: 100+ έως 1000+
Parallelism είναι σχεδόν απαραίτητο

Πού μπαίνει το Parallelism (και γιατί δεν είναι πάντα λύση)

Όταν το estimated cost ξεπεράσει το Cost Threshold for Parallelism (~5), ο optimizer μπορεί να επιλέξει parallel execution (ανάλογα με MAXDOP και server load).

Όμως:

το parallelism εισάγει coordination overhead (exchange operators, thread sync)
εμφανίζονται waits όπως CXPACKET / CXCONSUMER
σε μικρά OLTP queries, το overhead μπορεί να είναι μεγαλύτερο από το όφελος

Άρα: “μεγάλο cost ⇒ βάλε parallel” είναι oversimplification.

Πρακτικά κριτήρια για χρήση MAXDOP 1

Για να αποφασίσεις σωστά, κοίτα:

Estimated Cost

< 4.5 → ποτέ parallel → μην βάζεις MAXDOP
4.5–6 → borderline
6 → πιθανό parallel

Query shape

πολλά joins / nested includes
subqueries / authorization filters

Workload type

OLTP (μικρά, συχνά queries) → αποφεύγεις parallelism
OLAP/reporting → το θέλεις

Runtime signals

CXPACKET / CXCONSUMER waits
υψηλό CPU χωρίς αντίστοιχο throughput

Συμπέρασμα

Το cost του SQL Server δεν είναι “μαθηματικός τύπος”, αλλά αποτέλεσμα εκτιμήσεων πάνω σε δεδομένα και statistics. Το parallelism ενεργοποιείται βάσει αυτού του cost, αλλά δεν είναι εγγύηση καλύτερης απόδοσης — ειδικά σε OLTP σενάρια. Γι’ αυτό, η χρήση του MAXDOP 1 πρέπει να είναι στοχευμένη και βασισμένη σε cost, query shape και runtime behavior, όχι γενική πρακτική.

Γιατί Είναι Σημαντικό το MAXDOP 1;

Το MAXDOP 1 (Max Degree of Parallelism = 1) επιβάλλει single-threaded εκτέλεση, εξαλείφοντας εντελώς το overhead του παραλληλισμού. Για interactive queries που επιστρέφουν λίγα records, αυτό έχει δραματικά οφέλη:

1.Απόδοση: Βελτίωση 10-25% σε CPU time και elapsed time, καθώς αφαιρείται το overhead συγχρονισμού

2.Προβλεψιμότητα: Σταθερός χρόνος απόκρισης χωρίς CXPACKET waits

3.Scalability: Σε high concurrency περιβάλλοντα, το MAXDOP 1 ελευθερώνει CPU πυρήνες για άλλα requests αντί να τους "κλειδώνει" σε παραλληλισμό ενός query

4.Resource Efficiency: Μειωμένη κατανάλωση thread pool resources

Πότε ΔΕΝ πρέπει να χρησιμοποιείται: Για reports, exports, ή queries με GROUP BY/aggregations που επεξεργάζονται χιλιάδες rows, ο παραλληλισμός είναι απαραίτητος και το MAXDOP 1 θα τα κάνει πολύ πιο αργά.

Στην περίπτωσή μας: Εφαρμόζουμε MAXDOP 1 μόνο σε 44 interactive OLTP queries με ≤8 includes, όπου ο παραλληλισμός είναι περισσότερο "βάρος" παρά όφελος. Τα αποτελέσματα θα επαληθευτούν με SSMS testing συγκρίνοντας CPU time, elapsed time, και CXPACKET waits.

Πότε χρησιμοποιείς MAXDOP 1

Υπάρχουν περιπτώσεις όπου το να περιορίσεις το parallelism είναι πιο σημαντικό από το να κάνεις ένα query πιο γρήγορο. Αυτό συμβαίνει κυρίως σε συστήματα με πολλούς ταυτόχρονους χρήστες.

Φαντάσου ένα API που κάνει αναζήτηση υπαλλήλων. Το endpoint αυτό το χτυπάνε 20 χρήστες ταυτόχρονα. Αν κάθε query χρησιμοποιεί 4 ή 8 πυρήνες, τότε πολύ γρήγορα εξαντλείται η CPU και όλα τα queries αρχίζουν να καθυστερούν.

Σε αυτή την περίπτωση, αν βάλεις:

OPTION (MAXDOP 1)

κάθε query χρησιμοποιεί μόνο έναν πυρήνα. Μπορεί να είναι λίγο πιο αργό μεμονωμένα, αλλά το σύστημα συνολικά γίνεται πιο σταθερό και μπορεί να εξυπηρετήσει περισσότερους χρήστες ταυτόχρονα.

Αυτό είναι ένα κλασικό trade-off μεταξύ individual query latency και συνολικού system throughput.

Σε high concurrency συστήματα, συνήθως προτιμάς σταθερότητα και προβλεψιμότητα αντί για το να “πετάει” ένα μόνο query χρησιμοποιώντας πολλούς πυρήνες.

Αυτός είναι ο λόγος που σε OLTP συστήματα (APIs, web εφαρμογές) συχνά περιορίζουμε το parallelism.

Πότε αφήνεις ή αυξάνεις το MAXDOP

Σε αντίθεση με τα APIs, υπάρχουν workloads όπου θέλεις να εκμεταλλευτείς πλήρως την CPU. Αυτά είναι συνήθως reports, aggregations ή batch jobs που τρέχουν λιγότερο συχνά αλλά επεξεργάζονται μεγάλα datasets.

Παράδειγμα:

SELECT Region, SUM(Sales)
FROM SalesData
GROUP BY Region

Αυτό είναι ένα query που επωφελείται από parallel execution. Δεν έχεις πολλούς χρήστες να το χτυπάνε ταυτόχρονα, και σε νοιάζει να τελειώσει όσο πιο γρήγορα γίνεται.

Εδώ το να αφήσεις το default MAXDOP ή να επιτρέψεις περισσότερους πυρήνες είναι σωστή επιλογή.

Το hidden κόστος του parallelism

Το parallel execution έχει κόστος που δεν φαίνεται άμεσα. Όταν ένα query εκτελείται σε πολλούς πυρήνες, δημιουργείται ανάγκη για συντονισμό μεταξύ των threads. Κάποια threads μπορεί να τελειώνουν νωρίτερα και να περιμένουν τα υπόλοιπα. Αυτή η αναμονή εμφανίζεται ως waits όπως CXPACKET ή CXCONSUMER.

Στις νεότερες εκδόσεις του SQL Server, μεγάλο μέρος των parallel waits εμφανίζεται πλέον ως CXCONSUMER, ώστε να διαχωρίζεται το φυσιολογικό coordination overhead από τα πραγματικά προβληματικά waits.

Γι’ αυτό, η ύπαρξη CXPACKET ή CXCONSUMER waits δεν σημαίνει αυτόματα ότι υπάρχει πρόβλημα. Η αξιολόγηση πρέπει να γίνεται μαζί με CPU usage, query duration και execution plans.

Το CXPACKET σημαίνει ότι ένα thread περιμένει τα υπόλοιπα threads του ίδιου query να ολοκληρώσουν τη δουλειά τους. Συνήθως δείχνει ότι η κατανομή του workload δεν είναι ισορροπημένη. Το CXCONSUMER εμφανίζεται όταν ένα thread περιμένει να λάβει δεδομένα από άλλα threads μέσα στη ροή εκτέλεσης. Αυτό είναι πιο φυσιολογικό σε parallel queries.

Το σημαντικό είναι ότι αυτά τα waits δεν είναι πάντα πρόβλημα, αλλά όταν κυριαρχούν, δείχνουν ότι το parallelism δεν λειτουργεί αποδοτικά.

Γιατί το parallelism μπορεί να κάνει τα πράγματα χειρότερα

Σε περιβάλλοντα με υψηλό concurrency, το parallelism μπορεί να δημιουργήσει συμφόρηση. Αν έχεις πολλούς χρήστες και κάθε query χρησιμοποιεί πολλούς πυρήνες, το σύστημα αρχίζει να “πνίγεται”.

Αυτό είναι ιδιαίτερα επικίνδυνο σε APIs με υψηλό concurrency, όπου δεκάδες requests μπορεί να εκτελούνται ταυτόχρονα. Ένα μόνο expensive parallel query μπορεί να επηρεάσει δυσανάλογα ολόκληρο το workload του server.

Πού πρέπει να εστιάσεις πραγματικά

Το πιο σημαντικό σημείο είναι ότι τα περισσότερα performance προβλήματα δεν λύνονται με parallelism. Λύνονται με σωστό σχεδιασμό.

Αν ένα query κάνει full scan, αν επιστρέφει υπερβολικά πολλά δεδομένα ή αν χρησιμοποιεί μη αποδοτικά φίλτρα, το πρόβλημα δεν είναι πόσους πυρήνες χρησιμοποιεί, αλλά πόση δουλειά κάνει.

Η σωστή προσέγγιση είναι πάντα η ίδια: πρώτα μειώνεις τη δουλειά που πρέπει να γίνει και μετά, αν χρειάζεται, βελτιστοποιείς τον τρόπο που εκτελείται.

Τι είναι τα OLTP συστήματα?

Τα OLTP (Online Transaction Processing) συστήματα είναι βάσεις/συστήματα που έχουν σχεδιαστεί για να διαχειρίζονται πολλές μικρές, γρήγορες συναλλαγές σε πραγματικό χρόνο (π.χ. insert/update/delete).

Με απλά λόγια:

είναι τα “operational” συστήματα που τρέχουν την καθημερινή λειτουργία μιας εφαρμογής (π.χ. orders, payments, employee data).

Παραδείγματα:

σύστημα παραγγελιών (orders)
τραπεζικές συναλλαγές
HR systems (employees, μισθοδοσία)

Χαρακτηριστικά:

πολλά concurrent users
γρήγορα queries (συνήθως απλά)
έμφαση σε consistency & integrity (ACID)

Σε αντίθεση με OLAP (analytics), τα OLTP είναι για run the business, όχι για reporting/analysis.

Τι είναι τα OLAP συστήματα?

Τα OLAP (Online Analytical Processing) συστήματα είναι σχεδιασμένα για ανάλυση δεδομένων και reporting, όχι για καθημερινές συναλλαγές.

Με απλά λόγια:

είναι τα συστήματα που χρησιμοποιείς για να βγάζεις insights από τα δεδομένα (π.χ. reports, dashboards, trends).

Παραδείγματα:

data warehouse
BI tools (Power BI, Tableau)
sales / finance reports

Χαρακτηριστικά:

δουλεύουν σε μεγάλα volumes δεδομένων
queries είναι πιο “βαριά” (aggregations, joins)
λιγότερα writes, κυρίως reads
optimized για analysis (GROUP BY, trends, KPIs)

Σε αντίθεση με OLTP (που είναι για transactions), τα OLAP είναι για analysis & decision making.

Τα timeouts δεν σημαίνουν πάντα “αργό query”

Ένα timeout μπορεί να προκληθεί από:

blocking
lock contention
thread pool starvation
υψηλό CPU load
parameter sniffing
κακό execution plan
network delays

Γι’ αυτό, πριν θεωρήσεις ότι το πρόβλημα είναι το parallelism ή το MAXDOP, πρέπει πρώτα να εξετάσεις execution plans, waits, runtime metrics και concurrency behavior.

Να θυμάσαι..

Το parallel execution είναι ένα ισχυρό χαρακτηριστικό, αλλά δεν είναι λύση από μόνο του. Το MAXDOP δεν είναι εργαλείο επιτάχυνσης, αλλά εργαλείο ελέγχου.

Σε ένα καλά σχεδιασμένο σύστημα, χρησιμοποιείς parallelism εκεί που πραγματικά προσφέρει αξία και το περιορίζεις εκεί που μπορεί να προκαλέσει αστάθεια.

Η ουσία είναι απλή:

Δεν προσπαθείς να κάνεις το query πιο “δυνατό”.
Προσπαθείς να το κάνεις πιο “έξυπνο”.

Το parallelism είναι εργαλείο κλιμάκωσης, όχι υποκατάστατο σωστού query design. Αν ένα query χρειάζεται περισσότερη CPU για να “σωθεί”, συνήθως αξίζει πρώτα να αναρωτηθείς γιατί κάνει τόση δουλειά εξαρχής.

Και όταν αυτό δεν φτάνει, τότε — και μόνο τότε — αποφασίζεις πόση CPU αξίζει να του δώσεις.

Συχνό λάθος mindset

Ένα συχνό λάθος είναι να αντιμετωπίζεται το parallelism σαν “θεραπεία” για κάθε αργό query.

Στην πράξη, αν ένα query:

διαβάζει υπερβολικά πολλά δεδομένα,
κάνει scans αντί για seeks,
επιστρέφει περισσότερα rows από όσα χρειάζονται,
ή βασίζεται σε κακά execution plans,

τότε το parallelism συνήθως απλώς μεταφέρει το πρόβλημα σε περισσότερους CPU πυρήνες.

Το πρώτο βήμα πρέπει σχεδόν πάντα να είναι:

καλύτερα indexes,
λιγότερα reads,
σωστό filtering,
και καλύτερο query shape.

Πρώτα μειώνεις τη δουλειά.
Μετά αποφασίζεις πόση CPU αξίζει να της δώσεις.

Τι να ελέγξεις πρώτα όταν βλέπεις timeouts

Πριν αλλάξεις MAXDOP ή προσπαθήσεις να αυξήσεις το parallelism, έλεγξε:

Actual execution plan
Index usage (seek vs scan)
Missing/inefficient indexes
Query duration & CPU time
Wait statistics
Blocking / deadlocks
Statistics freshness
Query Store history
Number of returned rows

Στις περισσότερες περιπτώσεις, το bottleneck φαίνεται πολύ πιο καθαρά στα execution plans και στα waits παρά στο ίδιο το timeout.

Microsoft sources

Troubleshoot query time-out errors
Microsoft λέει ότι ο πρώτος στόχος είναι να κάνεις το query πιο γρήγορο και να εντοπίσεις ποιο query προκαλεί timeout με Extended Events / traces.

Troubleshoot slow-running queries
Προτείνει να ξεκινάς από elapsed time, waits, CPU time και bottleneck analysis — όχι από “βάλε parallel”.

Query Processing Architecture Guide
Εξηγεί ότι parallel plan μπορεί να τελειώσει πιο γρήγορα, αλλά χρησιμοποιεί περισσότερους πόρους και ο optimizer το επιλέγει μόνο αν δεν επηρεάζει αρνητικά το server load.

MAXDOP configuration
Το MAXDOP απλώς περιορίζει πόσους processors μπορεί να χρησιμοποιήσει ένα parallel plan· δεν είναι γενική θεραπεία για κακό query.

Cost Threshold for Parallelism
Εξηγεί πότε ο SQL Server σκέφτεται parallel plan· άρα είναι configuration tuning, όχι αντικατάσταση query/index tuning.

Execution Plans
Τα execution plans είναι το βασικό εργαλείο για να δεις πώς ο optimizer αποφάσισε να τρέξει το query.

Index Design Guide
Microsoft γράφει ξεκάθαρα ότι efficient indexes είναι κλειδί για καλή database/application performance.

Statistics
Ο optimizer βασίζεται σε statistics για να φτιάξει καλά query plans· λάθος/παλιά stats μπορούν να οδηγήσουν σε κακό plan.

Query Store
Query Store κρατά ιστορικό queries, plans και runtime stats, άρα είναι σωστό εργαλείο για να βρεις regressions και top resource-consuming queries.

Blocking problems
Timeouts μπορεί να οφείλονται και σε blocking, όχι απαραίτητα σε “αργό query”.

Άλλες αξιόπιστες πηγές

Brent Ozar – Parallelism settings: λέει ότι τα default MAXDOP/Cost Threshold συχνά είναι κακά και ένα query μπορεί να απλωθεί σε πολλά cores και να επηρεάσει άλλους χρήστες.

Erland Sommarskog – Slow in the Application, Fast in SSMS?: εξηγεί ότι application timeouts/slow queries συχνά σχετίζονται με plans, cache, parameter sniffing κ.λπ., όχι απλά με έλλειψη parallelism.

Redgate – Actual execution plans: τονίζει ότι για expensive/slow queries χρειάζεσαι actual execution plan με runtime statistics.

nikosstit@gmail.com

AsTracking vs AsNoTracking στο Entity Framework Core Πλήρης Ανάλυση με Παραδείγματα

nikosst — Mon, 30 Mar 2026 13:39:07 +0000

Όταν δουλεύουμε με Entity Framework Core, ένα από τα πιο παρεξηγημένα αλλά ταυτόχρονα και κρίσιμα για την απόδοση θέματα είναι το change tracking. Πολλοί developers γράφουν queries χωρίς να συνειδητοποιούν ότι το EF Core παρακολουθεί (trackάρει) κάθε entity που επιστρέφεται από τη βάση.

Αυτή η default συμπεριφορά μπορεί να είναι είτε εξαιρετικά χρήσιμη είτε εντελώς περιττή, ανάλογα με το σενάριο.

Με τον όρο tracking εννοούμε ότι το DbContext κρατά πληροφορίες για τα entities που φόρτωσε από τη βάση, ώστε να μπορεί αργότερα να εντοπίσει αλλαγές και να εκτελέσει σωστά το SaveChanges().

Με απλά λόγια:

AsTracking() → το EF Core παρακολουθεί αλλαγές στα entities
AsNoTracking() → το EF Core επιστρέφει δεδομένα χωρίς να παρακολουθεί αλλαγές

Σε αυτό το άρθρο θα δούμε τι κάνουν τα AsTracking() και AsNoTracking(), πώς επηρεάζουν την απόδοση και πότε πρέπει να χρησιμοποιούμε το καθένα.

Κατανόηση του Change Tracking

Στην καρδιά του Entity Framework Core βρίσκεται ο Change Tracker, αλλά είναι πολύ σημαντικό να ξεκαθαρίσουμε κάτι από την αρχή: το EF δεν παρακολουθεί τη βάση δεδομένων, παρακολουθεί τα objects που υπάρχουν στη μνήμη.

Όταν εκτελείς ένα query, το EF φέρνει δεδομένα από τη βάση και δημιουργεί αντίστοιχα C# objects. Αυτά τα objects αποθηκεύονται στο Change Tracker μαζί με την αρχική τους κατάσταση (π.χ. τις αρχικές τιμές των properties τους). Από εκεί και πέρα, το EF παρακολουθεί μόνο αυτά τα objects στη μνήμη.

Αυτό σημαίνει ότι αν αλλάξεις μια τιμή σε κάποιο object, το EF μπορεί να το εντοπίσει γιατί συγκρίνει την αρχική τιμή που κράτησε με τη νέα τιμή που έχει τώρα στη μνήμη. Όταν καλέσεις SaveChanges(), το EF μετατρέπει αυτές τις αλλαγές σε SQL UPDATE και τις στέλνει στη βάση.

Το workflow λοιπόν είναι το εξής:

Το EF Core φορτώνει δεδομένα από τη βάση
Δημιουργεί entities στη μνήμη
Αποθηκεύει την αρχική τους κατάσταση στο Change Tracker
Παρακολουθεί αλλαγές στα properties
Στο SaveChanges() μετατρέπει τις αλλαγές σε SQL UPDATE/INSERT/DELETE

Το tracking του EF Core δεν είναι μηχανισμός συγχρονισμού με τη βάση δεδομένων. Είναι μηχανισμός παρακολούθησης in-memory entity state μέσα στο DbContext.

Αυτό σημαίνει ότι το EF Core δεν “παρακολουθεί” εξωτερικές αλλαγές που γίνονται απευθείας στη βάση από άλλα systems ή DbContext instances.

Ένα κρίσιμο σημείο που συχνά μπερδεύει είναι το εξής:
αν κάποιος άλλος (ή άλλο σύστημα) αλλάξει τα δεδομένα απευθείας στη βάση μετά που εσύ τα έχεις φορτώσει, το EF δεν το γνωρίζει. Συνεχίζει να δουλεύει με τα δεδομένα που έχει ήδη στη μνήμη, εκτός αν ξανακάνεις query.

Παράδειγμα:

var user = context.Users.First(); // φορτώνεται στη μνήμη

Αν στο μεταξύ αλλάξει η ίδια εγγραφή στη βάση από αλλού, το user που έχεις στη μνήμη παραμένει όπως ήταν. Το EF δεν κάνει αυτόματη ανανέωση.

Με απλά λόγια:
Το EF Core δουλεύει με ένα snapshot της κατάστασης των entities που έχει φορτώσει στη μνήμη, όχι με live σύνδεση προς τη βάση δεδομένων. Το Change Tracker γνωρίζει μόνο την κατάσταση των entities που έχουν φορτωθεί μέσα στο συγκεκριμένο DbContext instance.

Το tracking υπάρχει μόνο όσο ζει το συγκεκριμένο DbContext. Όταν το DbContext γίνει disposed, χάνεται όλο το tracking state και τα entities παύουν να παρακολουθούνται.

Γι’ αυτό το EF Core αντιμετωπίζει το DbContext ως unit-of-work boundary και όχι ως long-lived cache μηχανισμό.

Τι κάνει το AsTracking();

Στην πραγματικότητα, το AsTracking() δεν αλλάζει τη συμπεριφορά του EF Core, γιατί το tracking είναι ήδη το default behavior για queries που επιστρέφουν entities.

Συνήθως χρησιμοποιείται για σαφήνεια ή όταν έχει προηγηθεί global/default απενεργοποίηση tracking.

Το AsTracking() ενεργοποιεί ρητά το tracking σε ένα query. Στην πράξη, επιβεβαιώνει το default behavior και χρησιμοποιείται κυρίως για σαφήνεια ή όταν έχει προηγηθεί απενεργοποίηση tracking.

var users = context.Users
    .AsTracking()
    .ToList();

users[0].Name = "Updated Name";

context.SaveChanges();

Σε αυτό το παράδειγμα:

Το entity αποθηκεύεται στο Change Tracker του DbContext
Το EF Core κρατά πληροφορίες για την αρχική και την τρέχουσα κατάστασή του
Εντοπίζει ότι άλλαξε το Name
Στο SaveChanges() δημιουργεί το αντίστοιχο SQL UPDATE

Τι κάνει το AsNoTracking();

Το AsNoTracking() απενεργοποιεί τον μηχανισμό παρακολούθησης (change tracking) του Entity Framework Core για τα entities που επιστρέφει ένα query. Αυτό σημαίνει ότι τα αντικείμενα που θα φορτωθούν από τη βάση δεδομένων δεν αποθηκεύονται στο Change Tracker του DbContext και το EF δεν κρατάει καμία πληροφορία για την αρχική τους κατάσταση.

var users = context.Users
    .AsNoTracking()
    .ToList();

users[0].Name = "Updated Name";

context.SaveChanges();

Σε αυτό το παράδειγμα, το EF φέρνει κανονικά τα δεδομένα από τη βάση και δημιουργεί τα αντίστοιχα objects στη μνήμη. Όταν αλλάζεις την τιμή του Name, η αλλαγή γίνεται μόνο μέσα στο object στη μνήμη δηλαδή στο C# instance και όχι στη βάση δεδομένων.

Το EF Core δεν παρακολουθεί το entity, άρα δεν κρατά original values ούτε πληροφορία για αλλαγές κατάστασης.

Όταν εκτελεστεί το SaveChanges(), το EF Core δεν βρίσκει modified tracked entities, οπότε δεν δημιουργεί κανένα UPDATE statement.

Με απλά λόγια: η αλλαγή έγινε στη μνήμη, αλλά το EF δεν την “είδε” ποτέ, άρα δεν μπορεί να τη μεταφέρει στη βάση δεδομένων.

Detached entities

Ένα entity που φορτώθηκε με AsNoTracking() θεωρείται detached από το DbContext.

Αυτό σημαίνει ότι το EF Core δεν το παρακολουθεί πλέον και δεν μπορεί να εντοπίσει αλλαγές πάνω του αυτόματα.

Αν αργότερα θελήσεις να κάνεις update αυτό το entity, πρέπει είτε:

να το κάνεις Attach(),
είτε να το ξαναφορτώσεις μέσω tracking query.

Το πρόβλημα που λύνει το Identity Resolution

Όταν χρησιμοποιούμε AsNoTracking(), χάνουμε ένα σημαντικό χαρακτηριστικό του EF:

Το ίδιο record μπορεί να εμφανιστεί ως διαφορετικά objects στη μνήμη

Αυτό συμβαίνει κυρίως σε queries με joins ή includes.

Παράδειγμα:

var orders = context.Orders
    .AsNoTracking()
    .Include(o => o.Customer)
    .ToList();

Αν ένας πελάτης έχει πολλά orders:

Το ίδιο Customer μπορεί να δημιουργηθεί πολλές φορές
Κάθε order έχει διαφορετικό instance του ίδιου customer

Τι κάνει το AsNoTrackingWithIdentityResolution();

Το AsNoTrackingWithIdentityResolution() είναι ένα ενδιάμεσο mode:

Δεν κάνει tracking (άρα είναι πιο ελαφρύ από AsTracking())
ΑΛΛΑ διατηρεί identity resolution

var orders = context.Orders
    .AsNoTrackingWithIdentityResolution()
    .Include(o => o.Customer)
    .ToList();

Τι αλλάζει εδώ;

Αν ο ίδιος Customer εμφανίζεται σε 10 orders: Θα υπάρχει ένα και μόνο instance στη μνήμη
Το EF κρατάει έναν προσωρινό μηχανισμό για να αποφύγει duplicates
Δεν κρατάει όμως πλήρες tracking state

Είναι σημαντικό να ξεχωρίσουμε ότι το tracking και το identity resolution δεν είναι το ίδιο πράγμα.

Tracking σημαίνει ότι το EF Core παρακολουθεί αλλαγές στα entities για το SaveChanges().
Identity Resolution σημαίνει ότι το EF Core επαναχρησιμοποιεί το ίδιο object instance όταν το ίδιο entity εμφανίζεται πολλές φορές στο ίδιο query result.

Το AsTracking() παρέχει και τα δύο:

tracking
identity resolution

Το AsNoTracking() δεν παρέχει κανένα από τα δύο.

Το AsNoTrackingWithIdentityResolution() παρέχει μόνο identity resolution χωρίς change tracking.

Τι είναι το Identity Resolution

Το Identity Resolution εξασφαλίζει ότι αν το ίδιο entity εμφανιστεί πολλές φορές μέσα στο ίδιο query result, το EF Core θα χρησιμοποιήσει το ίδιο object instance στη μνήμη αντί να δημιουργήσει duplicates.

Αυτό είναι ιδιαίτερα σημαντικό σε queries με Include ή joins, όπου το ίδιο entity μπορεί να εμφανιστεί πολλές φορές μέσα στο result set.

Database
    │
    ▼
 DbContext
    │
    ▼
Change Tracker
    │
 ┌───────────────┬────────────────────┐
 │               │                    │
AsTracking   AsNoTracking   AsNoTrackingWithIdentityResolution
 │               │                    │
tracking       no tracking        identity resolution only
identity res   no identity res    no change tracking
SaveChanges ✔  SaveChanges ✘      SaveChanges ✘

Πρακτικό Παράδειγμα

Χωρίς Identity Resolution

var orders = context.Orders
    .AsNoTracking()
    .Include(o => o.Customer)
    .ToList();

var sameCustomer = ReferenceEquals(
    orders[0].Customer,
    orders[1].Customer
);

sameCustomer = false

Με Identity Resolution

var orders = context.Orders
    .AsNoTrackingWithIdentityResolution()
    .Include(o => o.Customer)
    .ToList();

var sameCustomer = ReferenceEquals(
    orders[0].Customer,
    orders[1].Customer
);

sameCustomer = true

Πότε έχει νόημα να το χρησιμοποιήσεις;

Το AsNoTrackingWithIdentityResolution() έχει νόημα όταν:

το ίδιο entity μπορεί να εμφανιστεί πολλές φορές μέσα στο ίδιο result set
χρησιμοποιείς Include ή joins
φορτώνεις nested relationships
δεν χρειάζεσαι SaveChanges()
αλλά θέλεις να αποφύγεις duplicate object instances στη μνήμη

Πότε να το αποφύγεις

Μην το χρησιμοποιείς όταν:

Κάνεις απλά flat queries
Δεν έχεις relationships
Δεν σε νοιάζουν duplicate instances

Σε αυτές τις περιπτώσεις:

AsNoTracking() είναι αρκετό και πιο γρήγορο

Συχνό λάθος σε senior επίπεδο

Πολλοί developers χρησιμοποιούν AsNoTracking() παντού για performance, αλλά:

Σε complex graphs μπορεί να δημιουργήσεις:

duplicate objects
bugs σε reference comparisons
περίεργη συμπεριφορά σε mapping

Στην πράξη, ένα συνηθισμένο guideline είναι:

CRUD/update scenarios → AsTracking()
Read-only simple queries → AsNoTracking()
Read-only queries με Includes ή repeated entities → AsNoTrackingWithIdentityResolution()

Η σωστή επιλογή εξαρτάται πάντα από:

το shape των δεδομένων,
το query size,
τα relationships,
και το αν χρειάζεται persistence μέσω SaveChanges().

Γιατί το AsNoTracking() είναι πιο αποδοτικό

Σημαντικό: όταν χρησιμοποιείς projections (Select σε DTOs ή anonymous types), το tracking συνήθως δεν έχει νόημα, γιατί τα αποτελέσματα δεν είναι tracked entity instances.

Το AsNoTracking() είναι συνήθως πιο αποδοτικό σε read-only queries, γιατί το EF Core δεν χρειάζεται να αποθηκεύσει τα entities στο Change Tracker.

Αυτό σημαίνει λιγότερο overhead σε:

memory usage
change detection
object state management
DbContext internal bookkeeping

Το όφελος γίνεται πιο εμφανές όταν το query επιστρέφει πολλά rows ή όταν το DbContext εκτελεί πολλά read-only queries.

Το σημαντικότερο είναι να καταλάβεις ότι το tracking δεν είναι “καλό” ή “κακό”. Είναι μηχανισμός με συγκεκριμένο κόστος και συγκεκριμένο σκοπό.

Το σωστό ερώτημα δεν είναι:
“να βάλω AsNoTracking παντού;”

Αλλά:
“χρειάζομαι πραγματικά change tracking σε αυτό το query;”

Συμπέρασμα

Το AsNoTrackingWithIdentityResolution() είναι ένα advanced εργαλείο που γεφυρώνει το κενό ανάμεσα σε performance και συνέπεια δεδομένων στη μνήμη.

Δεν είναι τόσο γνωστό όσο τα άλλα δύο modes, αλλά σε πραγματικά production συστήματα μπορεί να κάνει τεράστια διαφορά, ειδικά όταν δουλεύεις με σύνθετα object graphs.

Ένας έμπειρος developer δεν επιλέγει απλά tracking ή όχι. Καταλαβαίνει το shape των δεδομένων του και επιλέγει το κατάλληλο εργαλείο για το συγκεκριμένο πρόβλημα.

Και αυτό είναι που ξεχωρίζει τον καλό κώδικα από τον production-grade κώδικα.

Το σωστό mode δεν επιλέγεται με βάση το “τι είναι πιο γρήγορο”, αλλά με βάση το τι lifecycle και behavior χρειάζονται πραγματικά τα δεδομένα σου.

nikosstit@gmail.com

Specification Pattern υπό το πρίσμα του SOLID και της Clean Architecture

nikosst — Wed, 25 Mar 2026 18:24:21 +0000

Η εξέλιξη της μηχανικής λογισμικού τις τελευταίες δεκαετίες έχει καταδείξει ότι το βασικό πρόβλημα δεν είναι η υλοποίηση μιας λύσης, αλλά η διατήρησή της στο χρόνο. Συστήματα που αρχικά φαίνονται απλά, καταλήγουν να γίνονται εύθραυστα καθώς αυξάνεται η πολυπλοκότητα και οι απαιτήσεις μεταβάλλονται. Σε αυτό το πλαίσιο, αρχές όπως το SOLID και προσεγγίσεις όπως η Clean Architecture δεν αποτελούν θεωρητικές πολυτέλειες, αλλά θεμέλια για βιώσιμο λογισμικό.

Η χρήση design patterns εντάσσεται ακριβώς σε αυτή τη φιλοσοφία. Τα patterns δεν είναι έτοιμες λύσεις προς μηχανική εφαρμογή, αλλά αφαιρετικά εργαλεία που ενσωματώνουν δοκιμασμένες αρχές σχεδίασης. Ένα από τα patterns που συνδέονται άμεσα με τις αρχές του SOLID και ενσωματώνονται φυσικά σε μια Clean Architecture προσέγγιση είναι το Specification Pattern.

Η βασική ιδέα του Specification Pattern είναι η απομόνωση της επιχειρησιακής λογικής που αφορά κανόνες και φίλτρα σε ανεξάρτητα, συνθέσιμα αντικείμενα. Στο πλαίσιο της Clean Architecture, αυτή η λογική ανήκει στον πυρήνα του domain και δεν πρέπει να εξαρτάται από εξωτερικές υποδομές, όπως βάσεις δεδομένων ή frameworks. Με άλλα λόγια, οι προδιαγραφές αποτελούν μέρος της “καρδιάς” του συστήματος.

Αν εξετάσουμε το πρόβλημα χωρίς τη χρήση του pattern, συχνά παρατηρούμε repositories ή services να περιέχουν πολύπλοκα φίλτρα, ενσωματωμένα είτε σε queries είτε σε αλγοριθμική λογική. Αυτό οδηγεί σε παραβίαση του Single Responsibility Principle, καθώς οι ίδιες κλάσεις αναλαμβάνουν τόσο την πρόσβαση στα δεδομένα όσο και την επιχειρησιακή λογική των φίλτρων. Επιπλέον, κάθε νέα απαίτηση οδηγεί σε τροποποίηση υπαρχόντων μεθόδων, παραβιάζοντας το Open/Closed Principle.

Το Specification Pattern επαναφέρει τη δομή. Ξεκινάμε από έναν αφηρημένο ορισμό:

public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

Αυτή η διεπαφή ενσαρκώνει μια καθαρή ευθύνη, τον έλεγχο μιας συνθήκης. Δεν γνωρίζει τίποτα για το πού προέρχονται τα δεδομένα ούτε για το πώς θα χρησιμοποιηθεί το αποτέλεσμα. Αυτό ευθυγραμμίζεται πλήρως με τη φιλοσοφία της Clean Architecture, όπου τα domain components είναι ανεξάρτητα από εξωτερικές ανησυχίες.

Ας θεωρήσουμε ένα domain μοντέλο Product:

public class Product
{
public decimal Price { get; set; }
public bool IsActive { get; set; }
}

Αντί να ενσωματώσουμε τη λογική φίλτρων σε repositories, δημιουργούμε ανεξάρτητες προδιαγραφές:

public class ActiveProductSpecification : ISpecification<Product>
{
    public bool IsSatisfiedBy(Product product)
    {
        return product.IsActive;
    }
}

public class PriceSpecification : ISpecification<Product>
{
    private readonly decimal _maxPrice;

    public PriceSpecification(decimal maxPrice)
    {
        _maxPrice = maxPrice;
    }

    public bool IsSatisfiedBy(Product product)
    {
        return product.Price <= _maxPrice;
    }
}

Σε αυτό το σημείο, είναι εμφανής η εφαρμογή του Single Responsibility Principle. Κάθε κλάση εκφράζει έναν και μόνο κανόνα. Παράλληλα, η προσθήκη νέων κανόνων δεν απαιτεί τροποποίηση των υπαρχόντων, αλλά μόνο επέκταση του συστήματος με νέες υλοποιήσεις, ικανοποιώντας το Open/Closed Principle.

Η πραγματική δύναμη του pattern, ωστόσο, αναδεικνύεται μέσω της σύνθεσης. Σε ένα σύστημα που ακολουθεί Clean Architecture, η σύνθεση της επιχειρησιακής λογικής είναι κρίσιμη για την αποφυγή επανάληψης και τη διατήρηση καθαρών ορίων μεταξύ των layers.

public class AndSpecification<T> : ISpecification<T>
{
    private readonly ISpecification<T> _left;
    private readonly ISpecification<T> _right;

    public AndSpecification(ISpecification<T> left, ISpecification<T> right)
    {
        _left = left;
        _right = right;
    }

    public bool IsSatisfiedBy(T entity)
    {
        return _left.IsSatisfiedBy(entity) && _right.IsSatisfiedBy(entity);
    }
}

Η παραπάνω υλοποίηση εισάγει μια σημαντική ιδιότητα, τη δυνατότητα σύνθεσης συμπεριφορών χωρίς τροποποίηση υπαρχόντων κλάσεων. Αυτό συνδέεται άμεσα με το Liskov Substitution Principle, καθώς κάθε σύνθετη προδιαγραφή μπορεί να χρησιμοποιηθεί όπου αναμένεται μια βασική ISpecification, και με το Dependency Inversion Principle, αφού η εξάρτηση γίνεται από αφαιρέσεις και όχι από συγκεκριμένες υλοποιήσεις.

Σε επίπεδο εφαρμογής, η χρήση των specifications επιτρέπει την αποσύνδεση του domain από το infrastructure. Ένα repository μπορεί να δεχθεί μια ISpecification ως παράμετρο, χωρίς να γνωρίζει τις λεπτομέρειες της:

public IEnumerable<Product> GetProducts(ISpecification<Product> specification)
{
    return _products.Where(p => specification.IsSatisfiedBy(p));
}

Με αυτόν τον τρόπο, το repository παραμένει απλό και επικεντρωμένο στην ευθύνη του, ενώ η επιχειρησιακή λογική μεταφέρεται πλήρως στο domain layer. Σε πιο εξελιγμένες υλοποιήσεις, η ISpecification μπορεί να επεκταθεί ώστε να εκφράζει και expression trees, επιτρέποντας τη μεταφορά της ίδιας λογικής σε επίπεδο βάσης δεδομένων, χωρίς παραβίαση των αρχών της αρχιτεκτονικής.

Αξίζει να σημειωθεί ότι το Specification Pattern ενισχύει και τη δοκιμασιμότητα του συστήματος. Καθώς κάθε κανόνας είναι απομονωμένος, μπορεί να ελεγχθεί ανεξάρτητα με unit tests, χωρίς την ανάγκη για mocking πολύπλοκων εξαρτήσεων. Αυτό συνάδει με τη φιλοσοφία της Clean Architecture, όπου ο πυρήνας του συστήματος πρέπει να είναι πλήρως ελέγξιμος.

Ωστόσο, όπως κάθε αφαιρετική τεχνική, απαιτεί μέτρο. Σε απλά σενάρια, η εισαγωγή πολλών specifications μπορεί να οδηγήσει σε περιττή πολυπλοκότητα. Η αξία του pattern αναδεικνύεται σε συστήματα με πλούσια domain λογική, όπου οι κανόνες μεταβάλλονται συχνά και απαιτείται υψηλός βαθμός επαναχρησιμοποίησης.

Συνοψίζοντας, το Specification Pattern δεν είναι απλώς ένας τρόπος να γράφουμε φίλτρα. Είναι μια αρχιτεκτονική επιλογή που εναρμονίζεται με τις αρχές του SOLID και ενσωματώνεται οργανικά στη Clean Architecture. Επιτρέπει τη σαφή οριοθέτηση της επιχειρησιακής λογικής, ενισχύει την επεκτασιμότητα και καθιστά το σύστημα πιο ανθεκτικό στις αλλαγές. Σε ένα περιβάλλον όπου η πολυπλοκότητα είναι αναπόφευκτη, τέτοιες προσεγγίσεις αποτελούν βασικά εργαλεία για τη δημιουργία ποιοτικού και διαχρονικού λογισμικού.

nikosstit@gmail.com

Asynchronous Programming στην C#: Θεμελιώδεις Αρχές, Κανόνες και Βαθιά Κατανόηση

nikosst — Mon, 23 Mar 2026 23:36:40 +0000

Εισαγωγή

Ο ασύγχρονος προγραμματισμός στην C# αποτελεί ένα από τα πιο ισχυρά εργαλεία για την ανάπτυξη σύγχρονων εφαρμογών, ιδιαίτερα σε περιβάλλοντα όπου η απόδοση, η κλιμάκωση και η αποδοτική χρήση των πόρων είναι κρίσιμες απαιτήσεις. Παρ’ όλα αυτά, η ευκολία με την οποία εισάγεται το async και το await στη σύνταξη της γλώσσας δημιουργεί συχνά μια ψευδαίσθηση απλότητας. Πολλοί προγραμματιστές χρησιμοποιούν τα εργαλεία αυτά χωρίς να έχουν κατανοήσει πλήρως τη λειτουργία τους, με αποτέλεσμα να εισάγουν σφάλματα που είναι δύσκολο να εντοπιστούν και ακόμη πιο δύσκολο να διορθωθούν.

Στην πραγματικότητα, το asynchronous programming δεν είναι απλώς ένα διαφορετικό στυλ γραφής κώδικα, αλλά μια διαφορετική φιλοσοφία εκτέλεσης. Δεν στοχεύει απαραίτητα στο να κάνει τον κώδικα πιο γρήγορο με την έννοια της μείωσης του χρόνου εκτέλεσης, αλλά στο να επιτρέπει στο σύστημα να εκμεταλλεύεται καλύτερα τους διαθέσιμους πόρους του, αποφεύγοντας την άσκοπη δέσμευση νημάτων (threads). Η κατανόηση αυτής της διάκρισης είναι θεμελιώδης για την ορθή χρήση των μηχανισμών async/await.

Στο παρόν κείμενο θα αναλυθούν δέκα βασικοί κανόνες, οι οποίοι έχουν προκύψει μέσα από πραγματική εμπειρία ανάπτυξης λογισμικού σε παραγωγικά συστήματα. Για κάθε κανόνα θα παρουσιαστεί ένα αντιπαράδειγμα, η ορθή προσέγγιση και, κυρίως, η ερμηνεία του γιατί η σωστή πρακτική είναι αναγκαία.

1. Αποφυγή μπλοκαρίσματος ασύγχρονου κώδικα

Ένα από τα πιο συνηθισμένα λάθη είναι η χρήση των ιδιοτήτων .Result ή .Wait() σε ασύγχρονες μεθόδους. Εξετάζοντας το παρακάτω παράδειγμα:

public string GetData()
{
    return GetDataAsync().Result;
}

παρατηρούμε ότι η μέθοδος GetData καλεί μια ασύγχρονη λειτουργία, αλλά επιλέγει να περιμένει συγχρονισμένα το αποτέλεσμά της. Το πρόβλημα δεν είναι απλώς αισθητικό· αφορά τον ίδιο τον τρόπο λειτουργίας του runtime. Όταν η GetDataAsync φτάσει σε ένα await, προσπαθεί να συνεχίσει την εκτέλεσή της στο ίδιο thread. Ωστόσο, το thread αυτό είναι ήδη δεσμευμένο από την αναμονή της .Result. Δημιουργείται έτσι μια κατάσταση αδιεξόδου (deadlock), όπου καμία από τις δύο πλευρές δεν μπορεί να προχωρήσει.

Η σωστή προσέγγιση είναι η πλήρης διατήρηση της ασύγχρονης ροής:

public async Task<string> GetData()
{
    return await GetDataAsync();
}

Η σημασία αυτού του κανόνα είναι ιδιαίτερα εμφανής σε περιβάλλοντα όπως το ASP.NET, όπου ένα μπλοκαρισμένο thread μπορεί να οδηγήσει σε εξάντληση των διαθέσιμων πόρων και, τελικά, σε μη ανταποκρινόμενες εφαρμογές.

2. Αποφυγή της χρήσης async void

Η χρήση της επιστροφής async void πρέπει να αποφεύγεται σχεδόν καθολικά. Ένα παράδειγμα:

public async void Save()
{
    await SaveToDatabase();
}

μπορεί να φαίνεται ακίνδυνο, αλλά κρύβει σοβαρούς κινδύνους. Μια μέθοδος που επιστρέφει void δεν επιτρέπει στον καλούντα να περιμένει την ολοκλήρωσή της ούτε να διαχειριστεί εξαιρέσεις που μπορεί να προκύψουν. Σε περίπτωση αποτυχίας, η εξαίρεση δεν μεταφέρεται με ελεγχόμενο τρόπο, αλλά διαχέεται στο runtime.

Η προτιμητέα μορφή είναι:

public async Task Save()
{
    await SaveToDatabase();
}

Η επιστροφή Task λειτουργεί ως συμβόλαιο που επιτρέπει στον καλούντα να ελέγξει τη ροή εκτέλεσης και να διαχειριστεί πιθανά σφάλματα.

3. Εκτέλεση ανεξάρτητων εργασιών παράλληλα

Ένα άλλο συχνό λάθος αφορά την εκτέλεση ανεξάρτητων ασύγχρονων λειτουργιών με σειριακό τρόπο:

var user = await GetUser();
var orders = await GetOrders();

Η παραπάνω προσέγγιση οδηγεί σε άσκοπη αναμονή, καθώς η δεύτερη λειτουργία ξεκινά μόνο αφού ολοκληρωθεί η πρώτη. Αν οι λειτουργίες είναι ανεξάρτητες, μπορούν να εκτελεστούν ταυτόχρονα:

var userTask = GetUser();
var ordersTask = GetOrders();

await Task.WhenAll(userTask, ordersTask);

Με αυτόν τον τρόπο, το συνολικό χρονικό κόστος μειώνεται σημαντικά. Η διαφορά αυτή γίνεται κρίσιμη σε εφαρμογές που εκτελούν πολλαπλά εξωτερικά αιτήματα, όπως API calls ή database queries.

4. Αποφυγή χρήσης Task.Run για I/O εργασίες

Η χρήση του Task.Run για την εκτέλεση ασύγχρονων λειτουργιών εισόδου/εξόδου αποτελεί μια παρανόηση της φύσης του async programming. Για παράδειγμα:

await Task.Run(() => File.ReadAllTextAsync("file.txt"));

επιβαρύνει το σύστημα δημιουργώντας ένα νέο thread για μια εργασία που ήδη είναι μη μπλοκαριστική. Οι I/O λειτουργίες δεν απαιτούν dedicated thread κατά την αναμονή τους, καθώς βασίζονται σε μηχανισμούς του λειτουργικού συστήματος.

Η ορθή χρήση είναι απλούστερη:

await File.ReadAllTextAsync("file.txt");

Η αποφυγή άσκοπης δημιουργίας threads συμβάλλει στην αποδοτικότητα και στη σταθερότητα του συστήματος.

5. Χρήση του ConfigureAwait(false) σε βιβλιοθήκες

Η μέθοδος ConfigureAwait(false) επηρεάζει τον τρόπο με τον οποίο συνεχίζεται η εκτέλεση μετά από ένα await. Συγκεκριμένα, αποτρέπει την επιστροφή στο αρχικό synchronization context. Σε βιβλιοθήκες, όπου δεν υπάρχει ανάγκη επιστροφής σε συγκεκριμένο thread, η χρήση του:

await SomeOperation().ConfigureAwait(false);

βελτιώνει την απόδοση και μειώνει την πιθανότητα deadlocks. Η κατανόηση αυτού του μηχανισμού είναι κρίσιμη για την ανάπτυξη επαναχρησιμοποιήσιμων και αποδοτικών components.

Η μέθοδος ConfigureAwait(false) επηρεάζει άμεσα τον τρόπο με τον οποίο συνεχίζεται η εκτέλεση μιας ασύγχρονης μεθόδου μετά από ένα await. Για να κατανοηθεί πλήρως η σημασία της, χρειάζεται πρώτα να δούμε τι συμβαίνει “πίσω από τα φώτα” όταν χρησιμοποιούμε await. Από προεπιλογή, κάθε await καταγράφει το τρέχον Synchronization Context (δηλαδή το περιβάλλον εκτέλεσης, όπως το UI thread ή το request context) και προσπαθεί να επαναφέρει την εκτέλεση σε αυτό μόλις ολοκληρωθεί η ασύγχρονη εργασία. Αυτή η συμπεριφορά είναι ιδιαίτερα χρήσιμη σε εφαρμογές με γραφικό περιβάλλον ή σε περιβάλλοντα όπου η συνέχεια της εκτέλεσης πρέπει να γίνει σε συγκεκριμένο thread.

Ωστόσο, αυτή η “επιστροφή στο αρχικό context” δεν είναι πάντα απαραίτητη. Σε περιπτώσεις όπως οι βιβλιοθήκες (libraries) ή τα backend components, όπου δεν υπάρχει εξάρτηση από συγκεκριμένο thread ή περιβάλλον εκτέλεσης, η διατήρηση του context προσθέτει περιττό κόστος. Συγκεκριμένα, απαιτείται επιπλέον μηχανισμός scheduling για να επανέλθει η εκτέλεση στο αρχικό thread, κάτι που μπορεί να επηρεάσει αρνητικά την απόδοση, ιδιαίτερα σε σενάρια υψηλής κλιμάκωσης.

Με τη χρήση του ConfigureAwait(false), όπως στο παράδειγμα await SomeOperation().ConfigureAwait(false);, δηλώνουμε ρητά ότι δεν μας ενδιαφέρει η επιστροφή στο αρχικό synchronization context. Αυτό επιτρέπει στο runtime να συνεχίσει την εκτέλεση σε οποιοδήποτε διαθέσιμο thread, συνήθως από το thread pool, μειώνοντας έτσι το overhead και βελτιώνοντας τη συνολική αποδοτικότητα της εφαρμογής.

Επιπλέον, η χρήση του ConfigureAwait(false) συμβάλλει στην αποφυγή πιθανών deadlocks. Σε περιβάλλοντα όπου γίνεται συγχρονισμένη αναμονή (π.χ. με .Result ή .Wait()), μπορεί να προκύψει κατάσταση όπου το thread που περιμένει την ολοκλήρωση μιας ασύγχρονης μεθόδου είναι το ίδιο που απαιτείται για να συνεχιστεί η εκτέλεση μετά το await. Αν η συνέχεια προσπαθεί να επιστρέψει σε αυτό το δεσμευμένο thread, δημιουργείται αδιέξοδο. Με το ConfigureAwait(false), η συνέχεια δεν εξαρτάται από το αρχικό context, με αποτέλεσμα να αποφεύγεται αυτό το σενάριο.

Ένα απλό αλλά χαρακτηριστικό παράδειγμα μπορεί να αναδείξει τη διαφορά. Ας υποθέσουμε ότι έχουμε μια μέθοδο σε μια βιβλιοθήκη που καλεί ένα εξωτερικό API:

public async Task<string> GetDataAsync()
{
    var response = await httpClient.GetStringAsync("https://api.example.com/data");
    return response;
}

Σε αυτή τη μορφή, μετά το await, η εκτέλεση θα προσπαθήσει να επιστρέψει στο αρχικό context. Αν αυτή η μέθοδος κληθεί από ένα UI thread ή από κάποιο περιβάλλον με synchronization context, τότε δεσμεύεται άσκοπα σε αυτό.

Η βελτιωμένη εκδοχή για χρήση σε library είναι:

public async Task<string> GetDataAsync()
{
    var response = await httpClient
        .GetStringAsync("https://api.example.com/data")
        .ConfigureAwait(false);

    return response;
}

Εδώ, η μέθοδος δεν ενδιαφέρεται για το πού θα συνεχιστεί η εκτέλεση, καθώς απλώς επιστρέφει δεδομένα χωρίς να αλληλεπιδρά με UI ή context-specific στοιχεία. Αυτό την καθιστά πιο αποδοτική και ασφαλή για επαναχρησιμοποίηση.

Αντίθετα, σε ένα UI παράδειγμα:

public async Task LoadDataAsync()
{
    var data = await GetDataAsync();
    myLabel.Text = data; // χρειάζεται UI thread
}

Σε αυτή την περίπτωση, δεν πρέπει να χρησιμοποιηθεί ConfigureAwait(false) μέσα στη μέθοδο που ενημερώνει το UI, γιατί η συνέχεια πρέπει να εκτελεστεί στο UI thread.

Το βασικό συμπέρασμα είναι ότι το ConfigureAwait(false) ανήκει κυρίως σε επίπεδο βιβλιοθηκών και υποδομής (infrastructure code), όπου δεν υπάρχει ανάγκη επιστροφής σε συγκεκριμένο context. Με αυτόν τον τρόπο, ο κώδικας γίνεται πιο αποδοτικός, πιο ασφαλής ως προς deadlocks και πιο κατάλληλος για χρήση σε διαφορετικά περιβάλλοντα.

Συνοψίζοντας, η κατανόηση και η σωστή χρήση του ConfigureAwait(false) είναι κρίσιμη για την ανάπτυξη αποδοτικών και επαναχρησιμοποιήσιμων components. Επιτρέπει καλύτερο έλεγχο της εκτέλεσης, μειώνει το περιττό κόστος διαχείρισης του context και προστατεύει από δύσκολα εντοπίσιμα προβλήματα συγχρονισμού, καθιστώντας τον κώδικα πιο αξιόπιστο και scalable.

6. Διατήρηση της ασύγχρονης ροής σε όλη την αλυσίδα

Η ανάμιξη συγχρονικού και ασύγχρονου κώδικα οδηγεί συχνά σε προβλήματα. Όταν μια ασύγχρονη μέθοδος καλείται από συγχρονική, η ανάγκη για αναμονή δημιουργεί πίεση προς τη χρήση .Result ή .Wait(), με τα προβλήματα που ήδη αναφέρθηκαν. Η σωστή πρακτική είναι η διατήρηση της ασύγχρονης φύσης σε όλη την αλυσίδα κλήσεων.

7. Ορθή διαχείριση εξαιρέσεων

Η εκτέλεση μιας ασύγχρονης μεθόδου χωρίς await οδηγεί σε μη παρατηρήσιμες εξαιρέσεις:

DoWorkAsync();

Σε αυτή την περίπτωση, αν η μέθοδος αποτύχει, η εξαίρεση δεν θα διαχειριστεί στο σημείο που αναμένεται. Αντίθετα, η χρήση του await εξασφαλίζει ότι η εξαίρεση θα προκύψει στο σωστό σημείο της ροής και θα μπορεί να αντιμετωπιστεί κατάλληλα.

8. Αποφυγή άσκοπης χρήσης του async

Η δήλωση μιας μεθόδου ως async χωρίς την ύπαρξη await προκαλεί περιττό overhead. Ο compiler δημιουργεί έναν state machine που δεν είναι απαραίτητος. Σε τέτοιες περιπτώσεις, η επιστροφή ενός ήδη ολοκληρωμένου Task είναι προτιμότερη.

9. Υποστήριξη ακύρωσης μέσω CancellationToken

Η δυνατότητα ακύρωσης είναι κρίσιμη σε πραγματικά συστήματα. Ένας χρήστης μπορεί να εγκαταλείψει μια ενέργεια ή ένα request μπορεί να λήξει. Η ενσωμάτωση ενός CancellationToken επιτρέπει τον έλεγχο της εκτέλεσης και την αποφυγή άσκοπης κατανάλωσης πόρων.

10. Αποφυγή αναμονής μέσα σε επαναλήψεις

Η χρήση του await μέσα σε loops οδηγεί σε σειριακή εκτέλεση:

foreach (var item in items)
{
    await Process(item);
}

Όταν οι εργασίες είναι ανεξάρτητες, η μετατροπή τους σε συλλογή από tasks και η χρήση του Task.WhenAll επιτρέπει την παράλληλη εκτέλεση, βελτιώνοντας σημαντικά την απόδοση.

Συμπέρασμα

Ο ασύγχρονος προγραμματισμός στην C# δεν αποτελεί απλώς μια τεχνική βελτιστοποίησης, αλλά έναν θεμελιώδη τρόπο σχεδίασης συστημάτων. Η ορθή χρήση του απαιτεί κατανόηση του τρόπου με τον οποίο διαχειρίζεται το runtime τα threads, τα tasks και τη ροή εκτέλεσης.

Η διαφορά μεταξύ ενός αρχάριου και ενός έμπειρου προγραμματιστή δεν έγκειται στη γνώση της σύνταξης, αλλά στην ικανότητα πρόβλεψης της συμπεριφοράς του συστήματος. Ένας έμπειρος developer αναρωτιέται συνεχώς αν ένας πόρος δεσμεύεται άσκοπα, αν μια εργασία μπορεί να εκτελεστεί παράλληλα ή αν μια εξαίρεση μπορεί να χαθεί.

Η εμβάθυνση στους παραπάνω κανόνες οδηγεί όχι μόνο σε πιο αποδοτικό κώδικα, αλλά και σε πιο αξιόπιστα και επεκτάσιμα συστήματα. Τελικά, ο στόχος δεν είναι απλώς η δημιουργία κώδικα που λειτουργεί, αλλά η ανάπτυξη λύσεων που παραμένουν σταθερές, κατανοητές και αποδοτικές σε βάθος χρόνου.

nikosstit@gmail.com

Helper Classes vs Extension Methods

nikosst — Thu, 19 Mar 2026 21:31:55 +0000

Ποια είναι η διαφορά και πότε χρησιμοποιείς το καθένα

Στην καθημερινή ανάπτυξη λογισμικού, πολύ συχνά θα βρεθείς να γράφεις “βοηθητικό” κώδικα. Δηλαδή μικρές λειτουργίες που δεν ανήκουν ξεκάθαρα σε ένα domain object, αλλά χρειάζονται ξανά και ξανά.

Εδώ εμφανίζονται δύο βασικά patterns:

Helper Classes
Extension Methods

Πολλοί τα μπερδεύουν ή τα χρησιμοποιούν τυχαία. Όμως η διαφορά τους δεν είναι τεχνική λεπτομέρεια, είναι θέμα καθαρότητας, αναγνωσιμότητας και επικοινωνίας μέσω κώδικα.

Και αυτό είναι το πιο σημαντικό.

Helper Classes

Τι είναι

Μια helper class είναι απλά μια static class που περιέχει βοηθητικές μεθόδους.

Δεν “ανήκει” σε κάποιο object. Είναι ένα εξωτερικό εργαλείο.

Παράδειγμα 1: String Helper

public static class StringHelper
{
    public static bool IsNullOrShort(string text)
    {
        return string.IsNullOrEmpty(text) || text.Length < 5;
    }
}

Χρήση:

string name = "Nikos";

if (StringHelper.IsNullOrShort(name))
{
    Console.WriteLine("Invalid name");
}

Τι συμβαίνει εδώ

Έχω ένα string
Θέλω να κάνω κάτι με αυτό
Πάω σε μια άλλη class για να το κάνω

Δηλαδή: φεύγεις από το object

Παράδειγμα 2: Date Helper

public static class DateHelper
{
    public static bool IsWeekend(DateTime date)
    {
        return date.DayOfWeek == DayOfWeek.Saturday ||
               date.DayOfWeek == DayOfWeek.Sunday;
    }
}

Χρήση:

if (DateHelper.IsWeekend(DateTime.Now))
{
    Console.WriteLine("Relax!");
}

Πλεονεκτήματα

Απλό και ξεκάθαρο
Μαζεύεις utilities σε ένα μέρος
Δεν “πειράζεις” υπάρχουσες classes

Μειονεκτήματα

Δεν είναι intuitive
Δεν διαβάζεται φυσικά
Μεγαλώνει εύκολα και γίνεται “dumping ground”

Extension Methods

Τι είναι

Extension methods σου επιτρέπουν να “προσθέσεις” μεθόδους σε υπάρχουσες classes χωρίς να τις αλλάξεις.

Παράδειγμα 1: String Extension

public static class StringExtensions
{
    public static bool IsNullOrShort(this string text)
    {
        return string.IsNullOrEmpty(text) || text.Length < 5;
    }
}

Χρήση:

string name = "Nikos";

if (name.IsNullOrShort())
{
    Console.WriteLine("Invalid name");
}

Τι αλλάζει εδώ;

Αντί να λες:

“πάω στο helper”

λες:

“το ίδιο το string ξέρει να το κάνει”

Παράδειγμα 2: Date Extension

public static class DateExtensions
{
    public static bool IsWeekend(this DateTime date)
    {
        return date.DayOfWeek == DayOfWeek.Saturday ||
               date.DayOfWeek == DayOfWeek.Sunday;
    }
}

Χρήση:

if (DateTime.Now.IsWeekend())
{
    Console.WriteLine("Relax!");
}

Πώς το “βρίσκει” ο compiler

Εδώ βρίσκεται όλη η “μαγεία”, που στην πραγματικότητα δεν είναι μαγεία αλλά ένας πολύ συγκεκριμένος μηχανισμός του compiler.

Όταν γράφεις name.IsNullOrShort(), ο compiler ΔΕΝ ψάχνει μόνο μέσα στο string για τη μέθοδο. Αν δεν τη βρει εκεί, κάνει ένα δεύτερο βήμα: κοιτάει όλα τα extension methods που είναι διαθέσιμα μέσω των using statements στο αρχείο σου.

Δηλαδή, σκανάρει τα static classes στα namespaces που έχεις κάνει import και ψάχνει για μεθόδους που έχουν this string ως πρώτο parameter.

Μόλις βρει μια που ταιριάζει, τη “μεταφράζει” εσωτερικά σε κανονική static κλήση, π.χ. StringExtensions.IsNullOrShort(name).

Αν δεν υπάρχει το σωστό using, η μέθοδος απλά δεν υπάρχει για τον compiler γι’ αυτό και πολλές φορές “ξαφνικά” δουλεύει μόλις προσθέσεις ένα namespace.

Με λίγα λόγια, ο compiler δεν αλλάζει το string· απλά σου δίνει έναν πιο φυσικό τρόπο να καλέσεις μια κανονική static μέθοδο.

Παράδειγμα: Πώς ο compiler βρίσκει (ή δεν βρίσκει) το extension

Ορίζεις το extension

namespace MyProject.Extensions
{
    public static class StringExtensions
    {
        public static bool IsNullOrShort(this string text)
        {
            return string.IsNullOrEmpty(text) || text.Length < 5;
        }
    }
}

Περίπτωση Α: ΧΩΡΙΣ using

string name = "Nikos";

bool result = name.IsNullOrShort(); //Compile error

Error:
string does not contain a definition for 'IsNullOrShort'

Γιατί;
Ο compiler δεν βλέπει το extension, γιατί δεν έχεις κάνει import το namespace.

Περίπτωση Β: ΜΕ using

using MyProject.Extensions;

string name = "Nikos";

bool result = name.IsNullOrShort(); // Works

Τι έγινε εδώ;

Ο compiler δεν βρίσκει τη μέθοδο στο string
Κοιτάει στα extensions του namespace
Βρίσκει:

public static bool IsNullOrShort(this string text)

Και το μετατρέπει σε:

StringExtensions.IsNullOrShort(name);

Απόδειξη ότι είναι το ίδιο

using MyProject.Extensions;

string name = "Nikos";

bool a = name.IsNullOrShort();
bool b = StringExtensions.IsNullOrShort(name);

Τα a και b είναι ακριβώς το ίδιο πράγμα

Το extension method:

δεν ανήκει πραγματικά στο string
δεν αλλάζει την class
απλά γίνεται “ορατό” μέσω using
και ο compiler το μετατρέπει σε static call

Η Πραγματική Διαφορά

Δεν είναι θέμα “τι κάνει”, αλλά πώς διαβάζεται.

Σύγκριση

Helper:

if (StringHelper.IsNullOrShort(name))

Extension:

if (name.IsNullOrShort())

Πότε χρησιμοποιείς τι

Χρησιμοποίησε Extension Methods όταν:

Η λειτουργία σχετίζεται ξεκάθαρα με το object
Θες readable / fluent code
Θες να γράφεις “σαν πρόταση”

Παραδείγματα:

string.IsValidEmail()
date.IsWeekend()
list.IsEmpty()

Χρησιμοποίησε Helper Class όταν:

Η λειτουργία είναι γενική
Δεν ανήκει σε ένα object
Έχεις logic που χρησιμοποιεί πολλά types

Παράδειγμα:

public static class MathHelper
{
    public static int Add(int a, int b)
    {
        return a + b;
    }
}

Δεν έχει νόημα:

a.Add(b)

Να θυμάσαι..

Η διαφορά δεν είναι τεχνική, είναι νοητική.

Helper Class
εργαλείο έξω από το object

Extension Method
συμπεριφορά πάνω στο object

nikosstit@gmail.com

Από Static Classes σε Services με Dependency Injection Με οπτική Clean Architecture (layers & boundaries)

nikosst — Wed, 18 Mar 2026 16:19:37 +0000

Εισαγωγή

Οι static classes είναι από τα πρώτα εργαλεία που χρησιμοποιεί ένας developer. Είναι απλές, άμεσες και δεν απαιτούν ιδιαίτερη υποδομή. Για μικρές λειτουργίες ή βοηθητικό κώδικα, συχνά φαίνονται η πιο σωστή επιλογή.

Όσο όμως ένα σύστημα μεγαλώνει, οι ίδιες αυτές επιλογές αρχίζουν να δημιουργούν περιορισμούς. Ο κώδικας γίνεται πιο δύσκολος να δοκιμαστεί, οι εξαρτήσεις κρύβονται και η ευελιξία μειώνεται.

Σε αυτό το σημείο μπαίνουν τα services και το dependency injection. Όχι απλά ως τεχνική, αλλά ως τρόπος να οργανώσεις τον κώδικά σου με τρόπο που να αντέχει στον χρόνο.

Το πραγματικό τους value όμως δεν φαίνεται μόνο σε επίπεδο κλάσης. Φαίνεται όταν τα εντάξεις σωστά μέσα σε αρχιτεκτονικά layers. Εκεί είναι που η διαφορά μεταξύ “κώδικας που απλά δουλεύει” και “κώδικας που μπορεί να εξελιχθεί” γίνεται ξεκάθαρη.

Τι αλλάζει όταν μπαίνουμε σε Clean Architecture

Στην Clean Architecture δεν μας ενδιαφέρει απλά να γράψουμε services. Μας ενδιαφέρει πού ανήκουν και ποιος εξαρτάται από ποιον.

Η βασική ιδέα είναι ότι το σύστημα χωρίζεται σε layers με ξεκάθαρα boundaries. Το domain βρίσκεται στο κέντρο και δεν εξαρτάται από τίποτα. Τα εξωτερικά layers εξαρτώνται από το domain, όχι το αντίστροφο.

Αυτό σημαίνει ότι οι αποφάσεις που παίρνεις για static ή service δεν είναι πλέον τοπικές. Είναι αρχιτεκτονικές.

Πού “σπάνε” οι static classes μέσα σε layers

Αν χρησιμοποιήσεις static classes μέσα σε ένα layered σύστημα, αρχίζεις να παραβιάζεις boundaries χωρίς να το καταλάβεις.

Φαντάσου ότι έχεις μια static class που καλεί database ή κάνει HTTP calls. Αν αυτή χρησιμοποιείται μέσα στο domain layer, τότε το domain σου εξαρτάται άμεσα από infrastructure. Έχεις σπάσει την αρχιτεκτονική χωρίς να φαίνεται ξεκάθαρα στο code.

Αυτό είναι επικίνδυνο γιατί το dependency είναι κρυφό. Δεν φαίνεται από constructor ή interface. Είναι “σκληρά γραμμένο” μέσα στη static κλήση.

Με services και interfaces, αυτή η εξάρτηση γίνεται explicit και μπορείς να τη μετακινήσεις στο σωστό layer.

Πώς τοποθετούνται τα services στα layers

Σε ένα Clean Architecture setup, τα services δεν είναι όλα ίδια. Παίζουν διαφορετικούς ρόλους ανά layer.

Στο domain layer έχεις business rules. Εκεί δεν θέλεις concrete implementations. Θέλεις abstractions. Αν χρειάζεται κάτι εξωτερικό, το εκφράζεις ως interface.

Στο application layer orchestrate τη ροή. Εκεί χρησιμοποιείς services για να εκτελέσεις use cases. Τα dependencies έρχονται μέσω interfaces.

Στο infrastructure layer υλοποιείς τα interfaces. Εκεί μπαίνουν database, API clients, email senders και οτιδήποτε εξωτερικό.

Αν είχες static classes, δεν θα μπορούσες να κάνεις αυτόν τον διαχωρισμό. Θα είχες άμεσες κλήσεις από παντού προς παντού.

Παράδειγμα μέσα σε Clean Architecture

Ας πούμε ότι έχεις logic για αποστολή email.

Με static approach:

public static class EmailHelper
{
    public static void Send(string message)
    {
        // SMTP logic εδώ
    }
}

Αν αυτό χρησιμοποιηθεί μέσα στο domain ή στο application layer, έχεις ήδη δέσει το σύστημα σου με συγκεκριμένη υλοποίηση.

Με Clean Architecture προσέγγιση:

Στο domain ή application layer:

public interface IEmailService
{
    void Send(string message);
}

Στο infrastructure layer:

public class SmtpEmailService : IEmailService
{
    public void Send(string message)
    {
        // SMTP logic εδώ
    }
}

Και το injection γίνεται από έξω. Το domain δεν γνωρίζει τίποτα για SMTP, ούτε για implementation details.

Αυτό είναι το κλειδί. Δεν σε νοιάζει πώς στέλνεται το email. Σε νοιάζει ότι στέλνεται.

Πώς το lifecycle συνδέεται με τα layers

Το lifecycle των services αποκτά μεγαλύτερη σημασία μέσα σε Clean Architecture.

Τα infrastructure services συχνά σχετίζονται με resources. Database connections, HTTP clients, caches. Εκεί πρέπει να είσαι προσεκτικός με το αν θα είναι scoped ή singleton.

Τα application services είναι συνήθως stateless και μπορούν να είναι transient ή scoped.

Το domain δεν πρέπει να γνωρίζει τίποτα για lifecycle. Αυτό είναι ευθύνη του outer layer.

Αυτός ο διαχωρισμός είναι αδύνατος με static classes, γιατί δεν υπάρχει lifecycle. Όλα είναι global και πάντα διαθέσιμα.

Πώς καταλαβαίνεις ότι η static class “παραβιάζει” την αρχιτεκτονική

Σε ένα Clean Architecture σύστημα, το πιο σημαντικό σήμα είναι το εξής:

Αν μια static class σε αναγκάζει να κάνεις import κάτι από infrastructure μέσα σε domain ή application, τότε έχεις ήδη πρόβλημα.

Ένα άλλο σημάδι είναι όταν δεν μπορείς να αλλάξεις implementation χωρίς να πειράξεις πολλά σημεία στο σύστημα. Αυτό σημαίνει ότι δεν έχεις abstraction, αλλά direct dependency.

Επίσης, αν δεις ότι η static class αρχίζει να μεγαλώνει και να συγκεντρώνει logic από διαφορετικά concerns, τότε έχεις χάσει το separation of concerns.

Τα θετικά και τα αρνητικά μέσα σε Clean Architecture

Μέσα σε ένα layered σύστημα, τα services γίνονται σχεδόν απαραίτητα. Δεν είναι απλά πιο “καλά”. Είναι ο μόνος τρόπος να κρατήσεις τα boundaries καθαρά.

Το μεγάλο πλεονέκτημα είναι ότι μπορείς να αλλάξεις implementation χωρίς να επηρεάσεις το core. Μπορείς να κάνεις testing χωρίς εξωτερικά dependencies. Μπορείς να εξελίξεις το σύστημα χωρίς να “σπάσεις” υπάρχουσα λειτουργικότητα.

Το κόστος είναι ότι αυξάνεται η πολυπλοκότητα. Έχεις περισσότερα abstractions, περισσότερα αρχεία και περισσότερη “έμμεση” ροή. Αυτό όμως είναι ελεγχόμενη πολυπλοκότητα. Δεν είναι χάος, είναι δομή.

Οι static classes σε αυτό το περιβάλλον φαίνονται απλές, αλλά στην πράξη δημιουργούν αόρατες συνδέσεις μεταξύ layers. Αυτές οι συνδέσεις είναι που τελικά κάνουν ένα σύστημα δύσκολο να συντηρηθεί.

Πότε πρέπει να μετατρέψεις static σε service μέσα σε Clean Architecture

Η πιο κρίσιμη στιγμή για refactor έρχεται όταν η static class αρχίζει να “τραβάει” προς τα έξω layers. Αν βλέπεις ότι μέσα σε static logic μπαίνει database access, HTTP calls ή configuration, τότε έχεις ήδη περάσει το όριο.

Ένα δεύτερο σημείο είναι όταν θέλεις να αλλάξεις implementation χωρίς να επηρεάσεις τον πυρήνα της εφαρμογής. Αν αυτό δεν γίνεται εύκολα, τότε σημαίνει ότι δεν έχεις abstraction και η static class σε κρατάει πίσω.

Ένα τρίτο, πιο ώριμο κριτήριο, είναι όταν το domain σου αρχίζει να “ξέρει πολλά”. Αν το domain γνωρίζει λεπτομέρειες για το πώς δουλεύουν εξωτερικά συστήματα, τότε η αρχιτεκτονική έχει διαρρεύσει. Εκεί η λύση δεν είναι απλά refactor. Είναι επανατοποθέτηση της ευθύνης μέσω services και interfaces.

Πότε παραμένει σωστή επιλογή η static class

Ακόμα και μέσα σε Clean Architecture, οι static classes έχουν θέση. Δεν είναι κάτι που πρέπει να εξαφανιστεί.

Όταν έχεις καθαρή, deterministic λογική, χωρίς καμία εξάρτηση και χωρίς καμία πιθανότητα να αλλάξει, η static class είναι η πιο καθαρή λύση. Μαθηματικοί υπολογισμοί, απλά transformations, pure functions είναι ιδανικές περιπτώσεις.

Η διαφορά είναι ότι αυτές οι static κλάσεις δεν “αγγίζουν” τα layers. Δεν δημιουργούν dependencies. Είναι απομονωμένες και ασφαλείς.

Το τελικό mental model

Αν το δεις συνολικά, η απόφαση δεν είναι τεχνική αλλά αρχιτεκτονική.

Ό,τι ανήκει στον πυρήνα του συστήματος και μπορεί να αλλάξει, πρέπει να προστατεύεται πίσω από abstractions. Εκεί χρησιμοποιείς services και dependency injection.

Ό,τι είναι απλό, σταθερό και χωρίς εξαρτήσεις, μπορεί να παραμείνει static χωρίς κανένα πρόβλημα.

Η Clean Architecture δεν σου λέει “μην χρησιμοποιείς static”. Σου λέει “πρόσεχε τα boundaries”. Και τα services είναι ο μηχανισμός που σου επιτρέπει να τα τηρήσεις.

Συμπέρασμα

Η μετάβαση από static classes σε services είναι στην ουσία μετάβαση από ad-hoc κώδικα σε σχεδιασμένο σύστημα. Όταν τη δεις μέσα από το πρίσμα της Clean Architecture, γίνεται ξεκάθαρο ότι δεν είναι απλά θέμα καλής πρακτικής, αλλά θέμα επιβίωσης του codebase όσο μεγαλώνει.

Οι static classes είναι χρήσιμες όταν ο κόσμος σου είναι μικρός και ελεγχόμενος. Τα services είναι απαραίτητα όταν ο κόσμος σου αρχίζει να μεγαλώνει και να αποκτά πολυπλοκότητα.

Ο στόχος δεν είναι να αποφύγεις τα static ή να γεμίσεις το σύστημα με services. Ο στόχος είναι να ξέρεις πού ανήκει το κάθε πράγμα και να το τοποθετείς σωστά.

Και αυτή είναι, τελικά, η διαφορά ανάμεσα στο να γράφεις κώδικα και στο να σχεδιάζεις συστήματα.

A Simple Clean Architecture Structure for ASP.NET Core Projects

nikosst — Tue, 17 Mar 2026 22:29:40 +0000

Many developers hear about Clean Architecture but struggle with one simple question:

How should I structure my projects?

In this article we will look at a simple and practical project structure for ASP.NET Core using the ideas from Clean Architecture, introduced by software engineer Robert C. Martin (Uncle Bob).

The goal is simple:

keep business logic independent
keep infrastructure replaceable
keep the system easy to maintain

Let’s break it down.

The 4 Project Structure

A very clean approach is to split the solution into four projects.

MyProject

MyProject.Domain
MyProject.Application
MyProject.Infrastructure
MyProject.API

Each project has a very specific responsibility.

1. Domain Layer (The Core of the System)

The Domain layer contains the business rules.

Nothing here should depend on frameworks, databases, or external services.

Typical folders:

Domain ├── Entities ├── ValueObjects ├── Enums └── Exceptions

Example entity:

public class Order
{
    public Guid Id { get; private set; }

    public decimal Amount { get; private set; }

    public void Pay()
    {
        // business rule
    }
}

Important rule:

The Domain layer should have zero dependencies.

2. Application Layer

The Application layer orchestrates the use cases of the system.

This is where we define interfaces for external dependencies such as repositories or services.

Example structure:

Application ├── Interfaces ├── Services ├── DTOs ├── Commands └── Queries

Example interface:

public interface IOrderRepository
{
    Task<Order> GetByIdAsync(Guid id);
    Task SaveAsync(Order order);
}

Application services use these interfaces without knowing how they are implemented.

public class OrderService
{
    private readonly IOrderRepository _repository;

    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public async Task PayOrder(Guid id)
    {
        var order = await _repository.GetByIdAsync(id);

        order.Pay();

        await _repository.SaveAsync(order);
    }
}

3. Infrastructure Layer

The Infrastructure layer contains technical implementations.

Examples:

database access
external APIs
email services
file storage

Example structure:

Infrastructure
├── Persistence
├── Services
└── External

Repository implementation:

public class OrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context)
    {
        _context = context;
    }

    public async Task<Order> GetByIdAsync(Guid id)
    {
        return await _context.Orders.FindAsync(id);
    }

    public async Task SaveAsync(Order order)
    {
        _context.Update(order);
        await _context.SaveChangesAsync();
    }
}

Notice something important:

The Infrastructure layer depends on the Application layer, not the other way around.

4. API Layer

The API layer is the entry point of the system.

Typical structure:

API ├── Controllers └── Program.cs

Example controller:

[ApiController]
[Route("orders")]
public class OrdersController : ControllerBase
{
    private readonly OrderService _service;

    public OrdersController(OrderService service)
    {
        _service = service;
    }

    [HttpPost("{id}/pay")]
    public async Task<IActionResult> Pay(Guid id)
    {
        await _service.PayOrder(id);

        return Ok();
    }
}

Dependency Direction (The Most Important Rule)

The direction of dependencies should look like this:

API ↓ Application ↓ Domain

Infrastructure → Application

This rule ensures that business logic remains independent from frameworks and databases.

Dependency Injection

The concrete implementations are wired up in the API project:

builder.Services.AddScoped<IOrderRepository, OrderRepository>();

This allows the Application layer to stay clean and unaware of infrastructure details.

A Senior Developer Tip

As systems grow, many teams move from simple services to patterns like CQRS (Command Query Responsibility Segregation).

Instead of this:

Application └── Services

you may see something like this:

Application ├── Commands ├── Queries ├── Handlers └── Behaviors

This approach scales better in larger systems.

Final Thoughts

Clean Architecture is not about adding complexity.

It is about separating responsibilities so your system becomes:

easier to test
easier to maintain
easier to evolve

Start simple, keep the layers clean, and your architecture will scale naturally as your application grows.

nikosstit@gmail.com

Middleware στο ASP.NET Core (C#)

nikosst — Wed, 11 Mar 2026 21:19:56 +0000

Από τη θεωρία μέχρι τα production patterns

Στην αρχιτεκτονική του ASP.NET Core, το middleware αποτελεί έναν από τους πιο θεμελιώδεις μηχανισμούς του framework. Στην πράξη, σχεδόν κάθε request που φτάνει σε μια εφαρμογή ASP.NET Core περνά μέσα από μια αλληλουχία middleware components πριν φτάσει στον τελικό προορισμό του, δηλαδή σε έναν controller, ένα endpoint ή ένα minimal API.

Η έννοια του middleware δεν είναι απλώς μια τεχνική λεπτομέρεια. Είναι στην ουσία το κεντρικό μοτίβο επεξεργασίας HTTP requests, το οποίο επιτρέπει την υλοποίηση πολλών κρίσιμων λειτουργιών μιας εφαρμογής όπως authentication, logging, exception handling, rate limiting, caching και security.

Σκοπός αυτού του άρθρου είναι να παρουσιάσει το middleware σε βάθος, με τρόπο που να είναι κατανοητός τόσο από αρχάριους όσο και από πιο προχωρημένους developers, ενώ παράλληλα να εξετάζει και πρακτικές που χρησιμοποιούνται σε enterprise επίπεδο εφαρμογών.

Η βασική ιδέα του Middleware

Ένα middleware είναι ένα component που συμμετέχει στην επεξεργασία ενός HTTP request. Μπορεί να εκτελέσει λογική πριν και μετά από την εκτέλεση του επόμενου component στο pipeline.

Το ASP.NET Core βασίζεται σε μια αλυσίδα middleware components, τα οποία εκτελούνται διαδοχικά.

Η γενική ροή είναι η εξής:

Client Request
      │
      ▼
Middleware 1
      │
      ▼
Middleware 2
      │
      ▼
Middleware 3
      │
      ▼
Endpoint (Controller / Minimal API)
      │
      ▼
Response επιστρέφει προς τα πίσω

Η σημαντική λεπτομέρεια εδώ είναι ότι κάθε middleware έχει τη δυνατότητα να:

εκτελέσει λογική πριν την επεξεργασία του request
καλέσει το επόμενο middleware
επεξεργαστεί το response αφού επιστρέψει

Η συμπεριφορά αυτή θυμίζει έντονα το Chain of Responsibility pattern, όπου κάθε component μπορεί να επεξεργαστεί ένα αίτημα ή να το προωθήσει στον επόμενο.

Το HTTP Pipeline στο ASP.NET Core

Το σύνολο των middleware components ονομάζεται HTTP pipeline.

Όταν μια εφαρμογή ξεκινά, ο developer ορίζει ποια middleware θα συμμετέχουν σε αυτό το pipeline και με ποια σειρά.

Αυτό γίνεται συνήθως στο αρχείο Program.cs.

Ένα απλό παράδειγμα pipeline:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseHttpsRedirection();

app.UseAuthentication();

app.UseAuthorization();

app.MapControllers();

app.Run();

Σε αυτό το pipeline συμβαίνουν τα εξής:

Το request μετατρέπεται σε HTTPS αν χρειάζεται
Ελέγχεται η ταυτότητα του χρήστη
Ελέγχονται τα permissions
Εκτελείται ο controller

Η σειρά είναι εξαιρετικά σημαντική. Αν αλλάξει, μπορεί να δημιουργηθούν σφάλματα ή κενά ασφαλείας.

Δημιουργία απλού Middleware

Το πιο απλό middleware μπορεί να δημιουργηθεί inline μέσα στο pipeline.

app.Use(async (context, next) =>
{
    Console.WriteLine("Incoming request");

    await next();

    Console.WriteLine("Outgoing response");
});

Το context αντιπροσωπεύει το HTTP context, δηλαδή όλα τα δεδομένα του request και του response.

Το next είναι ένας delegate που καλεί το επόμενο middleware.

Η εκτέλεση γίνεται ως εξής:

Εκτελείται η πρώτη Console.WriteLine
Εκτελείται το επόμενο middleware
Επιστρέφει ο έλεγχος και εκτελείται η δεύτερη Console.WriteLine

Δημιουργία Custom Middleware Class

Σε πραγματικές εφαρμογές είναι καλύτερο να δημιουργούμε ξεχωριστές κλάσεις middleware.

Παράδειγμα:

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;

    public LoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        Console.WriteLine($"Request: {context.Request.Path}");

        await _next(context);

        Console.WriteLine($"Response: {context.Response.StatusCode}");
    }
}

Και προσθήκη στο pipeline:

app.UseMiddleware<LoggingMiddleware>();

Αυτός είναι ο πιο καθαρός και επεκτάσιμος τρόπος δημιουργίας middleware.

Middleware και SOLID Principles

Το middleware architecture είναι ένα εξαιρετικό παράδειγμα εφαρμογής των αρχών SOLID.

Single Responsibility Principle

Κάθε middleware πρέπει να έχει μία ευθύνη.

Για παράδειγμα:

LoggingMiddleware
AuthenticationMiddleware
ExceptionMiddleware
RateLimitMiddleware

Δεν πρέπει να υπάρχει middleware που να κάνει πολλά πράγματα ταυτόχρονα.

Open / Closed Principle

Το pipeline μπορεί να επεκταθεί χωρίς να αλλάξουμε υπάρχον κώδικα.

Απλά προσθέτουμε νέο middleware.

app.UseMiddleware<LoggingMiddleware>();
app.UseMiddleware<MetricsMiddleware>();
app.UseMiddleware<RateLimitMiddleware>();

Dependency Injection

Τα middleware μπορούν να χρησιμοποιούν dependency injection.

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<LoggingMiddleware> _logger;

    public LoggingMiddleware(RequestDelegate next,
        ILogger<LoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        _logger.LogInformation("Request started");

        await _next(context);

        _logger.LogInformation("Request finished");
    }
}

Αυτό επιτρέπει εύκολη ενσωμάτωση με services της εφαρμογής.

Κύριες Χρήσεις Middleware

Το middleware χρησιμοποιείται σε πολλές κρίσιμες λειτουργίες μιας web εφαρμογής.

Οι πιο συνηθισμένες περιπτώσεις είναι:

Logging requests
Authentication
Authorization
Exception handling
Request validation
Security headers
Rate limiting
Response caching
Metrics και monitoring
Localization
Multi-tenancy

Παρακάτω αναλύουμε τις πιο σημαντικές.

Exception Handling Middleware

Σε production εφαρμογές δεν θέλουμε τα exceptions να εμφανίζονται απευθείας στον χρήστη.

Ένα middleware μπορεί να τα διαχειρίζεται κεντρικά.

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;

    public ExceptionMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            context.Response.StatusCode = 500;

            await context.Response.WriteAsync(
                "An internal server error occurred");
        }
    }
}

Αυτό δημιουργεί centralized error handling.

Logging Middleware

Το logging middleware βοηθά στη διάγνωση προβλημάτων και στο monitoring.

public class RequestLoggingMiddleware
{
    private readonly RequestDelegate _next;

    public RequestLoggingMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var start = DateTime.UtcNow;

        await _next(context);

        var duration = DateTime.UtcNow - start;

        Console.WriteLine(
            $"{context.Request.Method} {context.Request.Path} took {duration.TotalMilliseconds} ms");
    }
}

Αυτό χρησιμοποιείται συχνά σε συνδυασμό με εργαλεία όπως:

structured logging
distributed tracing
application monitoring

Rate Limiting Middleware

Σε public APIs είναι απαραίτητο να περιορίζουμε τον αριθμό των requests.

public class RateLimitMiddleware
{
    private readonly RequestDelegate _next;

    public RateLimitMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var ip = context.Connection.RemoteIpAddress?.ToString();

        // pseudo logic rate limit

        await _next(context);
    }
}

Αυτό προστατεύει από:

abuse
bot traffic
denial-of-service attacks

Security Headers Middleware

Τα security headers είναι σημαντικά για την προστασία της εφαρμογής.

public class SecurityHeadersMiddleware
{
    private readonly RequestDelegate _next;

    public SecurityHeadersMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        context.Response.Headers.Add("X-Frame-Options", "DENY");
        context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
        context.Response.Headers.Add("X-XSS-Protection", "1; mode=block");

        await _next(context);
    }
}

JWT Authentication Middleware

Σε APIs χρησιμοποιούμε συχνά JWT tokens.

app.UseAuthentication();
app.UseAuthorization();

Το authentication middleware:

διαβάζει το token
το επικυρώνει
δημιουργεί το User Identity

Correlation ID Middleware (Production Pattern)

Σε distributed systems είναι σημαντικό να υπάρχει correlation id για tracing.

public class CorrelationIdMiddleware
{
    private readonly RequestDelegate _next;

    public CorrelationIdMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var correlationId = Guid.NewGuid().ToString();

        context.Response.Headers.Add("X-Correlation-ID", correlationId);

        await _next(context);
    }
}

Αυτό βοηθά στο debugging microservices.

Multi-Tenancy Middleware

Σε SaaS εφαρμογές χρησιμοποιούμε middleware για να εντοπίσουμε τον tenant.

public class TenantMiddleware
{
    private readonly RequestDelegate _next;

    public TenantMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var tenant = context.Request.Headers["X-Tenant"];

        context.Items["Tenant"] = tenant;

        await _next(context);
    }
}

Use vs Run vs Map

Το ASP.NET Core προσφέρει διαφορετικούς τρόπους προσθήκης middleware.

Use

Συνεχίζει το pipeline.

app.Use(async (context, next) =>
{
    await next();
});

Run

Τερματίζει το pipeline.

app.Run(async context =>
{
    await context.Response.WriteAsync("End");
});

Map

Δημιουργεί branch.

app.Map("/api", apiApp =>
{
    apiApp.UseMiddleware<ApiMiddleware>();
});

Middleware Order

Η σειρά είναι κρίσιμη.

Ένα συνηθισμένο production pipeline:

Exception Middleware
Logging Middleware
Security Middleware
Routing
Authentication
Authorization
Endpoints

Αν αλλάξει η σειρά μπορεί να προκύψουν προβλήματα ασφαλείας ή λειτουργίας.

Best Practices για Middleware

Σε production συστήματα πρέπει να ακολουθούνται μερικές βασικές αρχές.

Τα middleware πρέπει να είναι:

stateless
γρήγορα
ελαφριά
εύκολα επεκτάσιμα

Stateless

Ένα middleware πρέπει να είναι stateless, δηλαδή να μην αποθηκεύει κατάσταση (state) μεταξύ διαφορετικών HTTP requests. Κάθε request πρέπει να αντιμετωπίζεται ανεξάρτητα από τα προηγούμενα.

Αυτό σημαίνει ότι το middleware δεν πρέπει να κρατά δεδομένα σε fields που αλλάζουν ανά request, γιατί η ίδια instance μπορεί να χρησιμοποιείται ταυτόχρονα από πολλούς χρήστες.

Για παράδειγμα, δεν πρέπει να αποθηκεύουμε στοιχεία χρήστη σε μεταβλητές της κλάσης. Αν χρειάζεται προσωρινή πληροφορία, χρησιμοποιούμε το HttpContext, το οποίο είναι μοναδικό για κάθε request.

Η stateless σχεδίαση κάνει το middleware thread-safe και scalable, κάτι ιδιαίτερα σημαντικό για εφαρμογές με πολλούς ταυτόχρονους χρήστες.

Γρήγορα

Τα middleware πρέπει να εκτελούνται όσο το δυνατόν πιο γρήγορα, γιατί κάθε HTTP request περνά από αυτά.

Αν ένα middleware εκτελεί βαριές λειτουργίες, όπως μεγάλα queries στη βάση ή σύνθετους υπολογισμούς, τότε επηρεάζεται η συνολική απόδοση της εφαρμογής.

Για αυτό το λόγο συνήθως τα middleware περιορίζονται σε λειτουργίες όπως logging, validation ή routing και αποφεύγουν βαριά business logic.

Ελαφριά

Ένα middleware πρέπει να είναι ελαφρύ σε πόρους (CPU και μνήμη). Η βασική του ευθύνη είναι να επεξεργαστεί το request και να το προωθήσει γρήγορα στο επόμενο component του pipeline.

Αν ένα middleware περιέχει πολύπλοκη λογική ή πολλές εξαρτήσεις, τότε το pipeline γίνεται πιο αργό και δύσκολο στη συντήρηση.

Η καλή πρακτική είναι το middleware να λειτουργεί ως ενδιάμεσος μηχανισμός διαχείρισης του request, ενώ η κύρια λογική να υλοποιείται σε services.

Εύκολα επεκτάσιμα

Τα middleware πρέπει να είναι σχεδιασμένα έτσι ώστε να μπορούν να επεκταθούν ή να αντικατασταθούν εύκολα χωρίς να επηρεάζεται η υπόλοιπη εφαρμογή.

Αυτό επιτυγχάνεται με:

καθαρό διαχωρισμό ευθυνών
χρήση dependency injection
μικρά και ανεξάρτητα middleware components

Με αυτόν τον τρόπο μπορούμε να προσθέσουμε νέα λειτουργικότητα στο pipeline απλά προσθέτοντας ένα νέο middleware, χωρίς να χρειαστεί να τροποποιήσουμε τον υπάρχοντα κώδικα.

Επίσης δεν πρέπει να περιέχουν business logic. Η επιχειρησιακή λογική ανήκει στο domain ή στα services.

Να θυμάσαι..

Το middleware αποτελεί τον βασικό μηχανισμό επεξεργασίας HTTP requests στο ASP.NET Core. Μέσα από το middleware pipeline μπορούμε να υλοποιήσουμε μια μεγάλη ποικιλία λειτουργιών, από logging και authentication μέχρι security και distributed tracing.

Η σωστή σχεδίαση middleware επιτρέπει τη δημιουργία εφαρμογών που είναι modular, επεκτάσιμες και εύκολες στη συντήρηση. Συνδυάζοντας τις αρχές του SOLID, το dependency injection και το σωστό pipeline ordering, το ASP.NET Core παρέχει μια ιδιαίτερα ισχυρή αρχιτεκτονική για την ανάπτυξη σύγχρονων web εφαρμογών και APIs.

nikosstit@gmail.com

Async / Await, Task και Thread Pool στο C# Μια πλήρης αλλά απλή εξήγηση

nikosst — Tue, 10 Mar 2026 16:12:48 +0000

Πολλοί προγραμματιστές χρησιμοποιούν async και await καθημερινά χωρίς να γνωρίζουν πραγματικά τι συμβαίνει από κάτω.
Σε αυτό το άρθρο θα εξηγήσουμε από την αρχή και χωρίς κενά:

τι είναι thread
τι είναι thread pool
τι είναι task
τι κάνουν οι λέξεις async και await
τι σημαίνει "syntactic sugar"
τι πραγματικά κάνει ο compiler

Το άρθρο βασίζεται στη συμπεριφορά της πλατφόρμας .NET και της γλώσσας C#.

1. Τι είναι ένα Thread

Ένα thread (νήμα εκτέλεσης) είναι ο μικρότερος τρόπος με τον οποίο μπορεί να εκτελεστεί κώδικας σε ένα πρόγραμμα.

Σκέψου ένα πρόγραμμα σαν ένα εργοστάσιο.

Το εργοστάσιο είναι η εφαρμογή.
Οι εργαζόμενοι είναι τα threads.

Κάθε thread εκτελεί εντολές του προγράμματος.

Παράδειγμα:

Ένα πρόγραμμα μπορεί να έχει:

ένα thread για το UI
ένα thread για υπολογισμούς
ένα thread για δίκτυο
Κάθε thread εκτελεί κώδικα ανεξάρτητα.

2. Γιατί δεν δημιουργούμε συνεχώς Threads

Η δημιουργία ενός νέου thread είναι ακριβή διαδικασία για το λειτουργικό σύστημα.

Υπάρχουν αρκετοί λόγοι.

Memory allocation

Όταν δημιουργείται ένα thread, το λειτουργικό σύστημα πρέπει να δεσμεύσει μνήμη για αυτό.

Η μνήμη αυτή χρησιμοποιείται για:

το stack του thread
μεταβλητές που χρειάζεται το thread
εσωτερικά δεδομένα του λειτουργικού συστήματος

Η διαδικασία αυτή λέγεται memory allocation, δηλαδή:

δέσμευση ενός τμήματος μνήμης για χρήση από ένα thread.

Kernel scheduling

Το λειτουργικό σύστημα πρέπει να αποφασίσει ποιο thread θα εκτελεστεί κάθε στιγμή στον επεξεργαστή.

Αυτό το κάνει ένα κομμάτι του λειτουργικού συστήματος που λέγεται kernel.

Η διαδικασία με την οποία ο kernel αποφασίζει ποιο thread θα τρέξει λέγεται:

kernel scheduling

Δηλαδή:

ο προγραμματισμός εκτέλεσης των threads από το λειτουργικό σύστημα.

Context switch

Ο επεξεργαστής μπορεί να εκτελεί ένα thread τη φορά ανά πυρήνα.

Όταν το λειτουργικό σύστημα αλλάζει thread, πρέπει να:

αποθηκεύσει την κατάσταση του τρέχοντος thread
φορτώσει την κατάσταση ενός άλλου thread
συνεχίσει την εκτέλεση

Αυτή η αλλαγή λέγεται:

context switch

Δηλαδή:

αλλαγή από ένα thread σε ένα άλλο.

Η διαδικασία αυτή κοστίζει χρόνο.

3. Τι είναι το Thread Pool

Για να αποφύγουμε τη συνεχή δημιουργία threads, το runtime της πλατφόρμας .NET χρησιμοποιεί κάτι που λέγεται:

Thread Pool

Το Thread Pool είναι μια συλλογή από threads που έχουν δημιουργηθεί ήδη και περιμένουν δουλειά.

Αντί να δημιουργούμε νέο thread κάθε φορά:

το πρόγραμμα στέλνει μια εργασία
η εργασία μπαίνει σε μια ουρά
ένα διαθέσιμο thread από το pool την εκτελεί

Έτσι:

δεν δημιουργούνται συνεχώς νέα threads
μειώνεται το κόστος
αυξάνεται η απόδοση

4. Τι είναι το Task

Ένα Task είναι μια αναπαράσταση μιας εργασίας που θα ολοκληρωθεί στο μέλλον.

Πολύ σημαντικό:

Task δεν είναι thread.

Ένα Task είναι απλά ένα αντικείμενο που λέει:

Υπάρχει μια εργασία που θα ολοκληρωθεί αργότερα.

Παράδειγμα:

Task<int> result = CalculateAsync();

Αυτό σημαίνει:

η εργασία εκτελείται
κάποια στιγμή θα επιστρέψει έναν αριθμό

Το Task απλά κρατά πληροφορίες για την κατάσταση της εργασίας.

5. Τι σημαίνει Async

Η λέξη async μπαίνει πριν από μια μέθοδο.

Παράδειγμα:

async Task<string> GetData()
{
}

Η λέξη async δηλώνει ότι:

η μέθοδος μπορεί να περιέχει await.

Δεν δημιουργεί νέο thread.

Δεν κάνει την μέθοδο αυτόματα ασύγχρονη.

Απλά επιτρέπει τη χρήση του await.

6. Τι κάνει το Await

Το await χρησιμοποιείται για να περιμένουμε την ολοκλήρωση ενός Task.

Παράδειγμα:

var data = await GetDataAsync();

Η διαφορά από την κανονική αναμονή είναι σημαντική.

Με απλή αναμονή το thread μπλοκάρει.

Με await το thread ελευθερώνεται για να κάνει άλλη δουλειά.

Η διαδικασία είναι η εξής:

ξεκινά το Task
αν δεν έχει ολοκληρωθεί
η μέθοδος "παγώνει"
το thread επιστρέφει στο Thread Pool
όταν ολοκληρωθεί το Task
η μέθοδος συνεχίζει από το σημείο που σταμάτησε

7. Παράδειγμα Async με καθυστέρηση

async Task Example()
{
    Console.WriteLine("Start");

    await Task.Delay(2000);

    Console.WriteLine("End");
}

Τι συμβαίνει:

εκτελείται το Start
ξεκινά το Delay
η μέθοδος σταματά προσωρινά
το thread ελευθερώνεται
μετά από 2 δευτερόλεπτα
η μέθοδος συνεχίζει
εκτελείται το End

8. Async δεν σημαίνει νέο Thread

Ένα πολύ συχνό λάθος είναι να πιστεύουμε ότι:

async = νέο thread

Αυτό δεν ισχύει.

Στις περισσότερες περιπτώσεις async χρησιμοποιείται για I/O εργασίες.

Παραδείγματα:

HTTP requests
database queries
file system
network calls

Σε αυτές τις περιπτώσεις:

το πρόγραμμα στέλνει το αίτημα και απλά περιμένει απάντηση.

Κατά τη διάρκεια της αναμονής δεν χρειάζεται thread να δουλεύει συνεχώς.

9. Τι σημαίνει Syntactic Sugar

Οι λέξεις async και await είναι κάτι που λέγεται:

syntactic sugar

Αυτό σημαίνει:

ένας πιο απλός τρόπος γραφής για κάτι που θα μπορούσε να γραφτεί πιο δύσκολα.

Πριν υπάρξει το async/await γράφαμε κώδικα με callbacks.

Παράδειγμα:

GetDataAsync().ContinueWith(t =>
{
    Console.WriteLine(t.Result);
});

Με async/await:

var data = await GetDataAsync();
Console.WriteLine(data);

Ο δεύτερος τρόπος είναι πολύ πιο κατανοητός.

10. Τι κάνει ο Compiler

Όταν γράφουμε async μέθοδο, ο compiler της C# δεν την αφήνει έτσι.

Την μετατρέπει σε κάτι πιο σύνθετο που λέγεται:

state machine

Μια state machine είναι ένας μηχανισμός που:

θυμάται σε ποιο σημείο βρισκόταν η μέθοδος
ξέρει από πού να συνεχίσει μετά το await

Έτσι η μέθοδος μπορεί να:

σταματήσει
αποθηκεύσει την κατάσταση της
συνεχίσει αργότερα

11. Πραγματικό παράδειγμα με HTTP

async Task<string> Download()
{
    var client = new HttpClient();

    return await client.GetStringAsync("https://example.com");
}

Τι συμβαίνει:

στέλνεται το HTTP request
το πρόγραμμα περιμένει απάντηση
το thread ελευθερώνεται
όταν έρθει η απάντηση
η μέθοδος συνεχίζει
επιστρέφεται το αποτέλεσμα

12. Πότε πρέπει να χρησιμοποιούμε Async

Το async είναι πολύ χρήσιμο σε εφαρμογές όπως:

web APIs
servers
εφαρμογές με UI
εφαρμογές που κάνουν πολλά network calls

Παράδειγμα framework:

ASP.NET Core

Εκεί το async επιτρέπει σε έναν server να εξυπηρετεί πολλούς χρήστες ταυτόχρονα χωρίς να χρειάζεται πολλά threads.

13. Πότε δεν είναι χρήσιμο

Το async δεν βοηθά σε εργασίες που χρησιμοποιούν έντονα τον επεξεργαστή.

Παραδείγματα:

επεξεργασία εικόνας
πολύπλοκοι μαθηματικοί υπολογισμοί
machine learning
συμπίεση δεδομένων

Σε αυτές τις περιπτώσεις χρειαζόμαστε πραγματικά threads ή παράλληλη εκτέλεση.

Συμπέρασμα

Ας συνοψίσουμε τις βασικές έννοιες.

Thread
είναι ένα νήμα εκτέλεσης κώδικα.

Thread Pool
είναι μια συλλογή από έτοιμα threads που επαναχρησιμοποιούνται.

Task
είναι μια αναπαράσταση μιας εργασίας που θα ολοκληρωθεί στο μέλλον.

async
επιτρέπει την χρήση του await.

await
περιμένει την ολοκλήρωση μιας εργασίας χωρίς να μπλοκάρει το thread.

syntactic sugar
είναι ένας πιο απλός τρόπος γραφής για κάτι πιο σύνθετο.

nikosstit@gmail.com

Async/Await in C#: The Feature You Think You Understand (But Probably Use Wrong)

nikosst — Sun, 08 Mar 2026 17:34:02 +0000

If you work with C# and .NET, chances are you use async and await every day.

Yet many developers:

don't fully understand what await actually does
accidentally introduce performance bottlenecks
block threads without realizing it
write async code that isn’t truly asynchronous

This article is written primarily for Senior Developers, but structured so Junior Developers can learn from it step by step.

The goal is simple:

Build a correct mental model of asynchronous programming.

The Biggest Misconception

One of the most common misconceptions in .NET development is the following:

async/await = new thread

This is not true.

Using async and await does not automatically create a new thread.

Instead, something much more efficient happens.

When an asynchronous operation starts:

the current thread initiates the operation
the thread returns to the thread pool
the application does not block while waiting

when the operation completes, execution continues later from the awaited point

This mechanism allows the runtime to reuse threads efficiently instead of keeping them idle while waiting for I/O operations such as:

database queries
HTTP requests
file access
external API calls

Because threads are not blocked, the server can handle many more concurrent requests with the same resources.

And this is exactly what makes modern .NET web APIs highly scalable.

The Real Problem Async Solves

Imagine this API endpoint:

public string GetData()
{
    var client = new HttpClient();
    var result = client.GetStringAsync("https://api.example.com").Result;
    return result;
}

What happens here?

The thread:

waits for the network response
does nothing meanwhile
remains blocked

In a high-traffic server this leads to:

thread pool exhaustion
lower throughput
higher latency

The Correct Async Version

public async Task<string> GetDataAsync()
{
    var client = new HttpClient();
    return await client.GetStringAsync("https://api.example.com");
}

Now the thread:

starts the request
returns to the pool
resumes when the response arrives

This is the key to scalability.

The Mistake Even Senior Developers Make

One of the most common mistakes developers make when working with asynchronous code is forcing it to run synchronously.

Example:

var result = GetDataAsync().Result;

GetDataAsync().Wait();

At first glance this might seem harmless. You call an async method and simply wait for the result.

But what actually happens is more problematic.

Even though GetDataAsync() is asynchronous, using .Result or .Wait() blocks the current thread while waiting for the operation to complete.

Instead of allowing the thread to return to the thread pool and continue other work, the thread just sits there doing nothing, waiting for the result.

This defeats the entire purpose of asynchronous programming.

Because of this blocking behavior, several problems can occur:

Deadlocks especially in environments with synchronization contexts (such as UI frameworks)

Thread starvation, threads remain blocked instead of serving other requests

Performance issues, the application handles fewer concurrent operations

Golden Rule

Async all the way down

Once a method becomes asynchronous, the entire call chain should remain asynchronous.

In practice, this means:

var result = await GetDataAsync();

instead of forcing the async code to behave synchronously.

Following this rule ensures that threads are not blocked and that your application can fully benefit from asynchronous execution.

Sequential vs Parallel Async

A key difference between mid-level and senior developers is parallel async execution.

Sequential

var user = await GetUserAsync();
var orders = await GetOrdersAsync();
var payments = await GetPaymentsAsync();

Each operation waits for the previous one.

Parallel


var userTask = GetUserAsync();
var ordersTask = GetOrdersAsync();
var paymentsTask = GetPaymentsAsync();

await Task.WhenAll(userTask, ordersTask, paymentsTask);

Now everything runs concurrently.

In microservices architectures this can reduce response time from 900ms to 300ms.

Another Common Mistake: async void

Bad:

public async void Save()
{
    await SaveToDatabase();
}

Correct:

public async Task Save()
{
    await SaveToDatabase();
}

async void means:

you can't await it
you can't catch exceptions
It should only be used for event handlers.

Cancellation Tokens (Production Must-Have)

Real production systems need cancellation support.

public async Task<string> DownloadAsync(
    string url,
    CancellationToken token)
{
    var client = new HttpClient();
    return await client.GetStringAsync(url, token);
}

Why it matters:

aborted HTTP requests
timeouts
graceful shutdowns

A Tip That Separates Senior Developers

Don't write async code just because you can.

Use async when you have:

I/O operations
network calls
database queries
file access

For CPU-bound work, async often doesn't help.

A Simple Mental Model

Every time you write async code ask yourself:

Is this I/O bound?
Am I blocking a thread?
Can operations run in parallel?
Is cancellation supported?
Will this scale in production?

This is how senior engineers think.

Final Thoughts

async/await is one of the most important concepts in modern .NET development.

It is not just syntax.

It is an architectural tool.

Senior developers don't just write async code.

They design systems that:

leverage asynchronous execution
avoid concurrency pitfalls
scale under real production load

And that difference becomes obvious the moment your system starts receiving real traffic.

nikosstit@gmail.com