DEV Community: nikosst

Πλήρης αρχιτεκτονική JWT, Middleware, Authorization, Permissions και Cache σε .NET

nikosst — Fri, 12 Jun 2026 13:34:24 +0000

Σε ένα σύγχρονο ASP.NET Core backend, το authentication και το authorization δεν είναι μία ενιαία διαδικασία, ούτε ένα σημείο κώδικα που “ανεβάζεις και τελείωσες”. Είναι μια ροή από στάδια, όπου κάθε στάδιο έχει διαφορετική ευθύνη και κανένα δεν πρέπει να μπερδεύεται με το άλλο.

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

Το πρώτο σημείο: Middleware και JWT validation

Κάθε request που έρχεται στο API δεν φτάνει ποτέ απευθείας στον controller. Περνάει πρώτα από το middleware pipeline της ASP.NET Core.

Εκεί βρίσκεται το authentication middleware, το οποίο είναι υπεύθυνο να ελέγξει το JWT token πριν συμβεί οτιδήποτε άλλο.

Σε αυτό το σημείο γίνεται ο έλεγχος της υπογραφής του token, του issuer, του audience και κυρίως του χρόνου ζωής του. Αν το token έχει λήξει, το request απορρίπτεται άμεσα και επιστρέφεται 401 Unauthorized χωρίς να εκτελεστεί τίποτα άλλο.

Αυτό σημαίνει πρακτικά ότι ο χρήστης “κόβεται” πριν φτάσει σε business logic, πριν φτάσει σε authorization, πριν γίνει οποιοδήποτε database call. Το middleware λειτουργεί σαν απόλυτο security gate.

Αν το token είναι έγκυρο, τότε δημιουργείται το HttpContext.User και το request συνεχίζει τη διαδρομή του μέσα στο pipeline.

Τι σημαίνει στην πράξη η λήξη του JWT

Η λήξη του JWT δεν είναι κάτι που το χειρίζεται η εφαρμογή ως business logic. Είναι καθαρά security rule.

Όταν ο χρόνος exp περάσει, το middleware απλά απορρίπτει το request. Δεν υπάρχει session, δεν υπάρχει “logout server side”, δεν υπάρχει κάποια επιπλέον διαδικασία. Το token θεωρείται άκυρο και τελείωσε εκεί η διαδρομή.

Ο client είναι αυτός που πρέπει να αντιδράσει σε αυτή την κατάσταση, είτε κάνοντας refresh token call είτε ζητώντας login ξανά.

Μετά το middleware: αρχίζει το authorization

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

Εδώ ξεκινά το authorization κομμάτι, το οποίο δεν είναι ένα απλό if statement, ούτε ένα δεύτερο middleware που “τρέχει μόνο του”. Είναι ένα policy-based σύστημα που ενεργοποιείται όταν ένα endpoint απαιτεί συγκεκριμένο δικαίωμα.

Για παράδειγμα, όταν ένα endpoint έχει attribute όπως “Orders.Read”, δεν σημαίνει ότι το framework απλά κοιτάει roles. Σημαίνει ότι ενεργοποιείται μια διαδικασία ελέγχου που θα αποφασίσει δυναμικά αν ο συγκεκριμένος χρήστης μπορεί να εκτελέσει αυτή την ενέργεια.

Πώς υλοποιείται στην πράξη το authorization

Στην πράξη, το authorization εκφράζεται μέσω policies και handlers. Το endpoint δηλώνει τι απαιτείται, και ο handler αποφασίζει αν ο χρήστης το πληροί.

Όταν ένα request φτάνει σε ένα endpoint με policy, η ASP.NET ενεργοποιεί τον αντίστοιχο authorization handler. Εκεί γίνεται η πραγματική αξιολόγηση.

Ο handler δεν παίρνει την απόφαση από μόνος του. Ζητάει δεδομένα από ένα service, το PermissionService, το οποίο είναι υπεύθυνο να βρει τα δικαιώματα του χρήστη.

Πού αποθηκεύονται τα permissions

Τα permissions δεν πρέπει να βρίσκονται μέσα στο JWT. Ο λόγος είναι ότι αλλάζουν συχνά, πρέπει να μπορούν να ανακληθούν και δεν πρέπει να “παγώνουν” μέσα σε ένα token.

Αντίθετα, αποθηκεύονται σε βάση δεδομένων σε κανονικό relational μοντέλο.

Υπάρχουν users, roles και permissions. Οι χρήστες συνδέονται με ρόλους και οι ρόλοι συνδέονται με permissions. Έτσι το σύστημα γίνεται δυναμικό και μπορεί να αλλάξει ανά πάσα στιγμή χωρίς να χρειάζεται reissue όλων των tokens.

PermissionService: το σημείο που διαβάζονται τα δικαιώματα

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

Όταν καλείται, κάνει join μεταξύ users, roles και permissions και επιστρέφει τη λίστα των δικαιωμάτων.

Αυτό το κομμάτι είναι business data access layer και όχι security logic. Η απόφαση για το αν επιτρέπεται μια ενέργεια γίνεται αλλού, όχι εδώ.

Cache γιατί υπάρχει και πού μπαίνει

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

Γι’ αυτό μπαίνει cache.

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

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

Έτσι το πρώτο request είναι πιο “βαρύ”, αλλά όλα τα επόμενα είναι σχεδόν άμεσα.

Όλη η ροή μαζί

Όταν όλα τα κομμάτια συνδεθούν μεταξύ τους, η ροή του request είναι καθαρή.

Το request έρχεται στο σύστημα και περνάει πρώτα από το middleware. Εκεί γίνεται ο έλεγχος του JWT. Αν το token έχει λήξει, το request σταματάει αμέσως. Αν είναι valid, δημιουργείται το user context και το request συνεχίζει.

Στη συνέχεια ενεργοποιείται το authorization layer, το οποίο βλέπει ότι το συγκεκριμένο endpoint απαιτεί συγκεκριμένα permissions. Ο authorization handler καλείται και ζητάει τα permissions του χρήστη από το PermissionService.

Το PermissionService πρώτα κοιτάει στην cache. Αν τα δεδομένα υπάρχουν εκεί, τα επιστρέφει άμεσα. Αν όχι, κάνει query στη βάση δεδομένων, τα αποθηκεύει στην cache και τα επιστρέφει.

Αν ο χρήστης έχει το απαιτούμενο permission, το request συνεχίζει στον controller και από εκεί μπορεί να καλέσει άλλα microservices ή να εκτελέσει business logic.

Γιατί αυτό δεν γίνεται bottleneck

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

Η cache απορροφά τη συντριπτική πλειοψηφία των requests, οπότε η βάση χρησιμοποιείται μόνο σε cache miss ή όταν αλλάξουν τα permissions.

Αυτό σημαίνει ότι το authorization δεν είναι hot path προς τη βάση. Είναι hot path προς τη cache, η οποία είναι εξαιρετικά γρήγορη.

Έτσι το σύστημα παραμένει σταθερό ακόμα και υπό μεγάλο φορτίο.

Διάγραμμα

┌───────────────────────────────────────────────────────────┐
│                       Client / SPA                        │
└───────────────────────┬───────────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────────┐
│                     HTTP Request                          │
│                  Authorization: Bearer JWT                │
└───────────────────────┬───────────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────────┐
│                 Authentication Middleware                 │
│                                                           │
│  Validate JWT Signature                                   │
│  Validate Issuer / Audience                               │
│  Validate Expiration (exp)                                │
└───────────────────────┬───────────────────────────────────┘
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
     Token Invalid               Token Valid
          │                           │
          ▼                           ▼
   401 Unauthorized          HttpContext.User Created
          │                           │
          │                           ▼
          │             ┌──────────────────────────────┐
          │             │    Token Revocation Check    │
          │             │                              │
          │             │ Redis / Cache / DB Lookup    │
          │             └──────────────┬───────────────┘
          │                            │
          │              ┌─────────────┴────────────┐
          │              │                          │
          │              ▼                          ▼
          │        Revoked                    Active
          │              │                          │
          │              ▼                          ▼
          │       401 Unauthorized        Authorization Layer
          │                                         │
          │                                         ▼
          │                     ┌────────────────────────────┐
          │                     │    Policy / Handler        │
          │                     │  Orders.Read Permission    │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                                   ▼
          │                     ┌────────────────────────────┐
          │                     │     PermissionService      │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                                   ▼
          │                     ┌────────────────────────────┐
          │                     │         Cache              │
          │                     │ (MemoryCache / Redis)      │
          │                     └─────────────┬──────────────┘
          │                                   │
          │                 ┌─────────────────┴────────────┐
          │                 │                              │
          │                 ▼                              ▼
          │           Cache Hit                      Cache Miss
          │                 │                              │
          │                 │                              ▼
          │                 │              ┌────────────────────────┐
          │                 │              │      Database          │
          │                 │              │ Users / Roles / Perms  │
          │                 │              └───────────┬────────────┘
          │                 │                          │
          │                 └──────────────┬───────────┘
          │                                │
          │                                ▼
          │                    Permission Decision
          │                                │
          │                    ┌───────────┴───────────┐
          │                    │                       │
          │                    ▼                       ▼
          │                 Allow                   Deny
          │                    │                       │
          │                    ▼                       ▼
          │             Controller              403 Forbidden
          │                    │
          │                    ▼
          │        Orders API / Customers API
          │
          │
          └─────────────────────────────────────────────────


              ACCESS TOKEN EXPIRES
                        │
                        ▼
                Client receives 401
                        │
                        ▼
                POST /auth/refresh
                        │
                        ▼
              Refresh Token Validation
                        │
                        ▼
                Refresh Token Store
                  (DB / Redis)
                        │
          ┌─────────────┴─────────────┐
          │                           │
          ▼                           ▼
      Invalid                    Valid
          │                           │
          ▼                           ▼
   Login Required          New JWT Issued
                                   │
                                   ▼
                          User Continues

Να θυμάσαι!

Ένα σωστό authentication και authorization σύστημα δεν βασίζεται σε ένα μόνο layer, αλλά σε καθαρό διαχωρισμό ευθυνών.

Το middleware είναι το security gate που απορρίπτει invalid tokens πριν μπουν στο σύστημα.

Το authorization layer είναι το σημείο που αποφασίζει αν ένας χρήστης έχει πρόσβαση σε ένα συγκεκριμένο endpoint.

Το PermissionService είναι το σημείο που διαβάζει την πραγματική κατάσταση από τη βάση δεδομένων.

Και η cache είναι απλώς ένα performance layer που μειώνει το load χωρίς να επηρεάζει τη λογική του συστήματος.

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

nikosstit@gmail.com

AI Development Tools για Σύγχρονους Software Engineers: Πότε να χρησιμοποιείς Agent, Ask, Plan, GitHub Copilot, Debugger, Git και Profiler

nikosst — Wed, 10 Jun 2026 14:41:33 +0000

Η ανάπτυξη λογισμικού το 2026 έχει αλλάξει δραματικά. Ο σύγχρονος προγραμματιστής δεν γράφει απλώς κώδικα· συνεργάζεται καθημερινά με AI Agents, εργαλεία αυτόματης δημιουργίας κώδικα, συστήματα debugging, profiling και πλατφόρμες διαχείρισης εκδόσεων. Η πρόκληση πλέον δεν είναι μόνο να γνωρίζει κάποιος προγραμματισμό, αλλά να ξέρει ποιο εργαλείο πρέπει να χρησιμοποιήσει σε κάθε στάδιο του Software Development Lifecycle.

Ένας senior developer ή software architect οφείλει να επιλέγει το κατάλληλο εργαλείο ανάλογα με το πρόβλημα που αντιμετωπίζει. Η λανθασμένη χρήση ενός AI Agent για απλό debugging μπορεί να οδηγήσει σε χαμένο χρόνο, ενώ η χρήση ενός profiler σε πρόβλημα λογικής δεν θα προσφέρει καμία αξία. Η πραγματική παραγωγικότητα προκύπτει όταν κάθε εργαλείο χρησιμοποιείται στο σωστό σημείο της διαδικασίας ανάπτυξης.

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

1. Ask Mode – Όταν χρειάζεσαι γνώση και καθοδήγηση

Το Ask Mode είναι η πιο απλή μορφή αλληλεπίδρασης με ένα AI σύστημα. Ο προγραμματιστής θέτει ερωτήσεις και λαμβάνει απαντήσεις, εξηγήσεις ή παραδείγματα.

Χρησιμοποίησέ το όταν:

Θέλεις να κατανοήσεις μια βιβλιοθήκη ή framework.
Αναζητάς βέλτιστες πρακτικές.
Θέλεις επεξήγηση ενός error message.
Χρειάζεσαι παραδείγματα κώδικα.

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

Απαιτείται αλλαγή σε πολλά αρχεία.
Χρειάζεται ανάλυση ολόκληρου project.
Πρέπει να γίνει refactoring μεγάλης κλίμακας.

Το Ask λειτουργεί σαν ένας πολύ έμπειρος συνάδελφος που απαντά σε ερωτήσεις, αλλά δεν αναλαμβάνει εργασία.

2. Plan Mode – Πριν γράψεις γραμμή κώδικα

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

Το Plan Mode δημιουργήθηκε ακριβώς για αυτόν τον λόγο.

Χρησιμοποίησέ το όταν:

Σχεδιάζεις νέο feature.
Θέλεις να σπάσεις ένα έργο σε tasks.
Κάνεις migration συστήματος.
Προετοιμάζεις αρχιτεκτονική λύση.

Παράδειγμα

Αντί να ζητήσεις:

"Γράψε authentication"

ζήτησε:

"Σχεδίασε authentication architecture για .NET microservices με JWT και refresh tokens."

Το αποτέλεσμα θα είναι σαφώς καλύτερο.

Οι senior engineers επενδύουν περισσότερο χρόνο στον σχεδιασμό παρά στην υλοποίηση.

3. Agent Mode – Ο ψηφιακός συνεργάτης

Το Agent Mode αποτελεί τη μεγαλύτερη εξέλιξη των τελευταίων ετών.

Ένας Agent δεν απαντά απλώς σε ερωτήσεις. Μπορεί να:

διαβάσει ολόκληρο repository,
αναλύσει requirements,
τροποποιήσει πολλαπλά αρχεία,
δημιουργήσει tests,
κάνει refactoring,
ανοίξει Pull Requests.

Χρησιμοποίησέ το όταν:

Υπάρχει μεγάλο codebase.
Θέλεις αυτοματοποίηση εργασιών.
Κάνεις modernization legacy εφαρμογών.
Χρειάζεσαι end-to-end υλοποίηση.

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

Έχεις μια απλή απορία.
Χρειάζεται μόνο ένα μικρό snippet.

Ο Agent λειτουργεί περισσότερο σαν junior-to-mid developer παρά σαν chatbot.

4. GitHub Copilot – Ο καθημερινός βοηθός προγραμματισμού

Το GitHub Copilot είναι το πιο διαδεδομένο AI εργαλείο ανάπτυξης λογισμικού.

Βρίσκεται μέσα στο IDE και προσφέρει:

autocomplete,
code generation,
chat assistance,
code reviews,
agent workflows.

Χρησιμοποίησέ το όταν:

Γράφεις καθημερινό κώδικα.
Δημιουργείς APIs.
Υλοποιείς CRUD λειτουργίες.
Γράφεις unit tests.

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

Μικρό context switching.
Εξαιρετική ενσωμάτωση σε VS Code.
Υψηλή παραγωγικότητα.

Περιορισμοί

Δεν κατανοεί πάντα ολόκληρη την αρχιτεκτονική.
Μπορεί να παράγει λανθασμένο κώδικα.
Απαιτεί code review.

5. Debugger – Το εργαλείο που δεν αντικαθίσταται

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

Χρησιμοποίησέ τον όταν:

Υπάρχει runtime σφάλμα.
Οι τιμές μεταβλητών είναι λανθασμένες.
Το σύστημα συμπεριφέρεται διαφορετικά από το αναμενόμενο.

Βέλτιστη πρακτική

Reproduce.
Breakpoint.
Step Through.
Root Cause Analysis.

Οι καλύτεροι developers δεν μαντεύουν. Μετρούν.

6. Git – Η ασφάλεια του project

Το Git είναι το θεμέλιο κάθε σύγχρονης ομάδας ανάπτυξης.

Χρησιμοποίησέ το για:

Version control.
Feature branching.
Pull Requests.
Code Reviews.
Rollback.

Senior πρακτικές

Feature branches.
Squash merges.
Atomic commits.
Protected main branch.

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

7. Profiler – Όταν η εφαρμογή είναι αργή

Ένα από τα συνηθέστερα λάθη είναι η βελτιστοποίηση χωρίς μετρήσεις.

Ο profiler δείχνει:

CPU bottlenecks,
memory leaks,
database latency,
inefficient algorithms.

Χρησιμοποίησέ τον όταν:

Υπάρχουν προβλήματα απόδοσης.
Αυξάνεται η κατανάλωση μνήμης.
Υπάρχουν μεγάλοι χρόνοι απόκρισης.

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

Υπάρχει λογικό bug.
Το πρόβλημα είναι business logic.

8. Test Generation – Η ασπίδα της ποιότητας

Τα σύγχρονα AI εργαλεία μπορούν να δημιουργούν:

Unit Tests
Integration Tests
API Tests
Regression Tests

Χρησιμοποίησέ τα όταν:

Προσθέτεις νέα features.
Κάνεις refactoring.
Κάνεις modernization.

Ένα καλό σύστημα testing μειώνει δραματικά το τεχνικό χρέος.

Να θυμάσαι!

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

Για καθημερινό development, το GitHub Copilot παραμένει η πιο αποδοτική επιλογή. Για σύνθετες αλλαγές σε μεγάλα codebases, οι AI Agents και το Codex προσφέρουν τεράστια επιτάχυνση. Για σχεδιασμό αρχιτεκτονικής, το Plan Mode μειώνει τα λάθη πριν γραφτεί κώδικας. Για κατανόηση και εκπαίδευση, το Ask Mode είναι ιδανικό. Όταν εμφανίζονται σφάλματα, ο Debugger παραμένει αναντικατάστατος, ενώ ο Profiler είναι το μοναδικό εργαλείο που μπορεί να αποδείξει με δεδομένα πού πραγματικά χάνεται η απόδοση.

Οι κορυφαίοι software engineers του 2026 δεν είναι αυτοί που γράφουν περισσότερο κώδικα. Είναι εκείνοι που ξέρουν να συνδυάζουν σωστά ανθρώπινη εμπειρία, αρχιτεκτονική σκέψη και AI εργαλεία, δημιουργώντας λογισμικό ταχύτερα, ασφαλέστερα και με υψηλότερη ποιότητα.

nikosstit@gmail.com

Local Time, UTC, Offset και Epoch: Ο απόλυτος οδηγός για developers

nikosst — Tue, 09 Jun 2026 21:29:38 +0000

Το πρόβλημα της ώρας

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

Αν ένας χρήστης στην Αθήνα δημιουργήσει μια παραγγελία στις 20:00 και ένας άλλος στη Νέα Υόρκη τη δει στις 13:00, ποια είναι η "σωστή" ώρα;

Αν μια εφαρμογή αποθηκεύσει μόνο το 20:00, χωρίς να γνωρίζει τη ζώνη ώρας, τότε η πληροφορία είναι πρακτικά άχρηστη.

Αυτός είναι ο λόγος που υπάρχουν έννοιες όπως:

Local Time
UTC
UTC Offset
Epoch / Unix Timestamp

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

Local Time

Το Local Time είναι η ώρα που βλέπει ο χρήστης στη χώρα του.

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

Αθήνα:    2026-06-09 20:00
Λονδίνο:  2026-06-09 18:00
Νέα Υόρκη:2026-06-09 13:00

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

Πότε χρησιμοποιούμε Local Time;

Μόνο για εμφάνιση στον χρήστη.

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

Ημερομηνία παραγγελίας
Ώρα δημιουργίας post
Ημερολόγιο συναντήσεων
Reports προς τον χρήστη

Πότε ΔΕΝ το αποθηκεύουμε;

Σχεδόν ποτέ ως μοναδική πηγή αλήθειας.

Αν αποθηκεύσεις:

2026-06-09 20:00

δεν γνωρίζεις:

Σε ποια χώρα δημιουργήθηκε
Σε ποια ζώνη ώρας ανήκει
Αν ίσχυε θερινή ώρα (DST)

UTC (Coordinated Universal Time)

Το UTC είναι η παγκόσμια αναφορά χρόνου.

Όλες οι ζώνες ώρας υπολογίζονται σε σχέση με αυτό.

Παράδειγμα:

UTC: 2026-06-09 17:00

Την ίδια στιγμή με βάση την UTC ώρα μπορούμε να έχουμε:

στην Αθήνα   UTC+3 -> 20:00
στο Λονδίνο UTC+1 -> 18:00
στη Νέα Υόρκη UTC-4 -> 13:00

Πότε χρησιμοποιούμε UTC;

Σχεδόν πάντα στο backend.

Αποθηκεύουμε:

2026-06-09T17:00:00Z

Το Z σημαίνει UTC.

Γιατί;

Επειδή:

Δεν αλλάζει με DST
Δεν εξαρτάται από χώρα
Είναι παγκόσμιο σημείο αναφοράς

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

Store in UTC, display in Local Time.

UTC Offset

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

UTC+3
UTC+2
UTC-5
UTC+9

Για την Αθήνα:

Χειμώνας -> UTC+2
Καλοκαίρι -> UTC+3

Χειμώνας -> UTC+2
Καλοκαίρι -> UTC+3

Παράδειγμα

2026-06-09T20:00:00+03:00

σημαίνει:

Τοπική ώρα: 20:00
Offset: +03:00
UTC: 17:00

Πότε αποθηκεύουμε Offset;

Όταν θέλουμε να γνωρίζουμε ακριβώς τι έβλεπε ο χρήστης τη στιγμή της καταχώρησης.

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

Αεροπορικά εισιτήρια
Νομικά έγγραφα
Ιατρικά συστήματα
Financial systems

Epoch / Unix Timestamp

Το Epoch είναι η πιο "καθαρή" αναπαράσταση χρόνου.

Μετράει πόσα δευτερόλεπτα έχουν περάσει από:

1970-01-01 00:00:00 UTC

Αυτό ονομάζεται Unix Epoch. epochconverter

Παράδειγμα:

1780968655

Αυτός είναι απλά ένας αριθμός.

Δεν περιέχει:

Timezone
Offset
DST

Μόνο μια απόλυτη χρονική στιγμή.

Γιατί οι developers αγαπούν τα Epochs;

Επειδή οι συγκρίσεις είναι πανεύκολες.

Αν έχεις:

1780968655
1780968755

ξέρεις αμέσως ότι το δεύτερο συνέβη αργότερα.

Δεν χρειάζεται:

μετατροπή timezone
parsing
date calculations

Timestamp ως Long

Στη .NET και στις περισσότερες γλώσσες το Epoch αποθηκεύεται ως:

long timestamp

Παράδειγμα:

1780968655

1780968655000

(σε milliseconds)

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

Databases
APIs
Event streams
Kafka
Message queues
Logging systems

Timestamp ως String

Παράδειγμα:

2026-06-09T17:00:00Z

2026-06-09T20:00:00+03:00

Αυτό είναι συνήθως ISO 8601 format.

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

Αναγνώσιμο από άνθρωπο
Περιέχει timezone πληροφορία
Ιδανικό για APIs

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

Μεγαλύτερο μέγεθος
Πιο αργό parsing

Timestamp ως DateTime

Στη .NET:

DateTime DateTimeOffset

Σήμερα οι περισσότεροι senior developers προτιμούν:

DateTimeOffset

γιατί περιέχει και το offset.

Παράδειγμα:

2026-06-09 20:00 +03:00

Τι να χρησιμοποιήσω τελικά;

Για αποθήκευση στη βάση

Προτίμησε:

UTC ή DateTimeOffset

Για APIs

Προτίμησε:

ISO 8601

Παράδειγμα:

{
  "createdAt": "2026-06-09T17:00:00Z"
}

Για logs

Προτίμησε:

UTC

ή Epoch.

Για sorting και performance

Προτίμησε:

Epoch Timestamp

Για εμφάνιση στον χρήστη

Προτίμησε:

Local Time

με βάση τη ζώνη ώρας του χρήστη.

Τι είναι το Epoch Converter;

Το Epoch Converter είναι ένα πολύ γνωστό εργαλείο για developers που μετατρέπει:

Epoch → Human Readable Date
Date → Epoch
UTC ↔ Local Time
Seconds ↔ Milliseconds ↔ Microseconds

και υποστηρίζει διάφορες μορφές timestamps.

Είναι εξαιρετικά χρήσιμο όταν κάνεις debugging logs, APIs ή βάσεις δεδομένων.

Συμπέρασμα

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

Στην πραγματικότητα, ο χρόνος είναι ένα παγκόσμιο πρόβλημα συγχρονισμού. Το Local Time εξυπηρετεί τον χρήστη, το UTC εξυπηρετεί το σύστημα, το Offset διατηρεί το πραγματικό τοπικό πλαίσιο μιας στιγμής και το Epoch παρέχει την πιο απλή και απόλυτη αναπαράσταση του χρόνου.

Όταν σχεδιάζεις ένα σύστημα, η σωστή ερώτηση δεν είναι «ποιο type να χρησιμοποιήσω;». Η σωστή ερώτηση είναι:

Θέλω να αποθηκεύσω πώς είδε ο χρήστης την ώρα ή ποια ακριβώς στιγμή συνέβη το γεγονός;

Αν απαντήσεις σωστά σε αυτή την ερώτηση, τότε η επιλογή μεταξύ Local Time, UTC, Offset και Epoch γίνεται σχεδόν αυτονόητη. Οι καλύτερες εφαρμογές δεν είναι αυτές που χειρίζονται σωστά τις ημερομηνίες στις εύκολες περιπτώσεις· είναι αυτές που συνεχίζουν να λειτουργούν σωστά όταν οι χρήστες βρίσκονται σε διαφορετικές ηπείρους, αλλάζουν ζώνες ώρας ή όταν η θερινή ώρα αποφασίζει να σου χαλάσει το βράδυ παραγωγής.

Το πιο γνωστό και ευρέως χρησιμοποιούμενο εργαλείο μετατροπής Unix timestamps για developers.

Online εργαλείο μετατροπής Unix Epoch timestamps σε αναγνώσιμες ημερομηνίες και αντίστροφα.

Developer-focused εργαλείο για μετατροπές Epoch, UTC και ISO 8601 timestamps.

Web εφαρμογή για μετατροπές Unix time, debugging και date calculations.

Minimalistic converter για γρήγορη μετατροπή Epoch timestamps και ημερομηνιών.

Online converter με υποστήριξη Epoch, UTC, timezone conversions και date utilities.

Εργαλείο μετατροπής Unix timestamps με έμφαση σε προγραμματιστικές χρήσεις και APIs.

Πληροφοριακό site για Unix Time με converter και επεξήγηση του Epoch format.

Unix timestamp calculator με δυνατότητες date arithmetic και μετατροπών χρόνου.

nikosstit@gmail.com

ASP.NET Core Deep Dive: ViewData vs ViewBag vs TempData vs Session

nikosst — Thu, 04 Jun 2026 10:22:14 +0000

As ASP.NET Core developers, we often need to transfer data between controllers, views, requests, and even user sessions. The framework provides several mechanisms for this purpose: ViewData, ViewBag, TempData, and Session.

Many junior developers learn these concepts separately and end up using them interchangeably. In reality, each one solves a completely different problem, has a different lifecycle, and affects maintainability in different ways.

Understanding when to use each mechanism is essential for building scalable and maintainable MVC applications.

Why So Many Options Exist?

Imagine an e-commerce application.

Sometimes you need to pass data from a controller to a view.

Sometimes you need data to survive a redirect.

Sometimes you need information available across multiple requests.

Sometimes you need user-specific state that remains available during an entire browsing session.

These are fundamentally different requirements. Microsoft introduced different mechanisms because a single solution would either be inefficient or overly complex.

The key distinction is scope and lifetime.

ViewData

ViewData is the oldest mechanism inherited from classic ASP.NET MVC.

Internally, it is a dictionary of type:

ViewDataDictionary

which stores data as key-value pairs.

A controller can populate the dictionary and the view can read from it.

public IActionResult Details()
{
    ViewData["Title"] = "Product Details";
    ViewData["ProductCount"] = 15;

    return View();
}

Inside the Razor view:

<h1>@ViewData["Title"]</h1>

<p>Total Products: @ViewData["ProductCount"]</p>

Although simple, ViewData has a major weakness.

Because everything is stored as object, type casting becomes necessary.

int count = (int)ViewData["ProductCount"];

This means compile-time safety is lost.

If someone changes the type later, the application may fail at runtime.

For this reason, ViewData is generally considered suitable only for small pieces of UI-related information.

Examples include:

Page titles
Breadcrumb text
Display messages
Minor metadata

Using ViewData for complex business objects usually creates maintenance problems.

ViewBag

ViewBag was introduced to make ViewData easier to use.

Interestingly, ViewBag is not a separate storage mechanism.

Internally it wraps ViewData using dynamic properties.

When you write:

ViewBag.Title = "Product Details";

ASP.NET Core actually stores the value inside ViewData.

The equivalent ViewData version is:

ViewData["Title"] = "Product Details";

The controller:

public IActionResult Details()
{
    ViewBag.ProductName = "Gaming Laptop";
    ViewBag.Price = 1500;

    return View();
}

The view:

<h2>@ViewBag.ProductName</h2>

<p>Price: @ViewBag.Price €</p>

The syntax is cleaner and easier to read.

However, ViewBag introduces another problem: the use of dynamic.

Consider:

ViewBag.ProductName

the compiler will not detect the typo.

The error appears only during execution.

For small MVC applications this may not matter, but in enterprise systems it becomes a source of bugs.

That is why many senior developers prefer strongly typed ViewModels over both ViewData and ViewBag.

ViewData vs ViewBag

Since both use the same underlying storage, their lifecycle is identical.

They exist only during the current request.

Once the response is sent, the data disappears.

The following diagram describes their lifecycle conceptually:

Controller → View → Destroyed

Neither survives redirects.

Consider:

public IActionResult Save()
{
    ViewBag.Message = "Saved";

    return RedirectToAction("Index");
}

The message will be lost.

The redirect creates an entirely new HTTP request.

This is where TempData enters the picture.

TempData

TempData was designed specifically for passing data between requests.

Most commonly, it is used after redirects.

A typical scenario is the Post-Redirect-Get pattern.

[HttpPost]
public IActionResult Save(Product product)
{
    // Save logic

    TempData["Success"] = "Product saved successfully";

    return RedirectToAction("Index");
}

Then:

public IActionResult Index()
{
    return View();
}

Inside the view:

@if (TempData["Success"] != null)
{
    <div class="alert alert-success">
        @TempData["Success"]
    </div>
}

The user sees the message after the redirect.

This would not be possible using ViewData or ViewBag.

The Special Behavior of TempData

TempData behaves differently from the other mechanisms.

By default, data is automatically removed after it is read.

For example:

var message = TempData["Success"];

After this line executes, the value is marked for deletion.

If you need to preserve it:

TempData.Keep();

Or:

TempData.Keep("Success");

You can also inspect a value without removing it:

var message = TempData.Peek("Success");

This makes TempData ideal for:

Success notifications
Error messages
Wizard workflows
Redirect scenarios

It is not suitable for long-term storage.

Session

Session solves a completely different problem.

While ViewData, ViewBag, and TempData focus on controller/view communication, Session stores user-specific state across many requests.

Imagine a shopping cart.

A user may browse dozens of pages before checking out.

The cart must remain available throughout the session.

HttpContext.Session.SetString(
    "Username",
    "Nick"
);

Reading:

var username =
    HttpContext.Session.GetString(
        "Username"
    );

Unlike ViewData and TempData, Session can remain available for minutes or hours depending on configuration.

Configuring Session in ASP.NET Core

First, register Session services:

builder.Services.AddDistributedMemoryCache();

builder.Services.AddSession(options =>
{
    options.IdleTimeout =
        TimeSpan.FromMinutes(30);
});

Then enable middleware:

app.UseSession();

Now Session becomes available through:

HttpContext.Session

Without this configuration, Session operations will fail.

Session and Complex Objects

Session natively supports strings and byte arrays.

For custom objects, serialization is required.

Example:

public class ShoppingCart
{
    public int ItemCount { get; set; }
}

Store:

var cart = new ShoppingCart
{
    ItemCount = 5
};

HttpContext.Session.SetString(
    "Cart",
    JsonSerializer.Serialize(cart)
);

Retrieve:

var json =
    HttpContext.Session.GetString(
        "Cart"
    );

var cart =
    JsonSerializer.Deserialize<ShoppingCart>(
        json
    );

This approach is common in real-world applications.

Performance Considerations

A frequent mistake is treating Session as a database.

Session should store only small amounts of user-specific state.

Storing large datasets increases memory consumption and hurts scalability.

In distributed environments, Session data often ends up in:

Redis
SQL Server
Distributed Cache Providers

The larger the Session, the slower the application becomes.

A good rule is simple:

If data belongs in a database, keep it in a database.

What Senior Developers Usually Choose

In modern ASP.NET Core applications, strongly typed ViewModels are generally preferred over ViewData and ViewBag.

Example:

public class ProductViewModel
{
    public string Name { get; set; }

    public decimal Price { get; set; }
}

Controller:

public IActionResult Details()
{
    var model =
        new ProductViewModel
        {
            Name = "Laptop",
            Price = 1500
        };

    return View(model);
}

View:

@model ProductViewModel

<h2>@Model.Name</h2>

<p>@Model.Price €</p>

This provides:

Compile-time checking
IntelliSense support
Easier refactoring
Better maintainability

Consequently, ViewData and ViewBag are often reserved for small UI metadata.

Modern ASP.NET Core Perspective

While ViewData, ViewBag, TempData, and Session remain fully supported in ASP.NET Core, their role has evolved. Modern applications favor strongly typed ViewModels, DTOs, and API-based architectures because they provide better maintainability, testability, and compile-time safety. ViewData and ViewBag are now typically reserved for small UI-related values, TempData remains a practical solution for passing messages across redirects, and Session is used more selectively for user-specific state. The key takeaway is that these mechanisms are still valuable, but in contemporary ASP.NET Core development they are no longer the primary way application data is modeled and transferred.

Final Verdict

The biggest mistake developers make is viewing these four mechanisms as alternatives. They are not.

ViewData and ViewBag exist to pass data from a controller to a view during a single request.

TempData exists to transfer data between requests, especially after redirects.

Session exists to maintain user-specific state across multiple requests and pages.

When selecting one, ask a single question:

How long should the data live?

If the answer is until the view renders, use ViewData, ViewBag, or preferably a ViewModel.

If the answer is until the next request, use TempData.

If the answer is throughout the user's interaction with the application, use Session.

Understanding this distinction is one of those small architectural decisions that separates maintainable ASP.NET Core applications from those that become increasingly difficult to evolve over time.

Συμπεράσματα

Ένα από τα μεγαλύτερα λάθη που κάνουν οι προγραμματιστές είναι να αντιμετωπίζουν τα ViewData, ViewBag, TempData και Session ως εναλλακτικές λύσεις για το ίδιο πρόβλημα. Στην πραγματικότητα, δεν είναι.

Το ViewData και το ViewBag υπάρχουν για να μεταφέρουν δεδομένα από έναν Controller σε ένα View κατά τη διάρκεια του ίδιου HTTP request.

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

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

Όταν έρχεται η στιγμή να επιλέξετε ποιον μηχανισμό θα χρησιμοποιήσετε, κάντε πρώτα μία απλή ερώτηση:

«Για πόσο χρονικό διάστημα πρέπει να παραμείνουν διαθέσιμα αυτά τα δεδομένα;»

Αν τα δεδομένα χρειάζονται μόνο μέχρι να γίνει η απόδοση του View, τότε το ViewData, το ViewBag ή ακόμη καλύτερα ένα ισχυρά τυποποιημένο ViewModel αποτελούν τις κατάλληλες επιλογές.

Αν τα δεδομένα πρέπει να επιβιώσουν μέχρι το επόμενο request, τότε το TempData είναι η σωστή λύση.

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

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

nikosstit@gmail.com

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

Πότε το parallelism γίνεται πρόβλημα

Για να δούμε πόσα logical CPUs βλέπει ο SQL Server μπορούμε να τρέξουμε SELECT cpu_count FROM sys.dm_os_sys_info;, όμως το αν “αξίζει” MAXDOP = 1 δεν κρίνεται μόνο από τον αριθμό των πυρήνων. Σε μικρά συστήματα με λίγους πυρήνες, πολλά ταυτόχρονα sessions και κυρίως OLTP workload, το υπερβολικό parallelism μπορεί να δημιουργήσει ανταγωνισμό για CPU workers και να κάνει τα queries να μπλοκάρουν μεταξύ τους. Παρ’ όλα αυτά, το MAXDOP = 1 είναι ακραία ρύθμιση, γιατί απενεργοποιεί το parallel execution για τα queries· συνήθως πρώτα εξετάζουμε MAXDOP 2, 4 ή 8, το cost threshold for parallelism, τα wait stats, το CPU pressure, το είδος του workload, τον αριθμό των ταυτόχρονων χρηστών και αν το πρόβλημα είναι όντως CPU ή κακό execution plan/indexing. Με απλά λόγια: δεν λέμε “πάνω ή κάτω από Χ πυρήνες βάζω MAXDOP 1”, αλλά “βάζω χαμηλότερο MAXDOP όταν το parallelism αποδεδειγμένα χειροτερεύει τη συνολική απόδοση”.

Το βασικό λάθος: 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. Ο στόχος είναι να ξέρεις πού ανήκει το κάθε πράγμα και να το τοποθετείς σωστά.

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