„Háttéralkalmazások/Záróvizsgatételek” változatai közötti eltérés

A VIK Wikiből
← Régebbi szerkesztésÚjabb szerkesztés →
VizuálisWikiszöveges
→7. Spring: Tétel kidolgozása
→12. Cloud: Tétel kidolgozása
1 516. sor: 1 516. sor:


=== A számítási felhő fő jellemzői ===
=== 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 ===
=== 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 ===
=== Főbb publikus felhőszolgáltatók ===
...
 
* AWS
* Microsoft Azure
* Google Cloud
* OVH (EU)


=== Felhős szolgáltatásmodellek ===
=== Felhős szolgáltatásmodellek ===
...
 
* infrastructure as a service
* platform as a service
* software as a service
 
{| class="wikitable"
|+Ü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.: ''[[Háttéralkalmazások/Záróvizsgatételek#Főbb publikus felhőszolgáltatók|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) ===
=== 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 ===
=== 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 ===
=== Példák elérhető szolgáltatásokra ===
...
 
* AWS
** S3
** SQS
** EC2
* Google
** Pub/Sub


=== A felhős modell előnyei, hátrányai ===
=== A felhős modell előnyei, hátrányai ===
...
{| class="wikitable"
|+Ö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 ==
== 13. Azure ==

A lap 2025. július 1., 00:21-kori változata


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[1] é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.[2]

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 – detached
létezik new managed vagy removed

Á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[3] 
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[4]
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 könnyíti meg a JPA használatát a Spring Data JPA?

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

Mi az ASP.NET Core?

...

Mit jelent, hogy egy alkalmazás monolitikus?

...

Mi a clean architecture?

...

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

...

Hogyan indul el egy ASP.NET Core projekt?

...

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)?

...

9. Razor

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

...

Mi a szerveroldali renderelés?

...

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

...

Mi a Razor?

...

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

...

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

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

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
  • [5]

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

Azure alapszolgáltatások viszonya egymáshoz

Előfizetés

...

...

Fiók (account)

...

Erőforráscsoport

...

Erőforrás

...

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

...

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

...

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

...bemutatása.

...

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

...

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

...

  1. ↑ Kivéve: https://learn.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/native-compilation-of-tables-and-stored-procedures és https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdev/running-Java-stored-procedures.html
  2. ↑ https://blogs.oracle.com/javamagazine/post/transition-from-java-ee-to-jakarta-ee
  3. ↑ Nem tananyag, de Tanár Úr jelezte, hogy a Java 2. házit ennek segítségével lehet megoldani legszebben.
  4. ↑ Webalkalmazásoknál használatos.
  5. ↑ Külső eszközökkel történő kommunikáció esetén természetesen autentikáció is szükséges.
A lap eredeti címe: „https://vik.wiki/index.php?title=Háttéralkalmazások/Záróvizsgatételek&oldid=206651”