Új hozzászólás Aktív témák

• #9103 joysefke veterán

  Új Válasz 2020-03-07 14:02:07 #9103

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  joysefke

  veterán

  Sziasztok, szeretnék inputokat gyűjteni meg hátha segít ha leírom a gondolataimat.

  Van egy nagy alkalmazás amelynek a fejlesztésébe (elsőként) belecsöppentem, további szerencsések majd csatlakoznak. Az én feladatom viszonylag beláthatónak tűnik: RESTful Api-t kell írni az alkalmazás által managelt objektumok lekérdezéséhez és módosításához. A távlati terv az, hogy ezzel a Rest-Apival kiváltsák a meglévő legacy interfészt amit a kliensek használnak.

  A megvalósítandó REST-interfész Swagger szinten már kb definiálva van, nekem "csak megvalósítani" kell, vagy legalább érdemben elindulni az úton és kompetencia benyomását kelteni. A megvalósításhoz én minél kulcsrakészebb technológiát akarok használni, ahol minél több HTTP/REST/Auth dologhoz van gyári támogatás. Szóval ASP Core API projekt lebeg a szemem előtt. A fő kérdés az, hogy ezt hogyan fogom a jelenlegi monstrumba beleintegrálni anélkül, hogy közben újra fel kéne találnom a csillagrombolót vagy esetleg a kőbaltámmal tönkretenném az említett csillagromboló belső huzalozását miközben hozzápatkolok egy oldalkocsit.

  Az alkalmazás kifejezetten sokat látott már és bonyolult, Microsoft technológiák és irányzatok állatkertje, a világon keresztülmigrált fejlesztéssel. Az alkalmazott technológiák többségéhez nem értek. Az alkalmazás számomra lényegi része .Net 4.7.2-n van jelenleg.
  Az alkalmazás által nyilvántartott entitások adatmezőinek egy része csatlakoztatott MS-AD-ból származik, másik része pedig az alkalmazás saját SQL-szerveréből, amely kiegészíti az AD-ban tárolt adatmezőket (az AD-s sémát kiegészíti az SQL-ben tárolt séma). A kettőnek mindig együtt van értelme

  Kifejezetten nem cél és nem kívánatos, hogy a fejlesztendő REST szerviz közvetlenül a jelenlegi, alkalmazáslogikát megkerülve, hozzáférjen az adattárhoz (AD + SQL szerver) és onnan próbáljon meg adatokat visszaadni vagy oda írni.

  A meglévő legacy interfész (amit ki akarnak váltani) használata, illetve hogy annak a funkcionalitását egy REST interfész mögé rejtsem nem kívánatos, hiszen így bebetonoznám a legacy interfészt (továbbra is karban kéne tartani).

  Ha eltekintünk ettől a legacy interfésztől, akkor én úgy gondolom (nincs megerősítve, de erős a gyanúm), hogy nincsen az alkalmazásban másik interfész amihez a REST-szervízt külön processzként futtatva hálózaton (vagy localhoston) keresztül tudnék csatlakozni a Rest-szervíz leendő belső interfészével és onnan le tudnám kérdezni az adattárat. Tehát úgy gondolom, hogy mindenképpen hozzá kell nyúlnom az alkalmazáshoz és az alkalmazással azonos processzen belül -de külön threaden- kell fusson a REST-szervíz.

  A leendő architektúrára a jelenlegi legjobb működőképesnek gondolt ötlet a következő:

  Az alkalmazás két példányban fog futni:
  -(1) Az első példány a jelenlegi REST nélküli verzió lesz aminek a legacy interfészére csatlakoznak a legacy kliensek. Ehhez nekem nem lenne közöm.
  (2)A második példány az applikáció REST-szervizzel kiegészített változata lenne, ehhez a változathoz nem fognak csatlakozni legacy kliensek és a legacy interfésze nem lesz aktív használatban. Ez a második példány ugyanahhoz az AD-hez és ugyanahhoz a logikai SQL szerverhez fog csatlakozni mint az első példány.

  Egymással párhuzamosan írják/olvassák az adatbázisokat.
  Ez már jelenleg is működik és nálam hozzáértőbb emberek úgy gondolják, hogy nem fognak összeakadni az egyes alkalmazáspéldányok (már ma is van HA konfiguráció közös replikált SQL adatbázissal és közös AD-vel).

  Ezt a második, REST-tel kiegészített példányt kellene most összehozni.

  Az ötletem az, hogy a REST API egy ASP .NET Core 3.1 projekt lenne amelyhez tartozó ASP WebHost objektumot az applikációból (annak a belépési pontját megkeresve) egy külön Thread-en indítanám el, az pedig a megadott porton fogadná a kéréseket.

  A REST-szervíz belső fele pedig az appnak azokat a (megtalálandó) .NET -es objektumait használná mint kliens ahová jelenleg a legacy interfész is csatlakozik. Hogy ez mennyire jól behatárolható azt még nem tudom. Gondolom ezekhez az objektumokhoz írni kéne majd valami wrappert ami ezeket mint ASP-kontrollerbe injektálható szervízt fogja átadni.

  Valami észrevétel?
  Előre is köszi!
  J.

Új hozzászólás Aktív témák