Új hozzászólás Aktív témák
-
Tigerclaw
nagyúr
Ismerkednék az ASP.NET Core razor pages-el és VS 2019 for mac alatt indítottam egy ilyen új projektet. Futtani szeretném, de egy ilyen üzenet ugrik fel:
Invalid development certificate found:
A valid HTTPS certificate was found but it may not be accessible across security partitions. To fix this, we need to run "dotnet dev-certs https" to ensure it will be accessible during development. This will ask for your password to access the Keychain. Do you agree to running this tool?
Nem találkoztam még olyan alkalmazással, ami a keychainhez kért volna hozzáférést. Enélkül nem tudok tovább lépni. Ezt el kell fogadnom, ez a hivatalos menete ennek?
Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.
-
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 értelmeKifejezetten 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.[ Szerkesztve ]
-
martonx
veterán
válasz joysefke #9103 üzenetére
"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."
He? Hogy mi? Miért? Addig, hogy Asp.Net Core API teljesen értek mindent, de ez a kókányolás ötlet ez minek?
Simán elfut egy Asp.Net Core Api, megcsinálja, amit kell, és ennyi? Mindenki, mindenkitől függetlenül éli a világát.
Szakadjunk már el a görcsös monolitikus megvalósítástól, ez pont az a helyzet, ahol nyugodtan be lehet vezetni egy független microservice asp.net core api-t.Én kérek elnézést!
-
válasz martonx #9104 üzenetére
Mert nem tudom, hogyan/milyen alapon oldjam meg az inter-processz kommunikációt ha a REST-szervíz külön processzbe kerülne. A REST szerviz nem írhatja/olvashatja közvetlenül az adatbázist/adatbázisokat az összes hozzáférésnek mindenképpen keresztül kell mennie a jelenlegi alkalmazás logikán, ez elvárás.
Illetve akárhogy is lenne ez, ehhez mindenképpen hozzá kell nyúlni az apphoz (mivel a legacy interfészt nem használhatom), ezért gondoltam, hogy ennyi erővel akár egyből az applikációba bele lehetne rakni a REST szervízt.
Egyébként nem hiszem, hogy késleltetés/throughput szempontjából a kommunikáció túlságosan kritikus lenne (ha az lenne, akkor már a külső REST interfész is problémás lenne).
Tehát ha útba tudsz igazítani, hogyan oldjam meg minimális invázióval, hogy az applikáció a külön processzben futó REST-szervizzel tudjon kommunikálni, annak örülnék Meg minden ötletnek ami jobb mint a jelenlegi.
[ Szerkesztve ]
-
-
martonx
veterán
válasz joysefke #9105 üzenetére
Én ebbe nem folynék bele, mert azok alapján, amit leírtál két esetet tudok elképzelni:
1. ahol dolgozol, mindenki segg hülye, de azért szeretném hinni, hogy ennyire nem lehet rossz a helyzet
2. valamit végtelenül félreértesz az alatt, hogy a cég mit nevez inter kommunikációnakHa nem félreértés, és tényleg azt erőltetik, ami a leírásod alapján átjött, akkor meg ideje felmondani, és normális fejlesztő céget keresni
Én kérek elnézést!
-
-
G.A.
aktív tag
Üdv!
Egy NumUpDown számlálót (0-255) és egy 8 paraméterrel rendelkező CheckedListBox "értékeit" szeretném szinkronban megjeleníteni. Azaz ha egyiket módosítom, akkor a másik is változzon.
Ehhez Evenet interruptokat használok.
Ha a felhasználó a NumUpDown-t változtatja, akkor annak az Event interruptja megváltoztatja a CheckedListBox "értékeit".
A másiknál vica-versa, de itt már problémás a dolog. Néha megy, néha nem.private void NumUpDown_ValueChanged(object sender, EventArgs e)
{
byte temp = (byte)NumUpDown.Value;
for (int i = 0; i < CheckedListBox.Items.Count; i++)
{
CheckedListBox.SetItemChecked(i,IsBitSet(temp,i));
}
CheckedListBox.Refresh();
}
private void CheckedListBox_SelectedValueChanged(object sender, EventArgs e)
{
byte temp = 0;
for (int i = 0; i < CheckedListBox.Items.Count; i++)
{
if (CheckedListBox.GetItemChecked(i))
{
temp += (byte)Math.Pow(2, (i % 8));
}
}
NumUpDown.Value = (decimal)temp;
NumUpDown.Refresh();
}
A hibát leginkább úgy tudnám jellemezni, hogy akkor jön elő, ha túl gyorsan jelölöm be (vagy ki) a mezőket CheckedListBox-ban. Merre keressem a hibát?
-
G.A.
aktív tag
válasz bandi0000 #9110 üzenetére
Majdnem eltaláltad, csak fordítva.
Ha CheckedListBox_SelectedValueChanged() hívom meg, akkor utána NumUpDown_ValueChanged() is meg lesz hívva. Ez lehet a hiba forrása?
Talán egy if()-el megoldom, hogy akkor ne fusson le, ha a CheckedListBox_SelectedValueChanged() hívta a fv-t. Tesztelem is... -
G.A.
aktív tag
Üdv!
Egy saját class-t szerettem volna létrehozni:
public class Avr_Registers
{
public string Name
{ get; set; }
public byte Value
{ get; set; }
public string[] Bit_Names
{ get; set; }
}
amivel már a teszt foo()-ban gondo akadt:public void AVR_Register_Test()
{
Avr_Registers[] AVR_Regz =
new Avr_Registers[256];
for (UInt64 i = 0; i < 0x08; i++)
{
AVR_Regz[i].Name = "Reg" + i.ToString(); << már itt hibát ir ki
AVR_Regz[i].Value = (byte)i;
for (byte b = 0; b < 8; b++)
{
AVR_Regz[i].Bit_Names[b] = "Bit" + i.ToString() + b.ToString();
}
write_to_uart_screen(AVR_Regz[i].Name + " value = " + AVR_Regz[i].Value.ToString() + "\r\n");
for (byte y = 0; y < 8; y++)
{
write_to_uart_screen(AVR_Regz[i].Bit_Names[y] + "\r\n");
}
}
}
A hiba:
"System.NullReferenceException: 'Az objektumhivatkozás nincs beállítva semmilyen objektumpéldányra.' "
Nem tudok a változóimnak (új) értéket adni.
A legidegtépőbb számomra, hogy akármilyen módon próbálom megoldani nem megy, pedig vagy egy tucat "referencia" kódot találtam a neten, amik leginkább erre a félépítésre hajaznak:
[link]A vicc, hogy van egy másik, egy array-változós class-om, ami meg simán megy, ahogy azt elképzeltem.
-
cattus
őstag
Régen foglalkoztam már C#-pal, de tippre ott lesz a hiba, hogy a
Avr_Registers[] AVR_Regz =new Avr_Registers[256];
sorban csak egy üres tömb jön létre, nem lesznek benne az Avr_Registers objektumok, így annak a propertyjére sem tudsz hivatkozni. Ehhez először inicializálnod kell a tömb elemeit, még mielőtt hivatkozol rájuk:
for (int i = 0; i < AVR_Regz.Length; ++i)
{
AVR_Regz[i] = new Avr_Registers();
}
Ugyanitt tipp, hogy az osztályneveket egyes számban írd.
[ Szerkesztve ]
Do the thing!
-
-
coco2
őstag
Sziasztok!
Oktató anyag után nézelődöm.
Van egy wsdl + xsd, kellene belőle soap szerver + kliens skeleton fordulás és indulásképesen.
Környezet win10 / vs, c#. Gui-hoz nem ragaszkodom, háttérben elinduló web service + előtérben futó console app lenne az ideális.
Van ilyesmire blog / oktató videó lépésről lépésre? Nem a végeredmény a fontos, hanem a project építési folyamat, és hogy megértsem.
Előre is köszönöm.
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
válasz martonx #9118 üzenetére
Wcf kapcsán találtam egy dev console-os wsdl.exe behívást. Az le is fut, és van egy myFile.cs-em a wsdl+xsd-ből. Interface van benne, meg partial class-ok. Arra még nem találtam blogot, hogy abból hogyan lesz működő szerver és kliens skeleton.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
dqdb
nagyúr
Bármi, aminek a támogatása nem igényel akkora bloatware-t sem a kliensen, sem a szerveren, mint a SOAP-é. Ha a legkönnyebb integráció a cél kliensoldalon, akkor JSON vagy sima form data, ha sok a bináris adat, akkor protobuf.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
Keem1
addikt
Bár lehet hogy nem a legjobb stratégia, de én szeretem azokat a technikákat előnyben részesíteni, amik szinte szabvánnyá váltak és a legtöbb helyzetben egyértelműek, elfogadottak. Pl. ezért használok XMLRPC-t. Elég világosan lefektetett szabályai vannak, szinte minden platformon implementálták és mindenhol ugyanúgy használható.
Az lenne a jó, ha ugyanez XML helyett JSON-ban lenne (elvileg van rá törekvés: JSON-RPC). -
martonx
veterán
Egyértelműen ez: https://docs.microsoft.com/en-us/aspnet/core/grpc/?view=aspnetcore-3.1
De ott van még a sima REST API vagy Odata.
Felejtsük már el végre az őskövület szarokat, amikor valami újat fejlesztünk.
GLS-en röhögtem nagyon jót, mikor idén év elején nagy lelkesen bejelentették, hogy végre vadonatúj API-juk van, ami immár WCF alapú
Váááá
Hülye elmaradott parasztok. Mondjuk az előző classic ASP-s API-jukhoz képest ugrottak vagy 15 évet előre, már csak másik 15 évet kellene ugraniukÉn kérek elnézést!
-
dqdb
nagyúr
Szép dolog a szabvány, ha azt nem bonyolítják túl. A SOAP és a köré épülő infrastruktúra azonban túlbonyolított erőteljesen, ha pedig hozzácsapod a WS-Security-t, akkor főleg az lesz nem egyértelműen definiált elemekkel a szabványban. Szép dolog, amikor a Java és a C# világ nem tud beszélgetni egymással egy szabványos felületen keresztül úgy, hogy mindketten támogatják azt, mert adott feature X opcionális lehetősége közül sikerült diszjunkt halmazt implementálni (például bináris adatok hatékonyabb átvitelére a csak MTOM-ot támogató WCF találkozik egy csak SwA-t támogató Oracle alkalmazásszerverrel).
JSON, grpc (protobuf alatt ezt is értettem) eléggé támogatott minden platformon, az utóbbi esetben a túloldal megkapja a .proto fájlokat az interfészleírás részeként, és tud vele szépen dolgozni.
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
martonx
veterán
a gRPC nyelv független szabvány. A google kezdte el, szóval nagyon nincs köze .Net-hez
Az Odata is nyelv független, bár az MS kezdeményezés, nem tudom mennyire terjedt el más nyelveken.
A REST API, meg aztán végképp független bármilyen nyelvtől.A SOAP az úgy lett szabvány, hogy igaziból sose volt interoperábilis a nyelvek között, mert túl bonyolult volt, és ki így valósította meg, ki úgy. Mint a böngészők HTML5-ös szabvány követése 5 évvel ezelőtt. Ha próbáltál már PHP-s SOAP-ot .Net-el kezelni, és fordítva (de említhetném a java-t, vagy bármely nyelvet), akkor tudod miről beszélek
Én kérek elnézést!
-
bandi0000
nagyúr
Rest API-nál mik a konvenciók nagy vonalakban a visszatérési értékeknek?
PL amin most fennakadok, hogy bejelentkezésnél visszatérek egy Ok()-al, és a jwt tokennel
Viszont, ha nem jó a felhasználónév vagy jelszó, akkor BadRequest-tel térjek vissza, vagy egy Ok()-al amibe rakok egy osztályt amibe benne vannak a hibával kapcsolatos dolgok?
Frontenden valami olyasmit akarok válaszban, hogy tudjam, pl hogy a felhasználónév a rossz, vagy a jelszó, illetve regisztrálásnál is jó lenne tudni, hogy létezik e már ilyen felhasználó stb
Xbox One: bandymnc
-
coco2
őstag
válasz martonx #9118 üzenetére
WCF-re rákerestem, és ilyesmit találtam: [link]
Then came .NET Core and the story changed: WCF was not here, or, to be precise, there was no server-side WCF, only client-side, meaning, you could write a WCF proxy to access aSOAP or REST web services, but you could not implement one.
Nekem szerver komponens is kell
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
petyus_
senior tag
válasz bandi0000 #9127 üzenetére
Ha nem jó a user/pass, akkor 401. 400 akkor, ha valami gond van a requesttel (pl nem küldött pass-t, csak usert).
Loginnál jellemzően elég egy string, hogy invalid username or pass. (azért nem invalid username, meg külön invalid pass, hogy így ne lehessen kinyerni a username-eket).
Registernél jó kérdés, hogy mi a jó statuscode már létező userre, [link] itt pl megy a vita, hogy jó-e a 409 (conflict), de fel is sorolja valaki, hogy a FB/Google/stb mit küld. Én 400-at küldenék, mert ugyan nem client hiba, de neki kell változtatnia a requesten ahhoz, hogy jó legyen.
A hibakezelésnek meg nézz utána, core-ban (nem tudom milyen verziót használsz, azt hiszem 2.2-től, de lehet, hogy csak 3.0-tól) van egy ProblemDetails classt, ezt generálja ha validationError van. Ha túljut a validationön (ha csak az a gond, hogy már létezik ilyen felhasználó, akkor túljut), akkor megnézed, hogy van-e ilyen user, ha van, akkor a ModelState-hez adj hozzá hibát, és az mehet vissza, majd a framework csinál belőle problemdetailst (ez egyébként szabány [link] ).
AVagy ha feleslegesen bonyolult neked a problemdetails, akkor csinálj egy saját error-handlert (action filter, vagy middleware), ahol olyan response-t csinálsz, amilyet akarsz, amit egyszerűen tudsz kezelni frontend oldalon.
[ Szerkesztve ]
-
bandi0000
nagyúr
válasz petyus_ #9129 üzenetére
Most lehet félreértelek, de pl ha csinálok több Exceptiont pl LoginException és ha rossz ugye a username vagy jelszó, akkor dobok egy ilyen exceptiont amit elkapok egy [ilyen] middleware-rel, és a hibaüzenetet átalakítom olyanra amit frontenden le tudok kezelni
Most, hogy gondolkozok, úgy emlékszek a szakmai gyakon is Java spring-ben, mindig exceptiont dobtunk, ami át lett alakítva
De most ez a megoldás nem rosszabb, mintha csak csinálnék pl egy osztályt, amibe van egy error és esetleg egy status code tulajdonság amit mindig visszaadok?
Xbox One: bandymnc
-
coco2
őstag
Én értem, hogy utáljuk a soap-ot, de azért had kérjek benne segítséget
Szóval van a wsdl.exe a developer console-on, az gyárt nekem egy server interface-t a wsdl-ből, amit elvileg a wcf serializálásra és deserializálásra használt. Sajnos a net tele van olyan blogokkal, mint ez itt: [link] (a link már "nem él": "MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here"). Jó lenne valami példa kód, ami még nem halott link
Pld van egy stringem (soap boríték), amit szét szeretnék parsingolni osztályváltozókba, illetve osztályváltozókból soap borítékot építenék, és string kimenet kellene további feldolgozáshoz.
Milyen támogatásom van arra?
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
dqdb
nagyúr
válasz bandi0000 #9130 üzenetére
De most ez a megoldás nem rosszabb, mintha csak csinálnék pl egy osztályt, amibe van egy error és esetleg egy status code tulajdonság amit mindig visszaadok?
Ha kizárólag webes felületet nyújtasz, akkor szerintem ez az exception + middleware páros a legjobb.Ha vegyes felvágott a helyzet, mint nálunk, ahol webes és MQ felület is előfordul, akkor más a helyzet. Ezeknél az adott API implementációból az általad kérdezetthez hasonló üzenet jön ki, az API által dobható exceptionök kezelése belül megtörténik:
public class SomeResponse : IResponse
{
public string RequestID { get; set; }
public class OK : SomeResponse
{
public string SomeData { get; set; }
}
public class FailedBecauseOfThis : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
public class FailedBecauseOfThat : SomeResponse, IFault
{
public int Code { get; set; }
public string Message { get; set; }
}
}Proto:
message SomeResponse {
string RequestID = 127;
oneof subtype {
SomeResponseOK OK = 1;
SomeResponseFailedBecauseOfThis FailedBecauseOfThis = 2;
SomeResponseFailedBecauseOfThat FailedBecauseOfThat = 3;
}
}
message SomeResponseOK {
string SomeData = 1;
}
message SomeResponseFailedBecauseOfThis {
int Code = 1;
string Message = 2;
}
message SomeResponseFailedBecauseOfThat {
int Code = 1;
string Message = 2;
}Sikeres válasz:
{
"some_data" : "data"
}Hibás válasz:
{
"code": 123,
"message": "blabla"
}Aztán ha MQ-n keresztül érkező kérésről van szó, akkor a teljes
SomeResponse
leszármazott megy vissza protobuf kódolással, ha webes kérésről van szó, akkor általában* egy réteg a hibákat a példány típusa és/vagy kód alapján megfelelő 4xx/5xx státuszkódokra mappeli és a hibaüzenetet tartalmazó JSON-t ad vissza, ha sikeres volt, akkor simán JSON megy vissza (webes kéréseknél aRequestID
sem kerül bele a válaszba, csak a konvertálást, szerializálást, naplózást befolyásoló attribútumokat az egyszerűség kedvéért lehagytam).* általában, mert volt, hogy a 200 azt jelentette csak, hogy a szerver válaszolt, és ugyanúgy protobuf ment vissza a kliens felé
[ Szerkesztve ]
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
martonx
veterán
Nagyon helyes, hogy régi elavult dolgokat (ami már új korában is szar volt, a fent részletezett okok miatt) nem támogatnak.
Ha szerver komponens is kell, akkor használj .Net Framework-öt.Egyébként már annyiszor mondtam: Miért nem használod a hivatalos dokumentációt??? Van ott WCF tutorial is, direkt nem vagyok hajlandó idelinkelni a kézenfekvőt.
Én kérek elnézést!
-
bandi0000
nagyúr
Használta már valaki ezt a SignalR-t ?
Egy másik projekten belül gondolkozok ezen, igazából Android appot akarok majd, ott van ugye a Firebase Real Time database, ami tök jól használható, viszont külön nem kell írni baíckendet, ezért gondoltam erre, hogy így legalább lehetne mutatni, hogy én csináltam
Xbox One: bandymnc
-
boorit
csendes tag
Sziasztok!
Ha már úgyis feljött a SignalR, nekem olyan kérdésem lenne, hogy egy webapi-nál ezt hogy kell implementálni? Elég sokat kerestem, és nem találtam rá választ, kezdem azt gondolni, hogy amit én akarok, az nem megvalósítható.Tehát van egy webapi-m, ami kiszolgál egy SPA-t. Jelenleg az app indításakor meghívok egy endpointot, ahonnan visszakapom a kért adatokat. Viszont néha egy másik entity változása miatt ezek változhatnak, ilyenkor azt csinálom, hogy megy a POST, és utána megint meghívom a GETet az első endpointra, viszont így pl sokszor olyankor is meghívom, amikor nincs is rá szükgségem (pl az a component jelenleg nem is szerepel az oldalon, de mivel a state kezelés úgy van megoldva, hgoy a post után hívja meg a get-et, ezért minden esetben meghívódik). Ezt szeretném valahogy SignalRrel kiváltani, elkerülve a felesleges callokat.
Nem konkrét implementáció érdekel, csak hogy egy REST APIra, hogy an lehet ezt megoldani.
-
martonx
veterán
Web Api + SPA esetben ugyanúgy, mint bármilyen más esetben. SignalR szól, hogy új adat van, ekkor fogod és lekéred az új adatot.
Vagy ha minimális az adat, akkor eleve a SignalR-el ki is küldetheted, de a SignalR alapvetően nem arról szól, hogy sok száz Kbyte adatot mozgass vele (régebben 32/64Kbyte volt a korlátja, nem tudom ez azóta nőtt-e), hanem hogy signal-okat küldjön a kliensnek.Viszont értelmezve a problémádat, nálad architekturális gondok vannak az SPA-dban amire nem a SignalR lesz a megoldás.
Én kérek elnézést!
-
bandi0000
nagyúr
Megcsináltam az exception elkapást
Úgy működik, hogy dobom az exceptiont, és átalakítja egyedi státusz kódra és üzenetté
Viszont, lehet butaságot kérdezek, de így a böngészőbe a consolon mindig kapok egy HTTP 400 kódot (ezt adom vissza), viszont más weboldalakon nem látok ilyen hibaüzeneteket, azok Http 200-al térnének vissza + error message-el? Vagy én rontok el valamit?
Xbox One: bandymnc
-
sztanozs
veterán
válasz bandi0000 #9139 üzenetére
A HTTP error kódok azért vannak, hogy használd... Ha minden 200-al térne vissza, honnan tudod (illetve tudja az automata), hogy nem azt kapod, amit kéne?
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
-
boorit
csendes tag
válasz martonx #9138 üzenetére
Nem tudom mire gondolsz . Van egy oldal, ahol egy táblázatom, amiben szerepelnek objektumok. Mellette pedig van egy form, amivel újat lehet létrehozni. Létrehozok egy újat, akkor meghívom a GETet, hogy frissüljön a táblázat (erre szeretném használni a signalR-t). Ez szerinted rossz pattern?
Egyébként pedig van egy global gomb az appban, amire kattintva feljön egy dialog, és innen is lehet létrehozni új objektumot, viszont mivel ez bárhonnan elérhető, ezért itt felesleges lehet a GET hívás, ha nem is látszik az adott táblázat. Persze lehetne erre is egy logika, hogy mikor hívja meg a GETet, más megoldást nem jut rá eszembe.
-
bandi0000
nagyúr
Ilyenkor sztem azt szokták csinálni, hogy ahogy létrehozol egy újat, válaszba visszaküldöd a frissített adatokat/táblázatot, és akkor az új adatok szerint frissíted a frontendet
Persze, ha több felhasználó is szerkesztheti, és ugyan azt a táblázatot látják, akkor viszont valszeg SignalR lesz a megoldás, mert akkor muszáj valahogy értesíteni a többi felhasználót is az adatok változásáról
Xbox One: bandymnc
-
boorit
csendes tag
válasz bandi0000 #9145 üzenetére
Hát nem tudom, nekem a post az az éppen létrehozott objektumot adja vissza, put a módosítottat, delete NoContent-et. És ez a lista visszaküldés azért sem működne, mert pl be van állítva egy szűrő a táblázatra, akkor azt akarom, ha mondjuk törlök valamit, akkor a táblázatban a szűrt adatok maradjanak meg, aktuális oldal stb. Ez viszont csak úgy működhetne, hogy a requestben elküldöm a szűrőket is, ami nekem nem tűnik jónak.
Az adatok egy felhasználóhoz kötődnek, tehát ha használnék is SignalR-t, csak egy client lenne, akit értesíteni kell.
[ Szerkesztve ]
-
bandi0000
nagyúr
de a signalR is csak annyit mondana, hogy figyu vàltoztak az adatok, de pl akkor ugyan úgy be kellene húznod a táblàzatba , és hogy megmaradjanak a szűrt adatok, paginált adatok, akkor ugyan csak tudnia kell a szervernek, hogy honnan.adjon hàny adatot
vagy még azt lehet, hogy ahogy elküldöd a postot, vissszajött pl egy success, akkor megint lekérdezed a táblàzat adatait
Xbox One: bandymnc
-
boorit
csendes tag
Oké, ez tényleg működik a lista/táblázat frissítésre (és most, hogy írod, eszembe jutott, hogy ez tervben is volt, csak az elején az egyszerűség miatt csináltam úgy, ahogy most van), viszont a related entity változására még mindig nem jó.
Pl a létrehozott entity kapcsolódik egy másikhoz, legyen child, parent, one to many, és jelzem a parentnél a child-ok countját, ami nem egy static adat a DBben, hanem lekéréskor számolom ki. Ezt még mindig csak úgy tudom megoldani, hogy ha hozzáadok egy childot, akkor lekérem a parentet.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Villanyszerelés
- Futott egy Geekbench kört egy új HTC készülék
- Magga: PLEX: multimédia az egész lakásban
- Xiaomi 11 Lite 5G NE (lisa)
- Stellar Blade
- Tőzsde és gazdaság
- Napelem
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Vezetékes FEJhallgatók
- Xbox tulajok OFF topicja
- További aktív témák...