Háttéralkalmazások/Záróvizsgatételek

← Vissza az előző oldalra – Háttéralkalmazások

1. Adatbázisok

Ismertesse az adatbáziskonkurencia-problémákat!

• dirty read
  • uncommitted tranzakciók által frissített sorok kiolvasása
• non-repeatable read
  • committed tranzakciók által frissített sorok kiolvasása
    • a tranzakció előtt és után kiolvasott értékek nem egyeznek
• phantom read
  • committed tranzakciók által hozzáadott / eltávolított sorok kiolvasása
    • a tranzakció előtt és után kiolvasott értékek nem egyeznek

Ismertesse a tranzakciók alaptulajdonságait!

• ACID:
  • atomicity
    • minden tranzakció egy egység
    • ha egy tranzakció valamely része elhasal, akkor az egész sikertelennek minősül
  • consistency
    • az illegal transactionök nem mennek végbe
    • a kulcsok mindig helyesek
    • a megkötések (NOT NULL, UNIQUE, CASCADE stb.) be vannak tartva
    • a triggerek az előírtaknak megfelelően működnek
  • isolation
    • a párhuzamosan futó tranzakciók az izolációs szintnek megfelelő adatokat olvassanak ki
  • durability
    • a tranzakciók végrehajtása utáni állapot egy rendszerhiba vagy üzemzavar esetén is megmaradjon

Mire szolgálnak a tranzakcióizolációs-szintek?

izolációs szint	dirty read	non-repeatable read	phantom read
read uncommitted	🔴	🔴	🔴
read committed	🟢	🔴	🔴
repeatable read	🟢	🟢	🔴
serializable	🟢	🟢	🟢

Ezeket az SQL-92 (ISO-)szabvány tartalmazta először.

Milyen izolációs szinteket támogat az Microsoft SQL Server?

A fentieket, plusz egy snapshot szintet, ami egy segédadatbázis (tempdb) segítségével számon tartja az egyes sorok verzióit, így a tranzakciók az azok kezdetekor készített pillanatkép alapján végeznek műveletet az adatbázisban. Előnye, hogy lockok nélkül működik. Hátránya, hogy a tempdb-nek magas lehet az erőforrásigénye, illetve egy esetleges írásütközés esetén kivételt dob az RDBMS, amit kezelni kell.

2. Tárolt eljárások

Ismertesse az adatbázisok szerveroldali programozásának koncepcióját, előnyeit, hátrányait!

Használatával eljárásokat (procedures) és függvényeket (functions), illetve triggereket lehet tárolni az adatbázisban. Lényege, hogy az üzleti logika helyett maga az adatbázis-kezelő szerver futtatja a beállított szubrutinokat, az előbbi csak meghívja őket.

A szerveroldali programozás jellemzői

szempont / tulajdonság	➕	➖
teljesítmény	gyorsabb lokális feldolgozás a gyorsítótárnak is köszönhetően hálózat: kisebb késleltetés, alacsonyabb terhelés	legtöbb esetben értelmezett nyelvek nagyobb terhelés az adatbázison nem lehet igazán jól skálázni
szabvány		nincs (ISO-)szabvány platformfüggőek az implementációk sőt, általában egy külön nyelvet is meg kell tanulni hozzá így nehezebben karbantartható a kód
adatbiztonság	jobb megfelelés az ACID-elveknek nem kell a hálózaton utaztatni az adatokat
az üzleti logika bárhonnan meghívhatja a szubrutinokat	növeli a kód újrafelhasználhatóságát könnyebb karbantartás	nincs scope-juk, így nehezebb korlátozni, ki hívhatja meg őket jogosultságkezeléssel meg lehet oldani

Milyen programozási lehetőségei, sajátosságai vannak a Microsoft SQL Servernek?

A Microsoft SQL Server procedurális programozási nyelve a T(ransact)-SQL. Azokban változókat, operátorokat, elágazásokat, utasításblokkokat, ciklusokat és kivételeket is lehet használni.

Egyedi adatbetöltési eszköze a kurzor. Gyakorlatilag úgy működik, mintha lenne egy Excel-táblázatunk, amit egy olyan Maccel szeretnénk kiolvasni, amihez csak egy ▼ billentyű van csatlakoztatva. Meg kell nyitni a táblázatot, utána egyesével végig lehet léptetni az adatokon. Az utolsó sort elérve be kell zárni az ablakot (= a kurzort), majd magát a programot is, hogy felszabadítsuk az erőforrásokat (DEALLOCATE cursor1).

A függvények skalár értékekkel (változókkal) vagy táblákkal térhetnek vissza.

A triggerek DML- és DDL-utasításokat is végrehajthatnak.

szubrutinok jellemzői T–SQL-ben

típus	van visszatérési értéke?	van mellékhatása?
eljárás	🟠 lehet	🟠 lehet
függvény	🟢 igen, mindig	🔴 nem, soha

3. ORM

Mi az O/R leképzés feladata, mire szolgálnak a shadow-információk?

Az ORM segítségével egy objektumorientált nyelv memóriájában tárolt objektumokat le lehet képezni egy relációs adatbázis sémájára (és fordítva). Ezzel hidat képez az adatbázis és az üzleti logika között, biztosítva utóbbi adatperzisztenciáját.

A shadow-információk az adatbázisban szükséges, de az üzleti logika által nem használt kulcsokat, időbélyegeket és egyéb adatokat takarják.

Egymásnak megfeleltethető adattípusok

üzleti logika	adatbázis
osztály	tábla
tagváltozó (primitive)	oszlop (attribútum)
tagváltozó (objektum)	oszlop (attribútum), mely egyben idegen kulcs is
osztálypéldány	sor (rekord)

Az öröklési hierarchiát miképp lehet leképezni relációs sémára?

Tegyük fel, hogy van egy absztrakt Vehicle osztályunk. Ebből származik a Tram és a Bus osztály. Be akarunk vezetni egy új ElectricBus osztályt, mely a Bus leszármazottja.

Egy táblába, gányul

vehicle

🔑 id	lpn_or_car_number	is_tram	has_radio_point_switcher	is_bus	rear_engined
1	V1448	true	false	false	<null>
2	SGY811	false	<null>	true	true

↓

vehicle

🔑 id	lpn_or_car_number	is_tram	has_radio_point_switcher	is_bus	rear_engined	is_electric_bus	traction_battery_capacity_kwh
1	V1448	true	false	false	<null>	false	<null>
2	SGY811	false	<null>	true	true	false	<null>
3	NLE848	false	<null>	false	true	true	170

Külön táblába a valós osztályokat

tram

🔑 id	lpn_or_car_number	has_radio_point_switcher
1	V1448	false

bus

🔑 id	lpn_or_car_number	rear_engined
1	SGY811	true

➕

electric_bus

🔑 id	lpn_or_car_number	rear_engined	traction_battery_capacity_kwh
1	NLE848	true	170

Külön táblába az összes osztályt

vehicle

🔑 id	lpn_or_car_number
1	V1448
2	SGY811
3	NLE848

tram

🔑 id	🔑 🇸🇨 vehicle_id	has_radio_point_switcher
1	1	false

bus

🔑 id	🔑 🇸🇨 vehicle_id	rear_engined
1	2	true
2	3	true

➕

electric_bus

🔑 id	🔑 🇸🇨 bus_id	traction_battery_capacity_kwh
1	2	170

Absztrakt struktúrába

Külön tábla az osztályoknak, örökléseknek, tagváltozóknak, azok típusainak és az értékeknek. Mindegyiknek van kapcsolata legalább egy másik táblával.

Hogyan képezzük le az objektumok közötti kapcsolatokat?

Csak a kapcsolatok számosságát lehet leképezni, azok irányát nem. A kapcsolatok akár azonos táblán belül is lehetnek (rekurzió).

kapcsolatszámossági mátrix

	egy	több
egy	idegen kulccsal az egyik táblában
több	–	egy külön kapcsolótáblával

Hogyan képezhetőek le a globális változók?

Gányul

Változónként külön táblában:

vat_hungary

🔑 id	vat
1	0,27

transaction_fee_hungary

🔑 id	bank_transaction_tax
1	0,0045

Vagy akár ezeket osztályonként / teljesen összevonva.

Szépen

Kulcs-érték páronként:

globals

🔑 id	class	key	value
1	Hungary	vat	0,27
2	Hungary	bank_transaction_tax	0,0045

4. EF

Mi az Entity Framework?

Az Entity Framework egy Microsoft által fejlesztett, ADO.NET-re és .NET Frameworkre épülő ORM-keretrendszer. A 2016-ban kiadott, .NET Core-alapon újraírt, nyílt forráskódú verzió neve Entity Framework Core. A Java nyelvbeli megfelelője a Jakarta Persistence.

Teljesen moduláris, az egyes részeit NuGet-csomagokból lehet importálni. A JDBC-hez hasonlóan drivereket biztosít az egyes RDBMS-ekhez. Az ORM mellett a LINQ-eket futásidőben SQL-kódra fordítja le és hajtja végre.

Mikor használjuk, és mikor nem?

Mikor nem használjuk

• legacy kódban, ami közvetlenül használja az ADO.NET-et, és nyers SQL-parancsok szerepelnek benne, amiket nem éri meg migrálni EF-be
• teljesítménykritikus környezetekben, ahol
  • nem megengedhető az ORM overheadje
  • nem bízható rá az SQL-parancsok generálása az EF-re (pl. költségoptimalizálás miatt)
• tömeges műveleteknél

Mikor használjuk

Avagy mik az előnyei:

• ORM
• LINQ
• kódból történő migrációk (sémafrissítés)
• lazy loading
• párhuzamosság és konkurenciakezelés
• előre lefordított és cache-elt lekérdezések

Mi a DbContext?

Egy EF Core-beli osztály, mely egy adatbázis-munkamenetet reprezentál.

Általában a DAL-ban hozunk létre egy DbContext-ből leszármazó osztályt. Mivel a DbContext vezeti a nyilvántartást az entitáspéldányokról, azok felderítésében segíti, ha DbSet<Entity> tagváltozókat is megadunk a DAL-osztályban. Egy DbContextOptions objektum átadásával – mely tartalmazza az adatbázis típusát és connection stringjét – lehet példányosítani.

A service layernek DI-vel adjuk át a DbContext-et, és annak tagfüggvényeit meghívva lehet LINQ-ket futtatni.

Milyen három modellezési lehetőségünk van adatmodell készítésére?

	példa	előnyei
automatikus	public class Book { public int Id { get; set; } public string Title { get; set; } public string Isbn { get; set; } }	nem szükséges további konfiguráció a konvenciók alkalmazása kiváltja a további kód írását
annotációk	public class Book { public int Id { get; set; } public string Title { get; set; } [Unicode(false)] [MaxLength(22)] public string Isbn { get; set; } }	automatikus típusmegfeleltetés egyszerű, ismert szintaxis
Fluent API	protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Book>() .Property(b => b.Isbn) .IsUnicode(false); }	kapcsolatok meghatározása nézetek és egyedi eljárások támogatása ősfeltöltés támogatása adatbázisspecifikus beállítások

Milyen két lehetőségünk van a modell konfigurációjára?

Code first

	lépés	ki / mi készíti?
1.	OO-modell	a fejlesztő C#-ban
2.	ORM
3.	DB-objektumok	EF Core Migration Tool

Database first

	lépés	ki / mi készíti?
1.	DB-objektumok	a fejlesztő SQL-ben
2.	ORM	EF Core Reverse Engineering Tool
3.	OO-modell

Hogy néz ki egy entitás, hogyan készítünk kapcsolatokat közöttük?

Összehasonlítás

	1:N	N:N
annotációkkal	Entitások: public class Blog { [Key] public int Id { get; set; } public string Title { get; set; } = null!; public List<Post> Posts { get; set; } = new(); } public class Post { [Key] public int Id { get; set; } public string Content { get; set; } = null!; [ForeignKey(nameof(Blog))] public int BlogId { get; set; } public Blog Blog { get; set; } = null!; // parent navigation }	Entitások: public class Student { [Key] public int Id { get; set; } public string Name { get; set; } = null!; public List<Enrollment> Enrollments { get; set; } = new(); } public class Course { [Key] public int Id { get; set; } public string Title { get; set; } = null!; public List<Enrollment> Enrollments { get; set; } = new(); } public class Enrollment { [ForeignKey(nameof(Student))] public int StudentId { get; set; } public Student Student { get; set; } = null!; [ForeignKey(nameof(Course))] public int CourseId { get; set; } public Course Course { get; set; } = null!; public DateTime EnrolledOn { get; set; } }
Fluent API-val	Entitások: public class Blog { public int Id { get; set; } public string Title { get; set; } public List<Post> Posts { get; set; } = new(); } public class Post { public int Id { get; set; } public string Content { get; set; } public int BlogId { get; set; } // foreign key public Blog Blog { get; set; } = null!; // parent navigation } DbContext: protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .HasMany(b => b.Posts) .WithOne(p => p.Blog) .HasForeignKey(p => p.BlogId); }	Entitások: public class Student { public int Id { get; set; } public string Name { get; set; } public List<Course> Courses { get; set; } = new(); } public class Course { public int Id { get; set; } public string Title { get; set; } public List<Student> Students { get; set; } = new(); } DbContext: protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Student>() .HasMany(s => s.Courses) .WithMany(c => c.Students) .UsingEntity("StudentCourse"); } A kapcsolótáblát az EF automatikusan létrehozza.

Hogyan készítünk lekérdezéseket, hogyan módosítunk adatokat EF Core-ban?

A Dogs entitás példáját véve:

lekérdezések

típus	dbContext-függvényhívás
összes találat	.Any(d => !d.Ownerships.Any())
számlálás	.Any(…).Count()
projekció	.Select(d => d.Name)
csoportos projekció és spread	.SelectMany(d => d.Ownerships)
szelekció	.Where(d => d.Name == "Bodri") vagy ID alapján: .Find(dogId)
egyetlen találat	.Single(d => d.Name == "Bodri") vagy .SingleOrDefault(…)
első találat	.First(d => d.Name == "Bodri") vagy .FirstOrDefault(…)
csoportosítás	.GroupBy(d => d.Ownerships.Count())
rendezés	.OrderBy(d => d.Ownerships.Count()) .ThenBy(d => d.BirthDate)
lapozás	.Skip(20) és .Take(10);

módosítások

CRUD	dbContext-függvényhívás
create	.Dogs.Add(newDog);
read	ld. az előző táblázatot
update	.Dogs.Find(dogId); dog.BirthDate = birthDate;
delete	adatbetöltéssel: .Dogs.Find(dogId); .Dogs.Remove(dog); adatbetöltés nélkül: az előző táblázatból bármit meghívni az első találat sorig, majd utána .ExecuteDelete();

...majd utána dbContext.SaveChanges();.

5. JPA – általános

Ismertesd a Java Persistence API architektúráját és főbb jellemzőit!

A JPA egy Java ORM-interfészspecifikáció, melyet az Eclipse Foundation tart karban. 2020 óta már Jakarta Persistence a neve.

Egyik implementációja a Hibernate, .NET-es megfelelője pedig a .NET Persistence API.

Architektúra

┌──────────────────────────┐
│ 1. osztályok (entitások) │  ← annotációkkal ellátva
└──────────────────────────┘
           ↓
┌─────────────────────────────┐
│ 2. perzisztenciabeállítások │  ← a persistence.xml-ben vagy a kódban
└─────────────────────────────┘
           ↓
┌─────────────────────────┐
│ 3. EntityManagerFactory │  ← elindítja a JPA providert
└─────────────────────────┘
           ↓
┌──────────────────┐
│ 4. EntityManager │  ← futásidőben kezeli a perzisztenciakontextust (tranzakciókat, gyorsítótárat stb.)
└──────────────────┘
           ↓
┌───────────────────┐
│ 5. adatbázisréteg │  
│   - JDBC API      │  
│   - JDBC driver   │  
│   - RDBMS         │
└───────────────────┘

Az elsőt "csak" használja a JPA, a 2–4. elemek pedig a szerves részei.

Milyen annotációkat kell alkalmazni egy JPA-entitás megírásakor?

• @Entity
• @Id

Szükség esetén:

• @GeneratedValue az @Id-hoz

• @Table(name=…), illetve @Column(name=…)
• @Embeddable és @Embedded
• @Convert(converter=…)

Milyen típusú attribútumokat vehetünk fel benne?

• primitívek és TitleCase wrappereik
• szövegek
  • String
  • char[] és Character[]
• számok
  • BigInteger és BigDecimal
• idő
  • Calendar, Date, Time, Timestamp stb.
    • java.util.* esetén kötelező használni a @Temporal(DATE/TIME/TIMESTAMP)-et
    • egyéb esetben ajánlott
• Enum
  • @Enumerated(ORDINAL/STRING) szükséges
• nyers adatok
  • byte[] és Byte[]
  • nagyobb adatok esetén @Lob szükséges, hogy BLOB-ként tárolja őket

Ismertesd a perzisztenciakontextus fogalmát!

A perzisztenciakontextus a perzisztenciaszolgáltató által kezelt, memóriabeli entitások egy része. Hozzáférést biztosít az adatbázishoz az üzleti logikában. A JPA-ban az EntityManager, az EF Core-ban pedig a DbContext végzi ezt a feladatot.

Egy perzisztenciakontextus belül egy objektum csak egyetlen példányban létezhet.

Mutasd be az entitások életciklusát!

Állapotok

		a DB-ben
		nem létezik	létezik
a memóriában (perzisztenciakontextusban)	nem létezik	–	lecsatolt
	létezik	új	menedzselt vagy törölt

Állapotátmenetek

                          │                                    
                          │                                    
                    new() │                                    
                          │                                    
                          ▼                                    
                  ┌──────────────┐                             
                  │              │                             
                  │      új      │                             
                  │              │                             
                  └──────────────┘                             
                          │                                    
                          │                                    
                persist() │ merge()                            
                          │                                    
                          ▼                                    
                  ┌───────────────┐remove()     ┌──────────────┐
            ┌────►│               │────────────►│              │
  refresh() │     │   menedzselt  │             │    törölt    │
            └─────│               │◄────────────│              │
                  └───────────────┘    persist()└──────────────┘
                       │    ▲                                  
           megszűnik a │    │                                  
perzisztenciakontextus │    │                                  
                       │    │ merge()                          
                       ▼    │                                  
                  ┌──────────────┐                             
                  │              │                             
                  │   lecsatolt  │                           
                  │              │                             
                  └──────────────┘

6. JPA – használat

Milyen módokon lehet lekérdezést megfogalmazni a JPA-ban?

Összehasonlítás

komplexitás	módszer	példa
egyszerű	elsődleges kulcs alapján	Person p = entityManager.find(Person.class, 42L);
feltételekkel	Criteria API	CriteriaBuilder cb = entityManager.getCriteriaBuilder(); CriteriaQuery<Person> cq = cb.createQuery(Person.class); Root<Person> root = cq.from(Person.class); cq.select(root) .where(cb.equal(root.get("name"), "David")); Person p = entityManager.createQuery(cq).getSingleResult();
	Query by Example	Person probe = new Person(); ExampleMatcher matcher = ExampleMatcher .matching() .withMatcher("firstName", match -> match.regex().ignoreCase()); probe.setFirstName("^Dav.*"); Example<Person> example = Example.of(probe, matcher); List<Person> results = repo.findAll(example);
nyersen (el is lehet nevezni őket)	JPQL	TypedQuery<Person> q = entityManager.createQuery( "SELECT p FROM Person p WHERE p.age > :age", Person.class ); q.setParameter("age", 30); List<Person> list = q.getResultList();
	SQL	List<Object[]> rows = entityManager.createNativeQuery( "SELECT first_name, last_name FROM person WHERE age > :min" ) .setParameter("min", 30) .getResultList(); for (Object[] row : rows) { String firstName = (String) row[0]; String lastName = (String) row[1]; }

Hogyan bővíti a lehetőségeket a Spring Data JPA a lekérdezések megfogalmazásának területén?

jellemző	példakód	miben segít?
repositoryk használata	interface BusRepository extends JpaRepository<Bus, Long> { }	az implementációt a Spring generálja kevesebb boilerplate kód
konvenciók használata	List<Bus> findByLpn(String lpn);
rendezés és lapozás támogatása	interface BusRepository extends PagingAndSortingRepository<Bus, Long> { Iterable<Bus> findAll(Sort sort); Page<Bus> findAll(Pageable pageable); }
egyedi lekérdezés	@Query("SELECT DISTINCT b FROM Bus b WHERE b.lpn LIKE :lpn")	hosszú metódusnevek helyett kézzel meg lehet írni, és a kívánt nevet lehet adni a metódusnak

Hogyan valósíthatók meg entitások közti kapcsolatok és az entitások öröklése JPA-ban?

Kapcsolatok

Példa annotációkra

típus	egyirányú	kétirányú
@OneToOne	@Entity class A { @OneToOne @JoinColumn(name="b_id") B b; } @Entity class B { @Id Long id; }	@Entity class A { @OneToOne @JoinColumn(name="b_id") B b; } @Entity class B { @OneToOne(mappedBy="b") A a; }
@OneToMany és @ManyToOne	@Entity class A { @OneToMany(cascade=CascadeType.ALL) @JoinColumn(name="a_id") List<B> bs; } @Entity class B { @Id Long id; }	@Entity class A { @OneToMany( mappedBy="a", cascade=CascadeType.ALL, orphanRemoval=true ) List<B> bs; } @Entity class B { @ManyToOne @JoinColumn(name="a_id") A a; }
@ManyToMany	@Entity class A { @ManyToMany @JoinTable( name="A_B", joinColumns= @JoinColumn(name="a_id"), inverseJoinColumns= @JoinColumn(name="b_id") ) Set<B> bs; } @Entity class B { @Id Long id; }	@Entity class A { @ManyToMany @JoinTable( name="A_B", joinColumns= @JoinColumn(name="a_id"), inverseJoinColumns= @JoinColumn(name="b_id") ) Set<B> bs; } @Entity class B { @ManyToMany(mappedBy="bs") Set<A> as; }

Öröklés

típusai

módszer	@Inheritance(strategy = …)
egy táblába, gányul	SINGLE_TABLE
külön táblába a valós osztályokat	TABLE_PER_CLASS
külön táblába az összes osztályt	JOINED
absztrakt struktúrába	–

• @Id attribútuma csak a legfelső ősnek lehet
• absztrakt is lehet egy entitás
  • de természetesen nem lehet példányosítani
• nem-entitásból is származhat entitás
  • ha szükségünk van az örökölt attribútumokra, akkor @MappedSuperClass annotációt kell tenni az ősre
• entitásból is származhat nem-entitás
  • de nem "veszi kezelésbe" a JPA

7. Spring

Mik a függőséginjektálás főbb előnyei?

• az injektornak ki van szervezve a függőség betöltése és az objektumgráfok előállítása
  • kevesebb kódduplikáció
• könnyű mockolni a függőségeket

Hogyan támogatja a Spring?

A következő annotációkkal:

Opciók (a legrosszabbtól a legjobbig)

lehet injektálni	példa
mezőbe	@Service public class UserService { @Autowired private UserRepository userRepository; public void getAllUsers() { userRepository.findAll(); } }
setterbe	@Service public class UserService { private UserRepository userRepository; public void setUserRepository(UserRepository userRepository) { this.userRepository = userRepository; } public void getAllUsers() { userRepository.findAll(); } }
konstruktorba	@Service public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public void getAllUsers() { userRepository.findAll(); } }

Más beaneket is lehet injektálni, melyeket kollaborátoroknak hívják. Több lehetséges jelölt esetén konfigurálni kell, hogy melyiket szeretnénk injektálni.

Milyen élettartama lehet egy springes beannek?

Scope-ok (a leghosszabbtól a legrövidebb életűig)

típus	annotáció	minek az életciklusához van kötve
singleton	– (ez az alapértelmezett)	semminek, csak egy van belőle az egész alkalmazásban
application	@Scope("application")	ServletContext
prototype	@Scope("prototype")	új példány jön létre minden getBean() (@Autowired) hívásra
websocket	@Scope(scopeName="websocket", proxyMode=...)	WebSocket session
session	@Scope("session")	HTTP session
request	@Scope("request")	HTTP-kérés

Hogyan támogatja a tranzakciókezelést a Spring?

Egységes API-ja van, ami mögé ezeket a tranzakciókezelőket lehet berakni:

Tranzakciókezelők (az alacsonyabb szinttől a magasabbig)

típus	jellemzői
JDBC	–
EntityTransaction (JPA)	ld.: Ismertesd a Java Persistence API architektúráját és főbb jellemzőit!
JDO (Java Data Objects)	a JTA elődje
JTA (Jakarta Transactions)	szolgáltatásokon átívelő tranzakciókat lehet végrehajtani

Tranzakciókezelés módjai (a kevésbé népszerűtől a népszerűbbig)

típus	hogyan indítjuk / zárjuk le a tranzakciókat?	példa
programozott	a kódban	@Service public class OrderService { private final PlatformTransactionManager transactionManager; public OrderService(PlatformTransactionManager transactionManager) { this.transactionManager = transactionManager; } public void processOrder() { TransactionStatus transactionStatus = transactionManager .getTransaction(new DefaultTransactionDefinition()); try { validateOrder(); chargeCustomer(); saveOrderToDatabase(); transactionManager.commit(transactionStatus); System.out.println("Transaction committed successfully!"); } catch (RuntimeException ex) { transactionManager.rollback(transactionStatus); System.out.println( "Transaction was rolled back due to the following error: " + ex.getMessage() ); } } }
deklaratív	metódusannotációkkal	@Service public class OrderService { @Transactional public void processOrder() { validateOrder(); chargeCustomer(); saveOrderToDatabase(); // kezeletlen kivétel esetén a Spring automatikusan rollbackel } }

A @Transactional paraméterei

paraméter	értéke
(no)rollbackFor(ClassName)	milyen kivételek esetén legyen rollback
timeout	az időkorlát másodpercben
isolation	izolációs szint (a JPA nem támogatja)
value	a tranzakciókezelő azonosítója (több adatbázis esetén fontos)
propagation	kompatibilitás egy tranzakcionális metódusból hívott másik tranzakcionális metódussal

A propagation értékei (a megengedőbbtől a szigorúbbig)

érték	mit tesz a jelenlegi függvény...		mi történik a következő függvénnyel?
	...ha van aktív tranzakció?	...ha nincs aktív tranzakció?	...ha van aktív tranzakció?	...ha nincs aktív tranzakció?
REQUIRED (alapértelmezett)	azt folytatja	újat hoz létre	a jelenlegit folytatja	–
NESTED	folytatódik, és egy SAVEPOINT-ot hoz létre	újat hoz létre	a jelenlegit folytatja – rollback esetén csak a SAVEPOINT-ig áll vissza	–
REQUIRES_NEW	felfüggeszti	újat hoz létre	új tranzakciót használ	–
SUPPORTS	azt folytatja	tranzakció nélkül fut	azt folytatja	tranzakció nélkül fut
MANDATORY	azt folytatja	kivételt dob	azt folytatja	–
NOT_SUPPORTED	felfüggeszti	–	–	tranzakció nélkül fut
NEVER	kivételt dob	tranzakció nélkül fut	–	tranzakció nélkül fut

8. ASP.NET Core

Ez a szakasz átnézésre, esetleg javításra szorul. Segíts a szerkesztésében!

Ha nem tudod, hogyan állj neki, olvasd el az útmutatót!

Mi az ASP.NET Core?

Az ASP.NET Core egy .NET-alapú nagyteljesítményű, nyílt forráskódú, platformfüggetlen webalkalmazás‑framework.

Mit jelent, hogy egy alkalmazás monolitikus?

Monolitikusnak nevezzük azt az alkalmazást, amelynek összes komponense – pl. UI, üzleti logika és adatkezelés – egyetlen deploy‑egységben (pl. egy futtatható vagy szerveralkalmazásban) fut, nem részeire bontva.

Mi a clean architecture?

A clean architecture egy szoftvertervezési minta, melynek alapvetése a kód rétegekre (pl. domain, application, infrastructure, presentation) bontása. Alkalmazza a dependency inversiont is: a külső rétegek függnek csak az absztrakcióktól, nem fordítva.

Sorolj fel min. 3 általános, ASP.NET Core által nyújtott infrastruktúrafunkciót!

• beépített DI
• middleware alapú HTTP–pipeline-kezelés (pl. autentikáció, logging)
• konfigurálhatóság (appsettings.json + környezeti változók)
• moduláris hosting (pl. Kestrel), cross‑platform deployment (IIS, Nginx, Docker stb.)

Hogyan indul el egy ASP.NET Core projekt?

1. dotnet new webapi vagy dotnet new mvc parancs
2. a Program.cs és/vagy Startup.cs definiálja a hosztot, regisztrálja a service‑eket és a middleware‑eket
3. a dotnet run indítja el a Kestrel szervert
4. elérhető az alkalmazás

Milyen lépései vannak, hogy egy Web API-n kiajánljunk egy EF Core által nyújtott adatmodellt (lekérdezésre, módosításra)?

1. projekt generálása (dotnet new webapi)
2. EF Core-csomagok telepítése (Microsoft.EntityFrameworkCore, SQL server provider)
3. DbContext osztály és entitásmodellek létrehozása
4. AddDbContext<...>(...) DI a Program.cs-ben / Startup.cs-ben
5. kontroller létrehozása (ApiController), mely injektálja a DbContext‑et
6. lekérdező metódusok írása: GET, POST, PUT, DELETE endpointok
7. használat: context.Entities.ToList(), Find(id), Add(), Update(), Remove(), majd SaveChanges()

9. Razor

Ez a szakasz átnézésre, esetleg javításra szorul. Segíts a szerkesztésében!

Ha nem tudod, hogyan állj neki, olvasd el az útmutatót!

Milyen módokon szeparálhatjuk a kliens–szerver alkalmazásrétegeket?

• tiszta szerveroldali renderelés – minden HTML generálását a szerver végzi (pl. ASP.NET MVC, Razor Pages).
• tiszta kliensoldali alkalmazás (SPA) – az UI a böngészőben fut, a szerveren csak API-szolgáltatás van (pl. Angular, React).
• hibrid megközelítés – a kezdeti renderelés szerveren történik, utána a kliens veszi át az irányítást (Pl. Blazor Server, SSR + CSR kombinációk)

Mi a szerveroldali renderelés?

A szerver generálja az egész HTML-t a kérésre, és küldi el a kliensnek. Így a böngésző azonnal meg tudja jeleníteni a teljes oldalt.

Milyen előnyei/hátrányai vannak a kliensoldalival szemben?

Előnyök

• gyorsabb első betöltés – kész HTML érkezik
• jobb SEO-támogatás

Hátrányok

• magasabb szerverterhelés, minden kérésnél újrarenderelés
• lassabb interaktivitás és navigáció a teljes oldalletöltések miatt

Mi a Razor?

A Razor egy HTML-templating szintaxis C# (vagy VB) integrálásával; 2010 óta része az ASP.NET MVC-nek / ASP.NET Core‑nak. .cshtml / .razor fájlokban használatos.

Hogyan készül el egy HTML-oldal Razor segítségével és MVC vagy Razor Pages használatával?

MVC

1. létre kell hozni egy Controller metódust return View(model);-lel
2. a ViewName.cshtml fájlban Razor-kód (@model, @foreach stb.) generálja a HTML-t

Razor Pages

1. létre kell hozni egy .cshtml fájlpárt (Index.cshtml + Index.cshtml.cs), ahol:
   1. a *.cshtml.cs tartalmazza az oldal logikáját az OnGet() és OnPost() metódusokkal
   2. a *.cshtml Razor-jelölésekkel hivatkozik a @Model objektumra

10. Microservices

Milyen előnyökkel és hátrányokkal jár a mikroszolgáltatás architektúra a monolitikussal szemben?

Előnyök

Előnye, hogy az alkalmazás modulárissá válik. Ebből következik a...

• kisebb kódbázis
  • gyorsabb
    • tesztek
    • build
    • IDE
  • könnyebb teszteket írni
  • könnyebb bekapcsolódni a munkába
  • kisebb csapat tud rajta dolgozni
    • kevesebb koordináció szükséges
• külön kezelhető szolgáltatások
  • többféle technológia használható
  • robosztusabb
    • terheléselosztás
    • SPOF kiküszöbölése
    • automatikus újraindítás
  • jobb skálázhatóság
    • elég a bottleneck(ek)et felskálázni
      • gyorsabb indulás
    • alacsonyabb terhelés esetén leskálázni is lehet
  • rugalmasabb frissítések
    • könnyebb a rollback is
  • részekre bontott költségek
    • üzemeltetésnél
    • frissítéseknél
      • könnyebben eladható a megrendelő számára
        • akár egy szolgáltatás teljes újraírása is

Hátrányok

A modularitásnak természetesen vannak hátrányai is. Ezek a következőek:

• komplexebb architektúra, melynek tervezéséhez és üzemeltetéséhez nagyobb szaktudás (pl. utóbbihoz egy képzett DevOpsos) kell
  • több (teszt)példány
    • több tesztszerver
  • azok között több kapcsolat
    • a hálózati (szolgáltatások közti) kommunikáció továbbra is kötött
  • többféle szerveren is futhatnak
  • többféle technológiát is használhatnak
  • bonyolultabb a verziókezelés
    • nehezebb a kompatibilitás
  • nehezebb a CI/CD
    • bonyolultabb a deploy
• több hálózati kommunikáció
  • point of faliure
  • overhead
• nehezebben megvalósítható atomicitás
• kódduplikáció

Ezekre (részben vagy egészben) megoldást ad...

• egy jól elkészített CI/CD
• egy hálózatkiesésre felkészített szolgáltatás
• a fejlesztőcsapatok közti jó kommunikáció
• közös könyvtárak készítése
  • amely megint korlátozza a szolgáltatásokban használható nyelveket

Ismertesd az alábbi microservice tervezési minták céljait, azok előnyeit, hátrányait!

Összehasonlítás

tervezési minta	leírása	előnyei	hátrányai
shared database	több szolgáltatás egy sémát használ	nem kell több adatbázis szabadon lehet joinolni egy megkezdett tranzakciót folytathat egy másik szolgáltatás az ACID az adatbázis által biztosított	ellentétes a microservices alapelveivel egyféle RDBMS használható bottleneck függőséget teremt a szolgáltatások közt ha egy szolgáltatásnak szüksége van indexre, akkor a többi teljesítményét is rontja egyeztetni kell a sémamódosításokról
database per service	mindegyik szolgáltatás külön privát táblát / külön sémát / külön adatbázist használ	külön adatbázisok esetén nincs SPOF akár többféle RDBMS is használható	külön adatbázisok esetén nehezebb és drágább az üzemeltetés nehezebb joinolni nehezebb tranzakciókat átadni másik szolgáltatásnak e kettő általában hibás tervezés jele de meg lehet oldani az alábbi két minta valamelyikével
database per service + API composition	a külön privát táblák / külön sémák / külön adatbázisok adatait egy új szolgáltatás joinolja	lehet joinolni	a memóriakorlát miatt továbbra sem lehet szabadon joinolni
database per service + command query responsibility segregation	a külön privát táblák / külön sémák / külön adatbázisok adatait egy külön szolgáltatás módosítja, és azokat egy read-only view adatbázisban is összegyűjtjük (a master–slave replicationhöz hasonlóan)	szabadon lehet joinolni a gyakori lekérdezésre lehet optimalizálni a view adatbázis sémáját, ami akár a joinolást is kiküszöbölheti	ez a legbonyolultabb esetleges kódduplikáció a view adatbázist valahogy szinkronizálni kell a fő adatbázissal késleltetés vagy inkonzisztencia is felléphet

11. Microservices

Ismertesd az alábbi microservice tervezési minták céljait, azok előnyeit, hátrányait!

összehasonlítás

tervezési minta	leírása	előnyei	hátrányai
API gateway	az egyes szolgáltatások közvetlen elérése helyett egy átjárót hívjanak meg a kliensek	egy IP-címet kell ismerni protokollváltást is biztosíthat	még egy szolgáltatás szükség van service discoveryre és circuit breakerre még egy hálózati ugrás

Ismertesd a tanult service discovery mintákat!

összehasonlítás

típus		minta	leírása	előnyei	hátrányai
a nyilvántartás	vezetése	self registration (push)	minden szolgáltatás maga felelős a regisztrációért és annak törléséért	a szolgáltatás mindig ismeri a saját állapotát	minden szolgáltatásnál implementálni kell váratlan leállás esetén nem törli a regisztrációt
		3rd party registration	külön komponens felelős a regisztrációért és annak törléséért	nem kell implementálni mindegyik szolgáltatásnál elég egy health check endpoint	külön szolgáltatás szükséges ami ráadásul soha nem állhat le
	használata	client-side service discovery	pl. ilyen a round-robin DNS	egyből meghívja a kliens az adott szolgáltatást	a nyilvántartást továbbra is kell használnia aminek implementálni kell az elérését meg kell valósítani a terheléselosztást is
		server-side service discovery	egy router biztosítja a terheléselosztást	nem szükséges további kliensoldali implementáció felhőszolgáltatások is biztosítanak ilyet	külön szolgáltatás szükséges ami ráadásul soha nem állhat le még egy hálózati ugrás a routernek akár több protokollt is kell támogatnia

12. Cloud

A számítási felhő fő jellemzői

• önkiszolgálás bármikor
• nagy rugalmasság
  • skálázhatóság
    • akár egy komplex vállalati rendszer is kialakítható
  • számlázás fogyasztás alapján
• felhasználók közt megosztott erőforrások
• széleskörű hálózati elérés
  • internet
  • IoT

A számítási felhő fizikai, térbeli kiépítése

Fizikai

• nagy, légkondicionált raktárépületek
• bennük általában már "csak" előreszerelt konténerekkel

Térbeli

A nagyobbtól a kisebbig:

• region
• availability zone
  • redundancia
• data center

Főbb publikus felhőszolgáltatók

• AWS
• Microsoft Azure
• Google Cloud
• OVH (EU)

Felhős szolgáltatásmodellek

• infrastructure as a service
• platform as a service
• software as a service

Üzemeltetési modellek (a más által kezelttől a saját kezelésűig)

típus	jellemzői	példa
nyilvános	más által üzemeltetett szabadon elérhető	ld.: Főbb publikus felhőszolgáltatók
hibrid	nyilvános szolgáltatás saját környezetben	Azure Stack Hub, AWS Outposts
közösségi	egy csoport tagjai közt megosztott, zárt infrastruktúra	EESZT
saját	saját szolgáltatás saját környezetben	–

Szolgáltatásgaranciák (SLA)

• magas uptime
• redundancia
  • áramellátás
  • hálózat
  • hardver
    • tárhely
  • földrajzi
    • természeti katasztrófák

Skálázási lehetőségek

• vertikális
  • erőforrások növelése
• horizontális
  • példányok bővítése
• automatikusan is lehet

Példák elérhető szolgáltatásokra

• AWS
  • S3
  • SQS
  • EC2
• Google
  • Pub/Sub

A felhős modell előnyei, hátrányai

Összehasonlítás

előny	hátrány
költséghatékony	drágább is lehet
használatalapú árazás	bonyolult árazás
könnyen skálázható	nem végtelenül skálázható
SLA	a nagyon magas SLA-kért többet kell fizetni
menedzselt üzemeltetés és biztonság (DRP)	nem férünk hozzá fizikailag a szerverekhez
globális	helyi adatvédelmi megfelelőség esetleges hiánya
sokféle szolgáltatás	vendor lock-in (breaking changes)

13. Azure

Ez a szakasz átnézésre, esetleg javításra szorul. Segíts a szerkesztésében!

Ha nem tudod, hogyan állj neki, olvasd el az útmutatót!

Azure alapszolgáltatások viszonya egymáshoz

Előfizetés

Azure-szolgáltatások igénybevételének elszámolási és hozzáférési egysége; egy Azure-fiók alatt több előfizetés is lehet, és az éves költési korlátok is erre épülnek.

AD

Identitás- és jogosultságkezelés központja, amelyhez előfizetések, felhasználók és szolgáltatások (alkalmazásregisztrációk) kapcsolódnak.

Fiók (account)

Microsoft-fiók vagy szervezeti (Azure AD) fiók, amellyel be lehet jelentkezni és kapcsolatba lehet hozni az Azure-előfizetéseket.

Erőforráscsoport

Logikai gyűjtőkonténer az előfizetésen belül, amelybe kapcsolódó erőforrásokat, pl. VM-eket vagy adatbázisokat csoportosítunk; segíti az RBAC-t és a költségkövetést.

Erőforrás

Valós szolgáltatásobjektum (pl. virtuális gép, tárhely, SQL-adatbázis), amely egy előfizetésen belül erőforráscsoportban jön létre.

Erőforrások beállítható alapjellemzői

• név – globálisan vagy az előfizetésen belül egyedi azonosító
• régió – földrajzi hely (pl. eastus, westeurope)
• típus és SKU – szolgáltatás rétegének és teljesítményének kiválasztása (pl. basic, standard)
• címkék – kulcs–érték párok a költség- és szervezési szempontú csoportosításhoz

Régió kiválasztásának szempontjai

• késleltetés
• szabályozás és megfelelőség
  • egyes adattípusokra helyhez kötött tárolási előírások vonatkozhatnak
• elérhetőség
  • nem minden régió támogat minden szolgáltatást.
• költségek
  • régiónként eltérő árszintek lehetnek.

Azure SQL és Azure App Service szolgáltatások...

...bemutatása.

• Azure SQL Database: teljesen menedzselt relációsadatbázis-szolgáltatás automatikus mentéssel, patcheléssel, méretezéssel és beépített teljesítményoptimalizálással.
• Azure App Service: PaaS típusú app hosting szolgáltatás .NET, Java, Node.js, Python stb. számára. Könnyen skálázható és CI/CD-támogatott.

...felépítése (logikai) erőforrások szintjén.

• Azure SQL: logikai SQL-szerver → adatbázis(ok) (→ Elastic Pool)
• Azure App Service: App Service Plan (compute és scale) → Web App → deployment slots, konfigurációk stb.

...árazási tényezői.

• Azure SQL: vCore- vagy DTU-alapú teljesítmény, adattárolás mérete, elérhetőség (zóna-redundancia), licencek (Azure Hybrid Benefit)
• App Service: service plan típusa (free, shared, basic, standard, premium, isolated), példányszám, skálázás típusa (manual, autoscale), operációs rendszer (Windows / Linux)