Recommended
More Related Content
Similar to Szerver oldali fejlesztés korszerű módszerekkel C# nyelven
Similar to Szerver oldali fejlesztés korszerű módszerekkel C# nyelven (20)
Szerver oldali fejlesztés korszerű módszerekkel C# nyelven
- 1. Szerver oldali fejlesztés korszerű módszerekkel C# nyelven Tóth Krisztián Gyula Horváth Gábor
- 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
- 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.
- 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
- 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!
- 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
Editor's Notes
- Csak SOLID an EF Függőségek elfedése Dependecy injection Egyszerűbb szofter esetében felesleges
- Alternatíva: Quartz. Net -> Nincs dahboard
- Alternatíva -> Alap help page-en de ott nem lehet kipróbálni