1. Szerver oldali fejlesztés korszerű
módszerekkel C# nyelven
Tóth Krisztián Gyula
Horváth Gábor

2. Hagyományos vékony kliens
architektúra

3. Felhő általában
• Szerver + kliens = felhő?
• Szolgáltatás
▫ Azure, Bluemix
▫ Futtatják a szoftverünk
▫ Kiegészítő funkciókkal és rendszerekkel látnak el
• Infrastruktúra
▫ Ad egy hardveres, szoftveres és hálózati keretet az
alkalmazásunknak

4. Felhők jellemzői
• Nem tudjuk hol van az adatbázis
• Nem tudjuk honnan fut az alkalmazás
• De nem is érdekel!
• A lényeg, hogy bármikor bárhonnan elérhető
• Elfedi a számunkra lényegtelen rétegeket,
részletek

5. A felhők előnyei
• Terhelés elosztás
• Masszív
• Jól skálázható
• Biztonságos

6. Felhő a szerverfejlesztőnek
• A szoftver egyszerre több példányban is futhat
• Stateless jelleg
• Hívások párhuzamos végrehajtása
• Az alkalmazás legfelső szintje gyakorlatilag
független HTTP hívások gyűjteménye

7. REST – Reprezentational State Transfer
• Hálózati szoftver architektúra (szabályok, elvek)
• Kommunikáció:
▫ HTTP
 GET
 POST
 PUT
 DELETE
▫ XML
▫ JSON

8. REST – Architektúrális megkötések
• Stateless (nem tárolunk a kliensről semmi
információt a hívások között)
• Rétegelt sktruktúra
▫ A kliens nem tudja, hogy valójában egy szervert,
vagy egy köztes réteget hívott meg
• A köztes réteg elosztja a terhelést (middleware)
• Egységes interfész!
• Mindegy milyen kliens kapcsolódik hozzá

9. Példa
• Nagy vonalakban a következőről van szó:
▫ Akár a böngészőmből elindítok, egy POST vagy
GET kérést, amit szinte bármely szerveroldali
platform képes kezelni.
▫ Ezt a kérést a túloldalon a Web API fogadja,
feldolgozza és visszalök egy JSON csomagot,
amelyet a kliens oldal fel tud dolgozni.

10. Kommunikációs modellek
• RR (Request – Response)

11. Amikről szó lesz:
• Szerver oldali rétegek
• Repository – Unit of Work
• Üzleti logika
• API Controllers

12. Architectúra
Kliens
Szerver
DB
Controllers
Services
UnitofWork
Repository
EF - DbContext

13. Adat elérési réteg - Repository pattern
• Amikor adatbázissal dolgozunk gyakorlatilag minden
amit teszünk visszavezethető négy alapműveletre
▫ Get, Create, Update, Delete
• Az alapműveleteket kivezethetjük, a részleteket pedig
elrejtjük.
▫ Egy adott entitásra vonatkozóan
 Az se baj ha generikus…
▫ Honnan, hogyan? -> nem érdekel! 
▫ Egy helyen kerül megvalósításra! 
• Beépíthetünk rendezést, lapozás-támogatást, stb…

14. Adat elérési réteg - Unit of Work
• Tartalmazza az összes Repository-t
• Kezeli a kontextust amivel dolgozunk
 EntityFramework DbContext / Fake
• Adatok forrásának és a kontextus elfedése
▫ Az üzleti logika réteg teljesen elválasztva
▫ Tesztelhetőség
• Megj:
▫ Ef Context gyakorlatilag egy Unit of Work
 Ctx.Set<XY>().Add/Remove.. = Repository

15. Service réteg
• A service réteg funkció kerülnek kivezetésre a
kliensek számára
• Ide kerül az üzleti logika
• Egymásba ágyazva is felhasználhatóak
• Unit of Work-ből veszi az adatokat

16. Controller réteg
• Legkülső réteg ami elérhető a kliensek számára
▫ Hívható HTTP végpontok – WebAPI
• A service rétegre épülve nyújtja a
szolgáltatásokat

17. Architectúra összefoglalása
Kliens
Szerver
DB
Controllers
Services
UnitofWork
Repository
EF - DbContext

18. Amikről szó lesz:
• ORM
• Code first
• Lekérdezése
• Query - Response

19. Adatbázis – Entity Framework
• Az Entity Framework egy ún. ORM (Object-
Relational Mapping) eszköz, amely lehetővé
teszi, hogy egy adatbázis tábláit C# osztályokká
képezzünk le
• Nem írunk sql lekéréseket!
• Lambda kifejezésekkel történik a lekérdezés

20. Code first
• Objektum orientált adatszerkezet tervezünk és
implementálunk.
• Az EF a háttérben elkészíti belőle az adatbázist.
• Segítség: fluent api
• Virtual – lazy loading

21. Cache
• Az adatokat az EF csak akkor teszi a memóriába
amikor használni szeretnénk (például lekérjük
egy user nevét).
• A felhasznált adatok a memóriában maradnak a
hívás végéig.

22. Lekérdezés építés
• Az sql lekérdezések akkor jutnak el az
adatbázishoz, amikor szükség van rá, vagy ha
kikényszerítjük.
• IQueryable objektumokon, lambda kifejezéssel
történő lekérdezés során az épülő lánc, csupán
egy épülő sql lekérdezést jelent.
• A lekérdezés akkor fut le ténylegesen, amikor a
.ToList() metódust meghívjuk rajt.

23. Lekérdezés építés

24. CRUD Táblázatok lekérésinek kezelése
• Az alapprobléma a webes CRUD táblázatok
lekéréseinek egységes és könnyű kezelése
• Elvárások:
▫ Globális kerső
▫ Oszlopok alapján való (és kapcsolatos) kereső
▫ Rendezve lekérés
▫ Lapozhatóság
▫ Laponkénti elemszám

25. CRUD Táblázat

26. API Query – API Response

27. API Query – API Response
• Működése:
▫ Futási időben az objektumban tárolt string
adatokból lambda kifejezést fordít és hajt végre.
▫ IQueryable-el dolgozik így a végén csupán
egyetlen sql lekérdezés lesz belőle.
▫ Generikus, ezért bármely kollekción hívva
működik. Akár EF nélkül is!

28. Tranzakció kezelés
• SaveChanges() metódussal mentünk a db-be
• Az EF automatikusa mappeli a változásokat és
egyetlen sql tranzakcióba menti őket.

29. Amikről szó lesz:
• Felhasználó azonosítás
• Token-ek
• Jogosultság kezelés
• Authorizációs filterek

30. Authentikáció
• A meghívja az authentikációs végpontot, vagyis
elküldi a felhasználó nevét és jelszavát.
• Létrejön az adatbázisban egy token a
felhasználónak, amit visszakap.
• A későbbi hívásokban már csak ezt a token-t
küldi el.
• A token rövid ideig él (maximum néhány óráig),
vagyis ha lehalásszák, akkor is csak rövid ideig
használható.

31. Authorizáció

32. Authorizáció - jogosultság kezelés
• Filterek segítségével
▫ SystemAdminAuthorization
▫ SuperAdminAuthorization
▫ BasicAuthorization
 Megadhatjuk, hogy milyen rendszeren belüli
jogosultságok szükségesek

33. Amikről szó lesz:
• Dependency injection
• Automatikus szerver háttér folyamatok
• Szerveren elérhető végpontok kipróbálása
• Szerver -> Kliens értesítések
• Szerver diagnosztika

34. Unity - Dependency injection
• Konfigurációban megadjuk, hogy ha adott típusú
referencia kell, akkor milyen konkrét típust
hozzon létre.
▫ Automatikusan, rekurzívan képes feloldani
 Konstruktor paraméterek
 Publikus property-k

35. Dependency injection
• Miért jó?
▫ Konfigurálható példányosítás -> Függőség feloldás
▫ Inverse of Control
▫ Éles kódban:
 Modul példányosítása, ami tényleges adatbázis
műveleteket végez
▫ Teszteléskor:
 Olyan modult példányosítunk, ami nem áll
kapcsolatban az adatbázissal
 Szimulált adat kezelés
 Mock/Fake

36. DI Példa

37. DI életciklus managment
Feloldáskor jöjjön-e létre az objektum?
• Unity:
▫ TransientLifetimeManager
 Feloldási időben történő létrehozás
▫ ContainerControlledLifetimeManager
 Egy példány a rendszerben (Singleton)
▫ HierarchicalLifetimeManager
▫ ...

38. Hangfire
• Cél: Automatizált szerver oldali folyamatok
végrehajtása
• Lehetőséget ad különböző típusú folyamat
bejegyzésekre a szerver oldalon történő későbbi
végrehajtásra
▫ Ezek lehetnek:
 Ismétlődő folyamatok (Például: Engine hívás)
 Folyamatos
 Késleltetett
 Fire-and-forget

39. Hangfire - Dashboard

40. Swagger
• Cél: Front-end és a Back-end oldal közötti
fejlesztés könnyítése
• Segéd alkalmazás a végpontok felderítésére és
kipróbálásra is
▫ Milyen route-on érhető el?
▫ Hogyan kell paraméterezni?
▫ Mi a válasz JSON?
▫ …

41. Swagger - Példa
Api Controllers

42. Swagger - Példa

43. SignalR
• Cél: “valós-idejű” webalkalmazás készítés
• Szerver maga képes értesíteni a kliens(eke)t
▫ Notification-ok küldése
▫ Oldal frissítés kikényszerítése
 Például: Tőzsdei alkalmazás -> Árfolyam változások
• WebSocket-et használ (ahol lehetséges)
▫ Gyors, kis méretű forgalom
▫ Nincs pooling

44. Glimpse
• Cél: Szerveren történő folyamatok
diagnosztikája miközben használjuk a felületet
• Több mint egy Chrome dev tools
▫ Valós időben láthatjuk a szerveren történő:
 Kérésinket és a válaszidőket
 Adatbázis lekérdezéseket
 …

45. Amikről szó lesz:
• Miért is kell teszteket írni?
• Egység tesztelés
• Integrációs tesztelés
• Mock keretrendszerek

46. Miért ne írjunk teszteket !?
• Plusz munka, van nélkülük is elég igény a
megrendelőtől
• Változik a kód ->
▫ Karban kell tartani -> Teher
 Rossz minőségű tesztek -> Még nagyobb teher
 „Jó tesztekre nincs idő” -> Akkor meg már minek
• De!!
▫ Fejlesztés = A kód változik!
 Nincsenek tesztek!? -> Biztos minden jól működik még
most is?
 Át merjek írni bármit is? -> Nem változik a kód! -> ….

47. De írjunk!
• A tesztek tesznek képessé!
• Minél nagyobb területet fedtünk le annál kevésbé van mitől félnünk.
• Akár Kata-nak is kiváló. (Egy kis bemelegítő )
• Hogyan?
▫ Egyszerű és érthető, nem kell hogy hatékony legyen (de azért ne legyen
lassú)!
▫ F.I.R.S.T elvek
 Gyors – Fusson le gyorsan
 Független – Ne befolyásolják egymást
 Megismételhető – Környezet függetlenül
 Egyértelmű – Siker vagy kudarc
 Időszerű – Üzemi kód írás előtt/kor/utána/félévvel … -> Legyen a kódunk
tesztelhető
• Tervezést és gondosságot igényel de hosszú távon mindig megtérül!

48. Unit Vs Integrációs tesztek
Egység tesztelés Integrációs tesztelés
• Rész funkciót tesztel
• Szimulált környezetben
▫ Nincs adatbázis
▫ Függőségekre dummy
objektumok
• Gyors lefutás
• Egyszerű következtetés a hiba
okára
▫ Egyszerűen javítható
• Futtassuk őket gyakran
• Minél nagyobb egészét
próbáljuk lefedni a
rendszernek
• Valós környeztet hozunk létre
▫ Tényleges adatbázis
kapcsolat, stb..
▫ A függőségekre nincsenek
dummy objektumok
• Lassú lefutás
▫ Tényleges rendszer
inicializálás
• Elég hetente futtatni

49. Mock/Fake
• Cél: Csak egy adott osztályt akarunk tesztelni a kódban de az
kapcsolatban áll másokkal is..
• Keretrendszerek a tesztek írására és érthetőségének javítására
Lehetőséget ad a függőségeknek a feloldására úgy hogy tetszőleges
környezetet építhetünk a tesztre
Szimulált objektumok, valós szerű viselkedéssel kontrollált módon
 Használjunk interfészeket az üzleti logika rétegben!

50. Core-szerű módszerek

51. Kihívások
• Rengeteg technológia ismerete és azok
integrálása
• Jó alapszerkezet felállítása
• Konvenciók
• Tesztelési struktúra
• Üzemeltetés
• Változékony igények