Future: nikosst

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 συμπεριφορά μπορεί να είναι είτε εξαιρετικά χρήσιμη είτε εντελώς περιττή, ανάλογα με το σενάριο.

Σε αυτό το άρθρο θα δούμε τι κάνουν τα 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 λοιπόν είναι το εξής:

Φέρνεις δεδομένα από τη βάση (δημιουργούνται objects στη μνήμη)
Το EF κρατάει snapshot της αρχικής κατάστασης
Τροποποιείς τα objects στη μνήμη
Το EF εντοπίζει τις αλλαγές συγκρίνοντας τιμές στη μνήμη
Με SaveChanges() στέλνει τις αλλαγές στη βάση

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

Παράδειγμα:

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

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

Με απλά λόγια:
Το EF δουλεύει με ένα “snapshot” της βάσης μέσα στη μνήμη και παρακολουθεί αλλαγές πάνω σε αυτό, όχι απευθείας στη βάση δεδομένων.

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

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

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

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

context.SaveChanges();

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

Το EF Core παρακολουθεί το entity
Εντοπίζει την αλλαγή στο Name
Εκτελεί αυτόματα 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 και όχι στη βάση δεδομένων.

Το κρίσιμο σημείο είναι ότι το Entity Framework δεν γνωρίζει ότι έγινε αυτή η αλλαγή, γιατί δεν παρακολουθεί το συγκεκριμένο object. Δεν έχει καταγράψει την αρχική του κατάσταση, ούτε παρακολουθεί τις μεταβολές του.

Όταν στη συνέχεια καλείται η SaveChanges(), το EF ελέγχει ποια entities έχουν αλλαγές. Επειδή όμως δεν υπάρχει κανένα tracked entity, θεωρεί ότι δεν υπάρχει τίποτα προς αποθήκευση και έτσι δεν εκτελεί κανένα UPDATE query στη βάση.

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

Το πρόβλημα που λύνει το 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

Τι είναι το Identity Resolution

Το Identity Resolution είναι ένας μηχανισμός του Entity Framework Core που εξασφαλίζει ότι κάθε εγγραφή (record) από τη βάση δεδομένων αντιστοιχεί σε ένα και μοναδικό object instance στη μνήμη κατά την εκτέλεση ενός query. Με άλλα λόγια, αν το ίδιο entity εμφανιστεί πολλές φορές μέσα στο αποτέλεσμα — κάτι πολύ συνηθισμένο σε queries με JOIN ή Include — το EF Core δεν δημιουργεί νέα αντικείμενα κάθε φορά, αλλά επαναχρησιμοποιεί το ίδιο instance.

Αυτό έχει μεγάλη σημασία για τη συνέπεια των δεδομένων στη μνήμη. Επιτρέπει σωστή σύγκριση με reference equality (π.χ. ReferenceEquals), αποτρέπει duplicates και διασφαλίζει ότι οποιαδήποτε αλλαγή σε ένα object αντανακλάται παντού όπου αυτό χρησιμοποιείται μέσα στο ίδιο result set.

Χωρίς Identity Resolution, το ίδιο entity μπορεί να φορτωθεί πολλές φορές ως διαφορετικά objects, κάτι που μπορεί να οδηγήσει σε subtle bugs, αυξημένη κατανάλωση μνήμης και απρόβλεπτη συμπεριφορά σε mapping, serialization ή business logic.

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

Χωρίς 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() είναι ιδανικό όταν:

Έχεις complex graphs (π.χ. Orders → Customers → Addresses)
Χρησιμοποιείς Include
Δεν θέλεις tracking αλλά:
Θέλεις consistency στα object references

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

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

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

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

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

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

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

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

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

Κανόνας στην πράξη

CRUD → AsTracking()
Read simple → AsNoTracking()
Read complex graph → AsNoTrackingWithIdentityResolution()

Συμπέρασμα

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

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

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

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

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

Το Ταξίδι του JWT Όταν η Εμπιστοσύνη Γίνεται Token

nikosst — Sun, 08 Mar 2026 16:44:37 +0000

Η διαχείριση της σύνδεσης των χρηστών σε εφαρμογές υπήρξε πάντα μια δύσκολη υπόθεση. Παραδοσιακά, χρησιμοποιούνται cookies, sessions και διάφορες μορφές state management για να θυμάται ο server ποιος είναι συνδεδεμένος. Τα cookies αποθηκεύουν μικρά δεδομένα στον browser του χρήστη και στέλνονται αυτόματα με κάθε αίτημα. Τα sessions κρατούν πληροφορίες στη μνήμη ή στη βάση του server, συνδέοντας κάθε χρήστη με ένα μοναδικό session ID. Το state management βοηθά την εφαρμογή να θυμάται σε ποιο σημείο βρίσκεται ο χρήστης, αλλά η συντήρηση όλων αυτών των μηχανισμών μπορεί να γίνει σύνθετη και εύθραυστη, ειδικά όταν υπάρχουν πολλά endpoints, microservices ή περιβάλλοντα που αλλάζουν συχνά.

Το JWT (JSON Web Token) ήρθε να απλοποιήσει αυτή τη διαδικασία, προσφέροντας έναν διαφορετικό τρόπο να εκφράζεται η εμπιστοσύνη ανάμεσα σε client και server. Αντί ο server να χρειάζεται να “θυμάται” κάθε χρήστη, εκδίδει ένα token που περιέχει όλες τις απαραίτητες πληροφορίες μέσα του, με τρόπο ασφαλή και επαληθεύσιμο.

Το σώμα του token και πώς λειτουργεί

Κάθε JWT αποτελείται από τρία μέρη, το Header, το Payload και την Signature. Το Header δηλώνει τον τύπο του token και τον αλγόριθμο υπογραφής που χρησιμοποιείται. Το Payload περιέχει τα claims, δηλαδή τα δεδομένα που περιγράφουν την ταυτότητα και τα δικαιώματα του χρήστη, για παράδειγμα ποιος είναι ο χρήστης (Subject), ποιος εξέδωσε το token (Issuer), ποιοι είναι οι παραλήπτες του (Audience), πότε δημιουργήθηκε (Issued At) και πότε λήγει (Expiration Time). Η Signature είναι η ψηφιακή υπογραφή που εξασφαλίζει ότι το token δεν έχει τροποποιηθεί μετά την έκδοσή του.

Όταν ο χρήστης κάνει login, ο server επαληθεύει τα στοιχεία του, όπως όνομα χρήστη και κωδικό πρόσβασης. Αν αυτά είναι σωστά, δημιουργεί το JWT, παίρνει τα δεδομένα που θέλει να ενσωματώσει στο Payload, τα κωδικοποιεί σε Base64URL, προσθέτει το Header και στη συνέχεια υπογράφει το αποτέλεσμα με ένα μυστικό ή ιδιωτικό κλειδί. Το αποτέλεσμα είναι ένα ενιαίο string που μοιάζει κάπως έτσι:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNjg4MDAwMDAwfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Αυτό το token αποστέλλεται πίσω στον client, ο οποίος το αποθηκεύει — συνήθως στη μνήμη της εφαρμογής ή σε ένα ασφαλές cookie. Από εκεί και πέρα, κάθε φορά που ο client θέλει να καλέσει ένα προστατευμένο endpoint, στέλνει το token στο HTTP header με τη μορφή Authorization: Bearer . Η λέξη Bearer σημαίνει “κάτοχος” δηλαδή όποιος κρατάει αυτό το token, θεωρείται ότι έχει δικαίωμα να το χρησιμοποιήσει. Για αυτόν τον λόγο είναι κρίσιμο να προστατεύεται από διαρροές, καθώς δίνει πρόσβαση στο σύστημα όσο παραμένει έγκυρο.

Όταν ο server λάβει ένα αίτημα με ένα JWT (JSON Web Token), μπορεί να το επαληθεύσει χωρίς να χρειάζεται να κοιτάξει σε βάση ή cache. Αυτό σημαίνει ότι δεν κρατά καμία αποθηκευμένη πληροφορία για το ποιος είναι συνδεδεμένος όλες οι απαραίτητες πληροφορίες βρίσκονται ήδη μέσα στο token, όπως το user ID, οι ρόλοι του χρήστη και η ημερομηνία λήξης του token.

Το μυστικό ή το δημόσιο κλειδί που χρειάζεται για να επαληθευτεί η υπογραφή του token πρέπει να είναι ήδη γνωστό στον server. Αν χρησιμοποιούμε symmetric signing (π.χ. HS256), το server γνωρίζει το secret key. Αν χρησιμοποιούμε asymmetric signing (π.χ. RS256, που είναι το συνηθισμένο με Auth0), ο server γνωρίζει το public key που παρέχει ο πάροχος ταυτότητας (όπως το Auth0). Με αυτόν τον τρόπο, ο server μπορεί να ελέγξει ότι το token δεν έχει αλλοιωθεί και ότι είναι έγκυρο, χωρίς να χρειάζεται να ανατρέξει στη βάση δεδομένων για να βρει τον χρήστη.

Αν οι έλεγχοι υπογραφής και ημερομηνίας λήξης περάσουν, το αίτημα γίνεται αποδεκτό. Αυτή η λογική ονομάζεται stateless authentication, επειδή δεν απαιτεί καμία αποθήκευση κατάστασης στον server — όλα τα στοιχεία για την ταυτοποίηση του χρήστη περιέχονται ήδη μέσα στο token.

Η προσέγγιση αυτή ταιριάζει ιδανικά σε περιβάλλοντα serverless, όπου δεν υπάρχει μόνιμος server που τρέχει και διατηρεί μνήμη. Σε ένα serverless περιβάλλον, κάθε αίτημα μπορεί να εξυπηρετείται από μια ανεξάρτητη συνάρτηση ή μικροϋπηρεσία που ενεργοποιείται προσωρινά. Το JWT λειτουργεί σαν διαβατήριο, η συνάρτηση μπορεί να επαληθεύσει το token επιτόπου, χωρίς να χρειάζεται να συνδεθεί σε βάση ή να “θυμηθεί” προηγούμενες συνεδρίες.

Η λεπτή ισορροπία ασφάλειας

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

Επιπλέον, τα access tokens πρέπει να έχουν μικρή διάρκεια ζωής. Όταν λήγουν, χρησιμοποιούνται refresh tokens για την έκδοση νέων. Τα refresh tokens έχουν μεγαλύτερη διάρκεια, αλλά πρέπει να φυλάσσονται με αυστηρότητα και να ανανεώνονται περιοδικά, μια διαδικασία που ονομάζεται token rotation. Αυτή η πρακτική μειώνει τον κίνδυνο επαναχρησιμοποίησης σε περίπτωση παραβίασης.

Από τα sessions στα tokens μια αλλαγή φιλοσοφίας

Με τα sessions, η αυθεντικοποίηση βασίζεται στη διατήρηση κατάστασης στον server κάτι που γίνεται περίπλοκο όταν υπάρχουν πολλοί servers ή microservices. Με τα tokens, η ευθύνη μεταφέρεται στον client, ο χρήστης κουβαλάει μαζί του την ταυτότητά του, υπογεγραμμένη από τον server. Κάθε υπηρεσία που γνωρίζει το δημόσιο κλειδί του εκδότη μπορεί να επαληθεύσει το JWT χωρίς να εξαρτάται από κάποια κοινή βάση δεδομένων. Το αποτέλεσμα είναι ένα αποκεντρωμένο, καθαρό και επεκτάσιμο σύστημα που στηρίζεται στην κρυπτογραφική εμπιστοσύνη αντί στη μνήμη του server.

Το τέλος του ταξιδιού

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

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

Μπορούμε να το φανταστούμε σαν μια ψηφιακή ταυτότητα που κρατάς στα χέρια σου. Όπως ένας άνθρωπος δείχνει την ταυτότητά του για να εισέλθει σε ένα συνέδριο πληροφορικής, να αποδείξει την ηλικία του σε ένα μπαρ ή να περάσει από έναν έλεγχο ασφαλείας, έτσι και το JWT λειτουργεί ως απόδειξη ταυτότητας για τις εφαρμογές. Δεν χρειάζεται κάποιος να καλέσει μια αρχή για να επιβεβαιώσει την εγκυρότητα η υπογραφή πάνω του το αποδεικνύει. Το μόνο που μένει είναι να το δείξεις εκεί που χρειάζεται. Είναι η ίδια πράξη εμπιστοσύνης, απλώς σε ψηφιακή μορφή, μια ταυτότητα που δεν την κρατάει το κράτος, αλλά η εφαρμογή σου.

nikosstit@gmail.com

Πότε και πώς να μετατρέψεις ένα pattern σε NuGet Package

nikosst — Sun, 08 Mar 2026 16:34:18 +0000

Στον κόσμο της ανάπτυξης λογισμικού, η επαναχρησιμοποίηση κώδικα δεν είναι απλώς καλή πρακτική, είναι απαραίτητη για να διατηρείς καθαρά, συντηρήσιμα και ευανάγνωστα projects. Κάθε φορά που ανακαλύπτεις ότι αντιγράφεις και επικολλάς κομμάτια κώδικα σε πολλά projects ή modules, υπάρχει ένδειξη ότι κάτι μπορεί να γίνει πιο DRY.
Το DRY (Don't Repeat Yourself) είναι μια βασική αρχή που λέει ότι κάθε γνώση ή λειτουργικότητα πρέπει να έχει μία, μοναδική και authoritative αναπαράσταση μέσα στο σύστημα. Αν σπάσεις αυτήν την αρχή, δημιουργείς κώδικα δύσκολο στη συντήρηση, γεμάτο bugs και αντιφάσεις.

Πότε χρειάζεται να φτιάξεις NuGet package

Υπάρχουν αρκετές περιπτώσεις που η δημιουργία ενός NuGet package αξίζει
επαναχρησιμοποίηση σε πολλά projects

1.Αν ένα pattern, μια helper κλάση ή component χρησιμοποιείται σε περισσότερα από ένα project, η μετατροπή του σε package το καθιστά εύκολα προσβάσιμο.

2.Καθαρή αρχιτεκτονική
Διαχωρίζεις το core logic από τα projects που το χρησιμοποιούν. Αυτό είναι χρήσιμο για Clean Architecture ή layered architectures, όπου η επαναχρησιμοποίηση είναι κρίσιμη.

3.Διαχείριση εκδόσεων
Με NuGet μπορείς να ενημερώνεις μόνο το package αντί για κάθε project ξεχωριστά.

4.Ομαδική δουλειά
Κάθε μέλος της ομάδας μπορεί να χρησιμοποιεί το ίδιο package χωρίς να χρειάζεται να κατανοήσει κάθε λεπτομέρεια της υλοποίησης.

Πότε να μην το κάνεις

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

Πώς προέκυψε η ιδέα

Η ανάγκη για NuGet συνήθως εμφανίζεται όταν αντιλαμβάνεσαι ότι κάθε νέο project ή module επαναλαμβάνει την ίδια λογική.

Για παράδειγμα, σε ένα school management system μπορεί να έχεις ένα pattern για διαχείριση JWT tokens, logging ή validation. Αν το αντιγράψεις σε κάθε project, δημιουργείται γρήγορα redundant κώδικας.

Η λύση είναι να απομονώσεις τη λογική σε μια βιβλιοθήκη και να την διανείμεις ως NuGet. Έτσι, κάθε project μπορεί να εγκαθιστά το package και να χρησιμοποιεί την ίδια, ελεγμένη λογική.

Τι είναι και γιατί το DRY (Don't repeat your code) έχει σχήμα

Το DRY δεν είναι μόνο θεωρία. Έχει σχήμα όταν το εφαρμόζεις:

Κάθε κομμάτι λογικής υπάρχει μόνο μία φορά.
Όλοι οι developers ανατρέχουν στην ίδια πηγή.
Οτιδήποτε αλλάξει, ενημερώνεται κεντρικά, χωρίς να χρειάζεται να ψάχνεις και να αλλάζεις σε 5 - 10 projects.

Το NuGet είναι ένα εργαλείο που «υλοποιεί» το DRY σε επίπεδο πολλαπλών projects, προσφέροντας έλεγχο εκδόσεων, αυτοματισμό και επαναχρησιμοποίηση.

Βήματα για να μετατρέψεις ένα pattern σε NuGet

1.Δημιουργία Class Library

Δημιουργείς μια Class Library για να βάλεις όλο τον επαναχρησιμοποιήσιμο κώδικα.

dotnet new classlib -n MyPatternLibrary

2.Υλοποίηση του pattern

Γράφεις τις κλάσεις, interfaces και helpers με clear API και XML documentation.

3.Προσθήκη μεταδεδομένων στο .csproj

<PropertyGroup>
    <PackageId>MyPatternLibrary</PackageId>
    <Version>1.0.0</Version>
    <Authors>ΌνομαΣου</Authors>
    <Description>Library για επαναχρησιμοποίηση singleton pattern</Description>
    <PackageTags>singleton;utility;pattern</PackageTags>
</PropertyGroup>

Το αρχείο .csproj ενός project που πρόκειται να μετατραπεί σε NuGet package περιέχει βασικές πληροφορίες που καθορίζουν την ταυτότητα και τη διανομή του πακέτου. Το πεδίο PackageId δηλώνει το μοναδικό όνομα του πακέτου στο NuGet, ενώ το Version ορίζει την τρέχουσα έκδοση για λόγους ενημερώσεων και συμβατότητας. Το Authors αναφέρει τον δημιουργό ή την ομάδα ανάπτυξης, το Description δίνει μια σύντομη περιγραφή της λειτουργίας του πακέτου και το PackageTags περιλαμβάνει λέξεις-κλειδιά που διευκολύνουν την αναζήτησή του στο NuGet Gallery. Όλα αυτά τα στοιχεία εμφανίζονται δημόσια όταν το πακέτο ανέβει στο nuget.org και συμβάλλουν στο να κατανοήσει ο χρήστης τι κάνει και πώς μπορεί να το χρησιμοποιήσει.

4.Build και τοπικός έλεγχος

dotnet pack -c Release

Αφού ρυθμιστεί σωστά το .csproj, το επόμενο βήμα είναι η δημιουργία του πακέτου μέσω της εντολής dotnet pack, η οποία δημιουργεί ένα αρχείο .nupkg. Πριν δημοσιευθεί, είναι σημαντικό να γίνει τοπικός έλεγχος με την εντολή dotnet nuget locals ή εγκαθιστώντας το πακέτο σε ένα δοκιμαστικό project για να διαπιστωθεί ότι λειτουργεί σωστά. Έτσι διασφαλίζεται ότι το NuGet package είναι σταθερό και έτοιμο για διανομή χωρίς απρόοπτα.

5.Δημοσίευση στο NuGet

Φτιάχνεις λογαριασμό στο nuget.org
Παίρνεις API key
Στέλνεις το package

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

Δημιούργησε πρώτα έναν λογαριασμό στο https://www.nuget.org/ και έπειτα δημιούργησε ένα API Key από το προφίλ σου (θα χρειαστεί για να πιστοποιήσει το ανέβασμα). Στη συνέχεια, εκτέλεσε την εντολή

dotnet nuget push MyPatternLibrary.1.0.0.nupkg --api-key <API_KEY> --source https://api.nuget.org/v3/index.json

για να ανεβάσεις το πακέτο σου. Αν όλα πάνε καλά, θα είναι δημόσια διαθέσιμο μέσα σε λίγα λεπτά, έτοιμο για εγκατάσταση από οποιονδήποτε με ένα απλό dotnet add package MyPatternLibrary.

6.Διαχείριση εκδόσεων και updates

Κράτα semantic versioning: MAJOR.MINOR.PATCH. Κράτα CHANGELOG και ενημέρωνε το package μόνο όταν αλλάζει κάτι σημαντικό.

Η σωστή διαχείριση εκδόσεων είναι κρίσιμη για τη συντήρηση ενός αξιόπιστου NuGet package. Χρησιμοποίησε semantic versioning (MAJOR.MINOR.PATCH) ώστε οι χρήστες να γνωρίζουν πότε υπάρχουν σημαντικές αλλαγές ή διορθώσεις.

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

Να θυμάσαι..

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

Create and publish a NuGet package using Visual Studio (Windows only)

nikosstit@gmail.com

FluentValidation σε Clean Architecture

nikosst — Wed, 04 Mar 2026 16:15:54 +0000

Πώς στήνουμε σωστά τα validations και γιατί δεν πρέπει να βάζουμε business logic στους validators

Σε πολλές εφαρμογές που χρησιμοποιούν Clean Architecture μαζί με MediatR και FluentValidation, εμφανίζεται συχνά ένα συγκεκριμένο αρχιτεκτονικό λάθος. Οι validators αρχίζουν να περιέχουν μεγάλο μέρος της επιχειρησιακής λογικής της εφαρμογής, γεμίζουν με if συνθήκες, permission checks ή ακόμη και κλήσεις σε services και repositories.

Αν και αρχικά μπορεί να φαίνεται πρακτικό, αυτό οδηγεί σε κακή δομή κώδικα και σε προβλήματα συντήρησης. Για να αποφευχθεί αυτό, πρέπει να κατανοήσουμε πρώτα τον πραγματικό ρόλο του validation μέσα σε μια Clean Architecture.

Ο ρόλος του validation στην Clean Architecture

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

Το πρώτο επίπεδο αφορά το validation της μορφής του request. Το δεύτερο επίπεδο αφορά τους επιχειρησιακούς κανόνες της εφαρμογής. Το τρίτο επίπεδο αφορά τους κανόνες ακεραιότητας του domain model.

Κάθε επίπεδο πρέπει να βρίσκεται σε διαφορετικό σημείο της αρχιτεκτονικής ώστε να διατηρείται ο διαχωρισμός ευθυνών.

Input validation με FluentValidation

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

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

Ένας τυπικός validator μπορεί να μοιάζει με τον παρακάτω:

public class SaveCartItemCommandValidator 
    : AbstractValidator<SaveCartItemCommand>
{
    public SaveCartItemCommandValidator()
    {
        RuleFor(x => x.EmployeeId)
            .NotEmpty();

        RuleFor(x => x.Actions)
            .NotEmpty();

        RuleForEach(x => x.Actions)
            .ChildRules(action =>
            {
                action.RuleFor(x => x.ItemId)
                    .NotEmpty();

                action.RuleFor(x => x.Quantity)
                    .GreaterThan(0);
            });
    }
}

Ο validator εδώ ελέγχει μόνο τη δομή του request. Δεν γνωρίζει τίποτα για permissions, business rules ή κατάσταση της βάσης δεδομένων.

Application validation και business rules

Αφού περάσει το input validation, η εφαρμογή προχωρά στον έλεγχο των επιχειρησιακών κανόνων. Αυτή η λογική ανήκει στο Application Layer, συνήθως μέσα στον handler ή σε services που καλεί ο handler.

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

Ένα παράδειγμα τέτοιου ελέγχου είναι το ακόλουθο:

var employee = await employeeService.GetEmployeeAsync(request.EmployeeId);

if (!employee.CanReceiveItems())
{
    return Result.Fail("Employee cannot receive items");
}

Αυτή η λογική δεν έχει καμία θέση σε έναν FluentValidator γιατί δεν αφορά τη μορφή του request αλλά τη λειτουργία της εφαρμογής.

Domain validation

Το τρίτο επίπεδο βρίσκεται στο Domain Layer. Εκεί βρίσκονται οι κανόνες που προστατεύουν την ακεραιότητα των entities του συστήματος.

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

public void AssignItem(Item item)
{
    if(IsTerminated)
        throw new DomainException("Employee is inactive");

    _items.Add(item);
}

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

Γιατί δεν πρέπει να βάζουμε business logic στους validators

Όταν ένας validator αρχίζει να περιέχει επιχειρησιακή λογική, παραβιάζεται ο βασικός κανόνας της Clean Architecture: κάθε component πρέπει να έχει μια σαφή ευθύνη.

Ο validator πρέπει να γνωρίζει μόνο τη μορφή του request. Αν αρχίσει να καλεί services, repositories ή να ελέγχει permissions, τότε αποκτά εξαρτήσεις που δεν θα έπρεπε να έχει. Αυτό οδηγεί σε coupling ανάμεσα στα layers και κάνει την αρχιτεκτονική πιο δύσκολη στη συντήρηση.

Ένα συνηθισμένο παράδειγμα λάθους είναι το εξής:

RuleFor(x => x)
    .MustAsync(async (request, ct) =>
    {
        var employee = await employeeService.GetEmployeeAsync(request.EmployeeId);

        if(employee.IsTerminated)
            return false;

        if(employee.Role == "Manager")
            return true;

        return false;
    });

Σε αυτή την περίπτωση ο validator αρχίζει να εκτελεί business logic που κανονικά θα έπρεπε να βρίσκεται στον handler ή σε κάποιο application service.

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

Πώς διαχωρίζουμε σωστά τα validations

Η βασική αρχή είναι απλή. Το FluentValidation ελέγχει μόνο αν το request είναι σωστά διαμορφωμένο. Οι επιχειρησιακοί κανόνες εφαρμόζονται στο application layer, ενώ οι κανόνες ακεραιότητας προστατεύονται από το domain model.

Με αυτό τον διαχωρισμό κάθε κομμάτι της εφαρμογής έχει ξεκάθαρη ευθύνη. Οι validators παραμένουν μικροί και ευανάγνωστοι, οι handlers περιέχουν την επιχειρησιακή λογική και το domain model προστατεύει την κατάσταση των entities.

Έτσι η εφαρμογή παραμένει ευέλικτη, εύκολη στη συντήρηση και ευκολότερη στον έλεγχο μέσω tests.

Συμπέρασμα

Το FluentValidation είναι ένα εξαιρετικό εργαλείο για τον έλεγχο της μορφής των requests, αλλά δεν πρέπει να χρησιμοποιείται για επιχειρησιακή λογική. Όταν οι validators γεμίζουν με if συνθήκες, database calls ή permission checks, αυτό είναι συνήθως ένδειξη ότι η αρχιτεκτονική έχει αρχίσει να εκτρέπεται από τις αρχές της Clean Architecture.

Η σωστή προσέγγιση είναι να κρατάμε το FluentValidation για input validation, να τοποθετούμε τους επιχειρησιακούς κανόνες στο application layer και να αφήνουμε το domain model να προστατεύει την ακεραιότητα των entities.

nikosstit@gmail.com