- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- VoidXs: Tényleg minden játék optimalizálatlan?
- hcl: MS Office365 Linuxon
- gban: Ingyen kellene, de tegnapra
- Mr Dini: Mindent a StreamSharkról!
- erkxt: A Roidmi becsődölt – és senki nem szól egy szót sem?
- Hieronymus: Három júniusi képem
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
leslie23 #9798 üzenetére
Manapság, amikor a gépeknek van minimum 8GB ramja, szerintem semmi se akadályoz meg abban, hogy ramban tárold, amit csak tudsz. Mi lehet a legrosszabb, ami történik? A winforms appod memória használata felmegy 1-2GB-ig? Na ügy
Az első kérdésedre elég egyértelmű, hogy mi történik. Ha nincs a connection stringben a timeout beállítva, akkor a default azt hiszem 30s.
Azt írod, hogy ezek egyenként 5-15 másodpercesek. Igen ám, de nem nehéz belátni, hogy ha ilyen queryből futtatsz 15-öt párhuzamosan, akkor szegény DB szervernek sem 5-15 másodpercébe fog kerülni egyet-egyet végrehajtani, hanem ki tudja mennyivel többe (SQL szerver erőforrásaitól függ). Ergo simán elérheti a 30 másodpercet is 1-1 lekérdezés ideje, és voilá, máris kapod a hiba üzenetet. Legalábbis szerintem ez történik, és ezért is javul meg, amikor connection stringben belefoglalod a korlátlan timeout időt. Vagy egyszerűen csak megölöd a DB-t, és timeout időn belül még új connectiont létrehozni sem sikerül felé.
Biztos, hogy valami ilyesmi lesz a problémád forrása. -
leslie23
tag
Sziasztok!
Segítséget, vagy magyarázatot szeretnék kérni tőletek a következő probléma kapcsán, StackOverflow relevánsnak tűnő kérdéseit már átnyálaztam, de nem találtam számomra választ. Van egy WinForms alkalmazás, amivel SQL queryket szeretnék végrehajtani (kb. 70-80 darabot, egyenként 5-15 másodperc az execution time) a lekérdezések eredményeit pedig Excel-állományokba menteni. Nem parallel async végrehajtás működik, viszont kicsit tempósítandó a dolgokat átírtam Parallel.Foreach segítségével, a szimultán szálakat 15 darabban maximalizálom. Az SqlConnection using blokkban van, ennek ellenére az alábbi hibaüzenetet kapom: "The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached."
Ha a connection stringbe belefoglalom a Connection Timeout = 0 paramétert, akkor megintcsak lefut szépen a cucc. Próbáltam szintén a connection stringben állítani a Max Pool Size-et de nem volt hatása. Sajnos nem értem, hogy pontosan mi történik, ha jól értem a using végén a kapcsolat zárásra kerül és bekerül a connection poolba. Viszont ezután miért történik timeout, mikor a következő szálon ismét szükség lenne a connectionre?
Illetve ha Timeout van, miért nem tud új kapcsolatot létrehozni?
Köszönöm, ha valaki rá tud világítani mi itt a kulcs.
És egyből egy másik kérdésem is lenne; a Excelt az Interop liben keresztül kezelem. Neten azt találtam, hogy maga a COM Interop nem thread safe, feltételezem ez az oka annak, hogy parallel futásnál időnként COM error, application busy üzenetet kapok (5 futásból egyszer). Alternatív megoldásként felmerült, hogy a parallel végrehajtásnál csak egy DataSetben tárolnám a lekérdezések eredményeit, majd ezt követően egy külön műveletben sorosan generálnám le az Excel-riportokat. A kérdésem, hogy mennyire célszerű nagy mennyiségű adatot (pl. 80 query, egyenként 30-40 mező és 10-12 ezer rekord) memóriában tárolni míg elér a folyamat az Exceles lépésig?Vagy mi lehet itt best practice szerintetek?
-
kingabo
őstag
válasz
joysefke #9791 üzenetére
Én régebben olvastam 7"-os ebook olvasón, megnövelt betűmérettel még bkv-n is jól olvasható volt. Ha pdf-et olvasol akkor olyan progit keress ami újra tudja tördelni a szöveget, ha megnöveled a betűméretet (vagy sokat kell scrollozni), de inkább vmi ebook formátummal jársz a legjobban
PS: egy 2012-es nexus 7-en tudtam kipróbálni, szerintem kevés hozzá méretben -
leslie23
tag
Csak most jutottam gép közelébe, köszönöm szépen mindhármótoknak, kipróbáltam a SoapUI-t és a Fiddlert is, remekül működik mindkettő!
-
dqdb
nagyúr
válasz
leslie23 #9792 üzenetére
A Fiddlerrel ha jól értem nekem kellene felépítenem a request XML-t.
Rosszul, ahogyan martonx is írta, a Fiddler csak egy proxy, amin keresztül bonyolítva a forgalmat lehet monitorozni a kéréseket és válaszokat. Opció lehet még a message logging és tracing bekapcsolása. -
leslie23
tag
Köszönöm, sikerült végre! Próbáltam már az asmx-et célozni, de 404-et kaptam, mint kiderült a https miatt...
Http-vel működik pöpecül, köszönöm a segítséget mindkettőtöknek!Arra viszont nem találtam példát/leírást, hogy a web reference-es kódból hogy tudnám kinyerni az XML-eket, erre tudsz linkelni esetleg valamit? A Fiddlerrel ha jól értem nekem kellene felépítenem a request XML-t.
-
joysefke
veterán
Kicsit off.
Szeretném megkérdezni, hogy ki használ tabletet Pluralsight videók nézésére, illetve szakmai könyvek olvasására?
Szeretném tudni, hogy mi a minimum méret, felbontás, ahol már olvashatóak a ps videón a betűk illetve a könyvek. -
dqdb
nagyúr
-
leslie23
tag
válasz
martonx #9788 üzenetére
Köszi, pont erre gondolok, csak nem tudom összehozni...
Egyszerűség kedvéért a GetInfo endpointot górcső alá véve, így néz ki a kód web reference használatával:MNBWebservice.MNBArfolyamServiceSoapClient Client = new MNBWebservice.MNBArfolyamServiceSoapClient();
MNBWebservice.GetInfoRequestBody b = new MNBWebservice.GetInfoRequestBody();
MNBWebservice.GetInfoRequest r = new MNBWebservice.GetInfoRequest(b);
MNBWebservice.GetInfoResponseBody re = Client.GetInfo(b);
és ennek kiváltását így próbálom összehozni:
string soapXML =
"<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:web=\"http://www.mnb.hu/webservices/\">" +
"<soapenv:Header/>" +
"<soapenv:Body>" +
"<web:GetInfoRequest/>" +
"</soapenv:Body>" +
"</soapenv:Envelope>";
using (WebClient client = new WebClient())
{
client.Encoding = Encoding.UTF8;
string uploadString = client.UploadString("http://www.mnb.hu/webservices/MNBArfolyamServiceSoap/", soapXML);
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(uploadString);
}
Bizonyára triviális a dolog, de nem értem hogy pontosan melyik URI-t kellene céloznom...
Az endpointot? Az ASMX-et? Mindenre 404-et kapok...
-
leslie23
tag
Sziasztok,
elég noob kérdés, de nem találok rá egyértelmű választ. Van az MNB-nek egy jó öreg ASMX/WSDL árfolyamok webservice-e, amit mint web reference behivatkozva szépen le lehet tömegesen lekérni árfolyamokat.
Így néz ki a folyamat most nálam: példányosítom aGetExchangeRatesRequestBody
osztályt, beállítom az objektumcurrencyNames
,startDate
,endDate
tualjdonságainak értékét.MNBArfolyamServiceSoapClient
objektumGetExchangeRates
metódusának az imént létrehozottGetExchangeRatesRequestBody
objektumot megadva mint argumentum, egyGetExchangeRatesResponseBody
objektumot kapok vissza, aminek aGetExchangeRatesResult
metódusa adja meg a response XML-t, benne az árfolyamokkal.Nekem technikai okok miatt arra lenne szükségem, hogy ezt a műveletet web reference nélkül tudjam megoldani, a kérdés, hogy ez vajon lehetséges-e? Valami olyasmire gondolok, hogy egyszerűen felépítem a request XML-t (LINQ to XML), majd egy hívás után (gondolom a GetExchangeRates endpoint lesz a kulcs) megkapom a response XML-t. Tud ilyet az ASMX?
Előre is köszönöm a segítséget!
-
joysefke
veterán
válasz
ReSeTer #9783 üzenetére
Erre azt írják, hogy rekurzívan (mélyen) klónoz:
OpenXmlElement.Clone Method (DocumentFormat.OpenXml) | Microsoft Docs -
ReSeTer
senior tag
Helló!
Próbálgatom az openxml-t használni word dokumentum készítéséhez.
Nem találok sehol se információt, hogy hogyan lehetne egy egész oldalt másolni a következő oldalra.Amit eddig találtam: Elemeket egyenként klónozni, majd pagebreak-et az oldal végére rakni, új paragraph referenciával, és ehhez illesztem be a klónozott elemet.
Probléma, hogy ez így nagyon sok kód. Egyrészt van vagy 5 fajta elem, ismétlődik is szabálytalanul. Nincs valami olyan method ami két referencia közötti tartalmat egyben tudja klónozni?
Ha már referencia, nem lehet megjelölni a dokumentum bizonyos pontjait? Mert most tudnék rakni egy paragraphot oda ahova megakarom jelölni, de szerintem úgy kihagyja a fejlécet például.
Valami ötlet, merre induljak el?
-
Alexios
veterán
Én ezt az örököltetést nem erőltetném a helyedben, mert egyrész semmi szükség rá
Másrészt az öröklés IS-A kapcsolatot felételez, márpedig már nyelvtanilag is látszik hogy a dark IS A light nem állja meg a helyét
De ott agyalok, hogy a ColorScheme osztályt egyelőre nem tudom implementálni, mert nem tudom neki megmondani hogy az light és dark is lehet igazából.
Én itt megmondom őszintén nem teljesen értem mire gondolsz, de én a joysefke által felvetett úton mennék tovább -
Keem1
veterán
válasz
joysefke #9780 üzenetére
Jó irányban gondolkodsz
Én is már túl egy sörön, szóval.."anélkül, hogy tudnám, hogy milyen frameworkben"
.NET 5.0Találtam a neten egy ötletadó samplet:
public void ChangeTheme(ColorScheme scheme, Control.ControlCollection container)
{
foreach (Control component in container)
{
if (component is Panel)
{
ChangeTheme(scheme, component.Controls);
component.BackColor = scheme.PanelBG;
component.ForeColor = scheme.PanelFG;
}
else if (component is Button)
{
component.BackColor = scheme.ButtonBG;
component.ForeColor = scheme.ButtonFG;
}
else if (component is TextBox)
{
component.BackColor = scheme.TextBoxBG;
component.ForeColor = scheme.TextBoxFG;
}
...
}
}
Ami pont jól jönne ahhoz, amit csinálok: a Windows 10 light/dark módjának implementálására.
Ahogy ezt a kódot néztem, igazából elég lenne egyszer a light színeket felvinni, aztán abból örököltetni a darkot (hisz a light a default), és nem hasalna el a motyó akkor se, ha közben bekerülne a light-ba egy új szín, de még a darkba nem (hisz akkor csak az eredeti maradna).De ott agyalok, hogy a ColorScheme osztályt egyelőre nem tudom implementálni, mert nem tudom neki megmondani hogy az light és dark is lehet igazából.
Aztán arra gondoltam, hogy legyen egy static class, de az meg azért nem jó, mert az nem lehet metódus paramétere.
Ez a ColorScheme egy olyan osztály lehet, amiben benne van a dark és a light is, és ezeknek csak propertyjei vannak.Lehet innom kéne még egy sört és ezen csak holnap agyalni.
-
joysefke
veterán
Van egy basic classem, kb 10 környéki color propertyvel, nevezzük ezt Light-nak.
A "basic class" megnevezés base class helyett elég rendesen zavarja a megértést.
Öröklődés helyett miért nem definiálsz valami "color profile"-okat leíró egyszerű osztályt, pld "ColorProfile", annak lehetne 1-2 static readonly beégetett értéke, pld ColorProfile.Light, ColorProfile.Dark, de nyilván lehetőség lehet akár custom példány létrehozására is (pld egy ColorProfile.Default-ból) ha van erre igény.
Annak eldöntését hogy éppen milyen ColorProfile van érvényben azt egy másik osztály (-nak példánya) végezhetné ami kérésre előrántja konfigurációból vagy akárhonnan.
Mondom ezt egy sör után, illetve anélkül, hogy tudnám, hogy milyen frameworkben mit csinálsz, illetve UI-ban nem vagyok otthon
Öröklődést akkor van értelme használni amikor egy osztály viselkedését akarod módosítani/definiálni és nem akkor amikor egy egyszerű property értékét le akarod cserélni.
-
Alexios
veterán
Hát, lehet érdemes lenne megnézni a c# és oop alapokat, mert ez kb a legalapabb öröklődés
Példa:
using System;
public class Program
{
public static void Main()
{
var dark = new Dark();
Console.WriteLine(dark.Magenta);
Console.WriteLine(dark.Green);
}
}
public class Light
{
public virtual string Magenta{get;} = "LightMagenta";
public virtual string Green {get;} = "LightGreen";
}
public class Dark : Light
{
public override string Magenta {get;} = "DarkMagenta";
}
Ha a kérdés az, hogy ezek statikus propertyk lennének, akkor statikus propertyket nem lehet virtualnak vagy abstractnak megjelölni, szóval felülírni sem lehet őket
-
Keem1
veterán
Srácok, elakadtam, segítséget kérek.
Van egy basic classem, kb 10 környéki color propertyvel, nevezzük ezt Light-nak.
Van még egy, ennek neve legyen Dark, ami a Lighttól öröklődik.Amit szeretnék:
- egyrészt a Light-tól bizonyos propertyket overrideolni, tehát mondjuk aColor Magenta { get; } = ColorTranslator.FromHtml("#FF333337");
lesz, és ha a Dark.Magenta kerül meghivatkozásra, akkor innentől az ő propertyje lesz érvényes.
- másrészt, ha a Dark-ban egy property nem létezik, de a Light-ban igen (pl. Green), akkor aDark.Green
is érvényes lesz, csak megegyezik majd aLight.Green
színnel (mindaddig, míg a Dark-ban is nem kerül overrideolásra a Green).Már az elsőnél elakadtam
-
Cégnél hogy szokott kinézni az új kollégák kiképzése? Helyben történik, vagy elküldik a kollégát tanfolyamra?
Milyen oktatási anyagokat használnak? pl. ha infó tanárról váltana valaki programozói állásra. -
martonx
veterán
válasz
joysefke #9774 üzenetére
"Kérdése alapján már a táblákban kódolva van a struktúra (ki-kinek gyermeke) ezt kéne dekódolni és meghatározni, hogy a gráf csúcsai hogyan nézzenek ki kódba öntve, illetve hogyan tárolják a köztük lévő relációkat."
Igen, ez elég egyértelmű volt
És erre küldtem a minimalista példa kódot, mert szemlátomást emberünk csak és kizárólag fix dimenziós tömbökben tud gondolkozni, ti meg rögtön gráf-os legbonylultabb esetek lekezeléséhez alkalmas módszerekkel kezdtétek bombázni, miközben jó eséllyel olyan bonyolultságú a gráfja, mint egy meghajtón lévő mappákban lévő file-ok szerkezete. Aminek leképezéséhez semmi spéci nem kell, csak az én példa classom.
Persze ez is csak feltételezés, mivel nem sok konkrétumot tudtunk meg. -
joysefke
veterán
válasz
martonx #9772 üzenetére
Kérdése alapján már a táblákban kódolva van a struktúra (ki-kinek gyermeke) ezt kéne dekódolni és meghatározni, hogy a gráf csúcsai hogyan nézzenek ki kódba öntve, illetve hogyan tárolják a köztük lévő relációkat.
A kérdés nekem arra utal, hogy nem tudja, hogy a "normál" tömbökön túl van még dinamikusan bővíthető tömb, több dimentiós tömb illetve más ravaszabb struktúrák. Tapogatózik, hogy hogyan lehetne sok relációt flexibilisen tárolni, felépíteni.
Sokimm
Én azzal kezdeném, hogy
-(1)
körbenéznék, hogy milyen az általad használt UI-keretrendszerben támogatott gráf-megjelenító komponens van és melyiket szeretnéd viszont látni.-(2)
Megnézném, hogy annak mi a publikus interfésze, milyen formában várja a gráfot. Valószínűleg előírja a csúcsok és esetleg élek osztály-formátumát. Neked ehhez kell alkalmazkodni, ebben a struktúrában kell felépítened az adatbázis alapján a gráfot. Feltéve, ha nem akarsz saját UI- komponenst gyárani-(3)
Megnézném, hogy az adatbázis által kódolt gráf-csúcs szomszédossági információt hogyan tudom dekódolni és ebből előállítani azt a runtime-struktúrát ami a UI-komponensnek kell.Minnél közelebb van az adatbázis által kódolt struktúra ahhoz ahogyan a UI komponens várja annál inkább jobb pozícióban vagy. Minnél távolabb, annál rosszabb.
-(4)
Lehet hogy kell egy C# és/vagy gráfalgoritmus gyorstalpaló. Kérdésed alapján csak az egydimenziós tömböket ismered. Jó lesz ha képbe kerülsz a List<>, Queue<>, Stack<>, Dictionary<,>, HashSet<>, LinkedList<> típusokkal C# oldalon, ha csinálni is kell valamit a gráfokkal. Ugyanez vonatkozik a gráfalgoritmusokra. Feljebb volt is egy olvasós link #9770. -
Alexios
veterán
Rég volt már algoritmusok és adatstruktúrák órám, de ahogy mondja quailstorm is, egy fa struktúra alapvetően egy irányított gráf, szóval abban érdemes gondolkodni.
Kész megoldás helyett/mellett ajánlom hogy olvass utána az adjacency matrix/adjacency list struktúráknak, mert gráfok leírására van kitalálva, és bármely programnyelvben tudod implementálni.
Itt egy példa rá c#-ban: [link] -
martonx
veterán
Abszolút rosszul állsz hozzá. Ezt bármilyen nyelven meg lehet csinálni, csak nem úgy ahogy te próbálod.
Felejtsd el az array-t. Csinálsz egy objektumot, amiben van egy lista.public class MyGraph
{
public string Name;
public List<MyGraph> Children
}És ebbe végig fel tudod építeni az egész gráfot,
-
Sokimm
senior tag
válasz
quailstorm #9770 üzenetére
Ez szuper, thx!
-
quailstorm
félisten
Ide egy gráf adatstruktúra kell.
Szerencsére megvan a lehetőséged, hogy kész függvénykönyvtárat használj:
[link] [link] [link]
Ha szeretnéd a hátterét kicsit elolvasni.Az össze vissza elnevezett változóid meg teljes tévút és felejtsd el. Objektumokban kéne gondolkozni és a relációk adattagként tárolásában.
-
Sokimm
senior tag
válasz
Alexios #9768 üzenetére
Bár mindenkinek szól a válasz, de neked lett címezve, sry
Egy dinamikus tartalmú SQL táblából táplálkozik, és grafikusan meg kell jeleníteni egy fa struktúrát, aminek a szintjei és a szinten található elemeinek darabszáma nem konstans.
Erre a táblán belül hivatkozások vannak, ki kinek a gyermeke, de nem tudunk egyéb infót.
Ciklusok futtatásával darabszámot előre definiálni lehetne, ha strukturált lenne a fa, de van ahol a 4. mélységben ágazik 100 felé, van ahol egy szakaszon a 2. szint szépen növekszik arányosan. Erre kellene egy dinamikus tárhely, amit előre nem foglalok le (vagy nem is deklarálom), mert lehet ma 4 array-ből megúszom, lehet holnap 30 lesz, vagy több.
Ha a két dimenziós tömbbel gondolkodom, akkor az első cím információtombom[x][9]=7;
nem tükrözi azt, amit az adott fa leszármaztató ID lehetne, amikor én adok neki "nevet".int[] arrayname4 = new int [];
Így még kell egy kapcsolótábla is, hogy melyik array melyik fő x címei alatt mit is kell "érteni".arrayname4 == tombom[1][...]
arrayname34 == tombom[2][...]
Szándékosan ugrottam 30-at, mert nem biztos, hogy a köztes elemek fa elágazások. Azok "példányok" is lehetnének, tovább nem osztódnak.A dictionary-s megoldásnak utána nézek thx! (nagyon dinamikus a méret, a sorrend, bár nem én fogom változtatni c#-ból a tartalmat, én csak "használom" az információkat)
A végén a monitoron szeretném látni.
Viccet félretéve, ha van egy arrayname34-es elágazásom, ami alá csak "begyűjtöm" az adott array alá tartozó elemeket, akkor meghívni / kiolvasni, csoportban kezelni (grafikus tábla struktúra) el tudom képzelni, de így most minden "ős" alá kell egy ciklust írnom, hogy fussa végig kik tartoznak alá. Ez így elég erőforrásigényes.Ha c# ban nem lehet, akkor még érdekelne, hogy melyik nyelv képes futás időben deklarálni változót, ennyi az érv.
js-ben lehet? Utána nézek thx!
-
Alexios
veterán
De hol szeretnéd a végén látni? Azt leszámítva hogy a változóneveknek fordítási időben már ismertnek kell lennie is ott lenne a probléma, hogy c#-ban nem fognak csak úgy globális változók létrejönni, szóval ami a cikluson belül jön létre, az utána már azon kívül nem lesz elérhető.
Ha c#-ban nem lehet ezt megcsinálni, akkor miért szeretnéd más nyelven, főleg ha a fentebb említett megoldások sem jók, hanem kell az hogy legyenek ilyen változónevek, mi a cél?Technikailag amúgy javascriptben pl. megoldható, csak felmerül a kérdés, hogy miért akarnál ilyet csinálni?
-
vlevi
nagyúr
Kétdimenziós tömb lesz az, amit te keresel. Vagy, pontosabban, egy olyan tömb, aminek az elemei int[] tömbök.
attól még nem lesz 3 külön változód, de külön tudsz majd rá hivatkozni, a sorszámukkal.tombom[0][9]=7;
Ez a legelső array-nek a 9. elemébe beleírja a 7-et.Ha jól írtam le, mert most telefonról nem tudom ellenőrizni.
-
Sokimm
senior tag
Sziasztok!
Hogyan lehet for ciklssal array-t deklarálni?
Itt a példa amit szeretnék:for(int i=0; i<3 ;i++)
{
int[] arrayname + i = new int [];
}
És ezt szeretném a végén látni:
arrayname0
arrayname1
arrayname2Valahogy érzem, hogy nem lesz ilyen, ez esetben milyen nyelven megvalósítható ez szerintetek? (ez már off topic )
-
ReSeTer
senior tag
Ok, köszönöm a válaszokat, megpróbálok valamit összehozni ezekből.
-
joysefke
veterán
válasz
ReSeTer #9761 üzenetére
Azt az excel-t nem én irányítom, de ha változik is valami, általában csak annyi, hogy arrébb megy néhány oszlop, mert beszúrnak egyet, vagy törölnek egyet. Ez van.
Az excel a programod publikus API-ja. Ha a másik fél nem tartja magát hozzá, akkor a te programod sem tud stabilan működni. Ha a másik fél valamiért nem tudja magát fixen (legalább verziószerűen) az API-hoz tartani, akkor koncepcionálisan rosszul van kidolgozva az az API. -
quailstorm
félisten
válasz
ReSeTer #9761 üzenetére
YAML az van olyan egyszerű és letisztult, mint az INI, én azt javaslom ebben az esetben. De INI-hez is létezik library: például.
Én INI-vel úgy találkoztam, hogy GSD (PROFIBUS). Ahhoz képest a GSDML (PROFINET, XML alapú), az sokkal könnyebben használható programozás oldalról. INI-be nem tudsz szerializálni és deszerializálni sem (vagy kutatni kell olyan libet, ami tud).
-
ReSeTer
senior tag
válasz
joysefke #9760 üzenetére
Azt az excel-t nem én irányítom, de ha változik is valami, általában csak annyi, hogy arrébb megy néhány oszlop, mert beszúrnak egyet, vagy törölnek egyet. Ez van.
Többiek:
Aki szerkesztené, az semmiféle programozási kódot nem tud olvasni, csak ha tényleg egyértelmű mint pl:példaoszlop = A
példaoszlop2 = BEzt könnyen lehetne szerkeszteni is. Ezért is jutott eszembe az ini, mert anno a játékokban is lehetett változtatni dolgokat rajtuk keresztül, és semmi programozási tudásom nem volt.
De ha az egy rémálom programozási oldalról, akkor hagyjuk.
Valami hasonló? Nem akarom én túlbonyolítani, egyszerű olvasásról van szó.A program amiről szó van, egy egyszerű exe, egyszerű userform-mal. Nincs semmiféle config fájlja, amit én beírtam neki eredetileg, azokat az értékeket használja.
Ha én csinálok neki egy userform-t ahol belehet írni, hogy éppen melyik oszlop melyik, akkor azt minden egyes indításnál be kellene írni tudtommal. Amint bezárod, következő indításnál megint az eredeti értékek lesznek.
Kezdő vagyok, javítsatok ki nyugodtan, ha hülyeséget írok. -
joysefke
veterán
válasz
ReSeTer #9754 üzenetére
Miért nincsen védve az excel vagy annak bizonyos részei a nem kívánt változtatásokkal szemben? Minden lapot/cellát védeni kéne ami az appnak bemenetéül szolgál.
Ha a programod függ a konkrét excel dokumentumtól, akkor ha képtelen vagy elérni azt, hogy ne barmolják szét a bemenetül szolgáló excelt, akkor azt is képtelen leszel elérni, hogy aki "szétbarmolja", az majd pontosan vezesse, hogy mit "barmolt" szét...
szerintem...
-
quailstorm
félisten
Semmihez nem kell WCF. Az csak egy példakód DataContract szerializációra és deszerializációra. Linkelhettem volna ezt is.
Múlt héten kellett pont, ideiglenes megoldásként egy projektbe. Nem volt szabad berakni külső libet és régi .NET*, a DataContract-os szerializáció meg nagyon könnyen elérhető, mert csak a System.Runtime.Serialization reference kell hozzá.*Tehát Newtonsoft-ot nem szabad, de System.Text.Json meg még nincs.
-
fatal`
titán
válasz
quailstorm #9755 üzenetére
WCF mihez kell? Az SOAP és már semmire se használnám.
NewtonSoft.Json, de .NET alatt van már beépített JSON szerializáció/deszerializáció.
A JSON nekem is olvashatónak / szerkeszthetőnek minősül, ha le van dokumentálva.
-
quailstorm
félisten
Lehet én vagyok kocka, de nekem a json már bőven az ember által jól olvasható kategória, beautified formázással. Itt van rá NewtonSoft és System.Text.Json opció is.
Tény, hogy a DataContract az nem szép Json-t exportál, ahhoz a szövegszerkesztőben kell automata formázni (nálam Notepad++ és JSTools plugin, vagy Visual Studio Code).
TOML-t én elvetném, annyira nem tiszta annak sem a szintaxisa. YAML valóban megfelel az olvashatóság és az objektum konvertálás kritériumainak is, elsőre nem jutott eszembe, köszi, hogy bedobtad.
@ReSeTer: mennyire "kocka", aki szerkeszteni fogja azt a szöveges fájlt? Mennyire állandó a konfigurációs fájl struktúrája? Ha nagyon egyszerű, vagy állandó, akkor egy GUI-t sem nagy cucc összedobni hozzá.
-
cattus
addikt
válasz
quailstorm #9755 üzenetére
Ha jól értem az az igény, hogy ember számára könnyen olvasható / szerkeszthető legyen, amire se a JSON se az XML nem igazán alkalmas, én inkább YAML / TOML-t mondanék.
-
quailstorm
félisten
válasz
ReSeTer #9754 üzenetére
Json, vagy XML.
INI egy rémálom, TXT meg 80-as évek.Találj ki valami jó kis objektumos reprezentációt, aztán szerializáció, deszerializáció.
DataContractTudom, hogy nem ez a legszebb megoldás, amit linkeltem, de ezt régi .NET-en is meg lehet oldani külső libek, NuGet és függőségek nélkül.
-
ReSeTer
senior tag
Helló!
Van egy programom ami adatokat olvas ki egy excel fájlból.
Szeretnék egy olyan megoldást csinálni, hogy az user egy szövegszerkesztővel megnyitható fájlban tudná átírni bizonyos változóknak az értékeit (oszlopok azonosítója), hogy ha véletlen a forrás excelben változtatnak valamit és eltolódik a figyelt oszlop, akkor egyszerűen betudná állítani egy átírással, hogy továbbra is jó helyről olvasson a programom.Milyen megoldást javasoltok? Ini fájl? txt? Írni nem kell a fájlba, csak olvasni.
Melyik method-ot ajánljátok hozzá? -
martonx
veterán
"A visualstudio .net alapon hozna létre minden formot. (drag and drop a felülettervezés? Nem lenne komplex a weblap, csak 10 gomb meg 3 táblázat (dinamikus rádiógomobkkal meg checkboxokkal)."
Ilyen nincs. A webfejlesztés nagyon nem olyan, mint a winformsSzóval nincs mese, fel kell majd kötni a gatyát
Hacsak nem az évek óta elavult, depreciated Asp.Net Web Forms-ra akarsz alapozni, amit felejts el nagyon gyorsan.A .Net 2017 óta cross platform (feltéve, hogy a brutál elavult Asp.Net Web Forms-ot szóba se hozzuk, mert az még nem volt cross platform, csak Windows szerveren futott), tök mindegy neki, hogy linuxon vagy windows-on fut.
"Ezen túlmutatóan ha objektumorientáltan akarom a táblázat elemeit megjeleníteni (leképzeni), mert mindegyik elem egy halmaz információt hordoz, akkor c#-ot hogy tudok egy weblap mögé tenni? (ez már gondolom mélyebb kérdés)"
2022-t írunk, a kérdésed szerintem az évtizede elavult Asp.Net Web Forms-ra vonatkozik. Javaslom egy nagy lendülettel ugorj a mába, és tarts pár év gyorsképzést magadnak.
Az internet tele van anyagokkal.Ezt a projektet meg egyelőre felejtsd el, amíg ennyire durván nem vagy tisztában semmivel, és koncentrálj a Hello World és ToDo szintű projektekre.
-
Sokimm
senior tag
Ez esetben akkor írok, hátha valaki válaszol.
Ha létre akarok hozni egy olyan weblapot, ami mögött sql komplex feltételhalmazhoz kötött (gui-ból kijelölt adatok alapján, dinamikusan változó) lekérdezések vannak, akkor mi a járható utam? A visualstudio .net alapon hozna létre minden formot. (drag and drop a felülettervezés? Nem lenne komplex a weblap, csak 10 gomb meg 3 táblázat (dinamikus rádiógomobkkal meg checkboxokkal).
És hogy fut majd a dolog? Az msSQL-hez csatlakozáshoz fut a szerveren az adatbázis, ez oké. A weblap index.hmtl-je mint belépési pont is a szerveren található, és elindítja a .net keretrendszerből felépült strukturált form-omat (mindennel együttvéve, sql, feltételek, gui, stb)?
És ha a szerver linux, akkor honnan rántja a .net-et? Vagy mit jelent a .net egy webform készítésénél?
Ezen túlmutatóan ha objektumorientáltan akarom a táblázat elemeit megjeleníteni (leképzeni), mert mindegyik elem egy halmaz információt hordoz, akkor c#-ot hogy tudok egy weblap mögé tenni? (ez már gondolom mélyebb kérdés)
Köszi a válaszokat előre is. -
Sokimm
senior tag
Szeretnék valakit találni, aki elmagyarázná a struktúrát a windows visualstudio-s web api-s c#-os rendszerről.
Kérem akinek van lelki ereje telefonon segíteni, írjon privátban.
Max 20 percet rabolnám az idejét. -
martonx
veterán
válasz
Victoryus #9749 üzenetére
hagyd az access-es ősi db-t, használj localdb-t vagy valami rendes SQL-t. Delphi ide vagy oda, a local db, akkor sem fog magától átvándorolni a gépek között
EF Core-nál javaslom még a DB migration-t beröccenteni, és akkor legalább a DB sémád rendben tud lenni a gépek között.Úristen, ebből a jegyzetből még én is tanultam több, mint 10 évvel ezelőtt. Ezt felejtsd el, online, naprakész anyagokból tanulj, ne ilyen régi szarokból!
-
Találtam végül entity framework-höz jegyzetet: [link]
Johanyák Zsolt: Vizuális Programozás jegyzete.
Eddig kb. 10x futottam neki, de egyszer sem ment különféle okokból. Most 11x tötöltem ki az egészet és írtam újra. Odáig ok, hogy megvan a 3 tábla, látja őket, lehet mindháromba adatot beírni. De amikor megírom a konzol app-ot, akkor az hibaüzenetet dob: System.Data.Entity.Core.EntityException: 'The underlying provider failed on Open.'
SqlException: An attempt to attach an auto-named database for file F:\teszt\c#_feladatok_kész\GRAFIKUS felület\Telefonszamok_Konzol\bin\Debug\Telefonszamok.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
Az elérési út jó amit ír, ott van az mdf fájl.Egyéb kérdés: eredetileg a munkahelyi gépen írtam, hazahoztam, nem ment, elérési út hiba. Tehát ha egyszer netalán működne is, akkor mindig át kell írni az elérési útját az adatbázis fájlnak? Nem nagyon fogadta el a relatív hivatkozást. Ez ennyire körülményesen működik?
Én anno Delphin tanultam sql kezelést, de nem rémlik hogy ennyit szenvedtünk volna, mint ezzel. -
Sziasztok
Két applikációm között kellene adatokat megosztanom.
Mi a legegyszerűbb/legtisztább implementáció mondjuk egy objektum átpasszolására?
WCF-et néztem szimpatikusnak tűnik a leírás alapján de csak egy 12éves példát találtam.
Csinált valaki ilyet? Hogy induljak el? Van egyszerűbb mód? -
quailstorm
félisten
válasz
ReSeTer #9743 üzenetére
Van egy magyar könyv, Evosoft alkalmazott írta. Szerintem ez elég jó alap.
#9745 Victoryus : megjelenítés rétegben mindegy milyen DB van alatta, szóval inkább általános adatbáziskezelős tutorialokat nézz, meg az accdb driver API kézikönyvét.
-
Sziasztok!
Nem tud valaki egy jó tutorialt/könyvet accdb kezeléshez?
Hogy tudom megjeleníteni egy tábla tartalmát, esetleg módosítani?
Odaáig ment, hogy hozzáadtam a forms application-höz az access fájlt (1 tábla van benne egyelőre), tudok is a táblába új adatokat felvenni űrlapról (textboxokkal).#ReSeTer: viktortaylor.eu Ott vannak kezdő szoftverfejlesztőknek szánt anyagok.
-
sztanozs
veterán
válasz
ReSeTer #9743 üzenetére
Próbálj meg tesztfeladatokat megoldani.
https://www.codewars.com/ például. -
ReSeTer
senior tag
Helló!
Ha a szabadidőmben tanulni szeretnék C#-t akkor tudtok ajánlani roadmapet? Eddig udemy-n található ingyenes anyagon vagyok túl. Hogyan tovább?
Ha esetleg konkrét anyagot tudtok ajánlani az még jobb. A lényeg, hogy feltételezze az anyag, hogy nincs előéletem programozásban. Nagyon tudom utálni, amikor túl bonyolítják a példákat, amikor csak a szemléltetés a cél. -
cigam
titán
Köszi az útmutatást!
-
quailstorm
félisten
válasz
robotjatek #9739 üzenetére
Ja igen, így már értem én is, hogy mit nem látott. Pedig észrevettem a commandot elsőre is...
A Binding (ICommand implementáció) amit néznie kell és F12-vel nyomkodnia. A Click handlert lehet hogy valaki véletlen hozzáadta, de az nem csinál semmit most, inkább törölni kellene.
Ha paraméter kell a Command-hoz, akkor a CommandParameter attribútummal megteheti.#9740 cigam
ICommand WPF MVVM -
cigam
titán
válasz
quailstorm #9738 üzenetére
Bocs! A lényeg lemaradt: Ha elindítom a programot, akkor működik a letöltés gomb, be is tölti kiválasztott szöveget. Csak nem találom a programban ezt a rész! Nem én írtam, Githubról töltöttem le és próbálom átírni magyarra.
robotjatek
Köszi! Ööö... Erre hogyan tudok rákeresni? -
daninet
veterán
Sziasztok!
Valaki validálná nekem, hogy az alábbi kód helyes? Azt akarom, ha ez a loop eléri az auto9.g sorszámot ugorjon vissza nullára (vagyis a számlálóban 1-re amiből kivonunk egyet).
Ezek a fájlok majdnem 6 óráig futnak ezért szeretném tudni a hosszú teszt előtt, hogy amit belekontárkodtam működikvoid CardReader::autofile_begin() {
autofile_index = 1;
(void)autofile_check();
}
bool CardReader::autofile_check() {
if (!autofile_index) return false;
if (!isMounted())
mount();
else if (ENABLED(SDCARD_EEPROM_EMULATION))
settings.first_load();
// Don't run auto#.g when a PLR file exists
if (isMounted() && TERN1(POWER_LOSS_RECOVERY, !recovery.valid())) {
char autoname[10];
sprintf_P(autoname, PSTR("/auto%c.g"), '0' + autofile_index - 1);
if (fileExists(autoname)) {
cdroot();
openAndPrintFile(autoname);
if (autofile_index = 10)
autofile_index = 1;
else if (autofile_index < 10)
autofile_index++;
return true;
}
}
autofile_cancel();
return false;
}
-
joysefke
veterán
Roslyn-nal sikerült működésre bírnom a dolgot, (kb end-to-end megy fordítástól, az authentikációig és sikeres API hívásig
)
De a fordítás csak úgy működik, ha CSharpScript-et használok, ez az opció ahogy látom impliciten felhasználja a runtime betöltött assembliket referenciaként a fordításhoz /ami nincs betöltve csak azt kell referálni/.
CSharpCompilation-nal ugyanaz a fordítás nem működik. Itt nekem kéne expliciten megadni az assembly referencákat, amit természetesen hiánytalanul meg is tesztek. Aztán kapok egy undorító, Google által jól ismert fordítási hibát ami arra panaszkodik hogy a System.Net.Http.dll verzió mismatch van, az assembly ahonnal dinamikusan fordítom a kódot (és ahová interfész miatt függősége van a fordított kódnak) 4.2.0.0-t val lett fordítva, a Roslyn pedig 4.0.0.0-t akarna használni. Hogy a 4.2.0.0 honnan jött, azt nem tudom, de kézzel nem tudom betölteni. Hogy CSharpScript-tel ez miért és hogyan működik azt persze nem tudom.
Majdnem biztos vagyok benne, hogy a hibának semmi köze nincsen a Roslynhoz magához vagy akár a kódomhoz, egyszerűen nem azt a verziót kapom DLL-ből amit szeretnék.
Akik nálam jobban értenek a fordításhoz biztos meg tudnák oldani, meg lesz ez nálam is oldva, hogy "CSharpCompilation"-nel is működjön, de ez így egyáltalán nem bizalomgerjesztő...
Félek, hogy ami az én gépemen dinamikusan fordul, produktív gépen majd esetleg nem fog. Egy halom DLL-t pedig nyilván nem akarok betenni a repoba és nuget helyett azokat referálgatni vagy hasonló okosság.
===
Szóval most a pluginok kerültek fel az asztalra:
Talán ahelyett, hogy konfigból (encryptált DB-ből) on the fly fordítjuk a konkrét megvalósítás kódját, jobb ötlet lenne szükség esetén egy újabb plugin-dll-t berakni egy plugin könyvtárba aztán onnan betölteni a konkrét megvalósítást.Ilyen önműködő plugin megvalósításhoz van net 472-re ennél jobb cucc?
Managed Extensibility Framework (MEF) - .NET Framework | Microsoft DocsHasználta ezt már valaki?
-
dqdb
nagyúr
válasz
joysefke #9730 üzenetére
Az "Add-Type" valami régi fordítót használ, régi C# verió támogatással és a hibaüzenetei borzalmasak.
A Roslyn előtt azt lehetett kihasználni, hogy a .NET Framework része a csc.exe. A futtatni kívánt snippetből generáltál egy teljes .cs fájlt, ahol a generált kódban #pragma line használatával el tudtad érni, hogy az eredeti fájl nevével és a megfelelő sorszámmal dobja a hibát a fordító, futtattad és parse-oltad az eredményt. Működött ugyan, de eléggé meh, a Roslyn ilyen téren megváltás volt a rugalmasságával. -
joysefke
veterán
Eddig csak az első linket néztem meg (azt is egyelőre csak NET6-tal), de szerintem nekem pontosan erre (Roslynra) lesz szükségem.
Valamiért az volt bennem, hogy csak modern platformra van, ezért nem is néztem utána. Az "Add-Type" valami régi fordítót használ, régi C# verió támogatással és a hibaüzenetei borzalmasak.
Aztán hajrá a C# szintaktikájú saját DSL létrehozásához.
Annál azért egyszerűbbnek 'tűnik':
Http szolgáltatás daemon-kliens oldalára szeretnék a kliens HttpMessageHandler pipelinejába beépülő nem-interaktív autentikációs komponsenst (pld OAuth2 Client credentials flow) ami a lehető legszabadabban konfigurálható.A szabad konfigurálhatóság biztosítaná, hogy az autentikáció pontosan úgy történjen, ahogy az autentikációs végpont (token url) diktálja illetve a Http üzenetbe a token -vagy ami az autentikáció meglétét jelképezi -abban a formában kerüljön bele, ahogyan a szerver oldal szeretné.
Az tűnik a kiindulási állapotnak, hogy a jövőben több féle (standardtől kicsit eltérő) lehetőség lesz, mintsem hogy azt statikus konfigurációval le tudjuk fedni.
J.
-
cigam
titán
public static void LoadDocument(Stream fileStream, FlowDocument document, string dataFormat)
{
try
{
TextRange range = new TextRange(document.ContentStart, document.ContentEnd);
range.Load(fileStream, dataFormat);
}
catch (ArgumentException ex)
{
MessageBox.Show("Nem támogatott fájl típus.");
}
}
A fenti kód az rtf fáj betöltés gomb kódja. Hogyan tudnám az összes szín beállítást resetelni?
A cél az lenne, hogy minden betű szín infója tűnjön el, és egy mezei fekete/fehér szöveget kapjak. -
dqdb
nagyúr
válasz
joysefke #9726 üzenetére
Ha C# scriptelést szeretnél, akkor arra ott van a Roslyn, a .NET C#-ban írt C# fordítója, amelyet megfelelő objektummodellel ellátva be tudsz ágyazni saját projektekbe is.
Ez itt egy gyors bevezetés, ez pedig egy minimálisan mélyebb példa annak átlátására, hogy mit is lehet elérni Roslyn segítségével elérni.
Aztán hajrá a C# szintaktikájú saját DSL létrehozásához. Ha nem magadnak írod a cuccot, akkor szerintem érdemes a DSL-nek fluent felületet definiálni, az talán közelebb áll az átlagemberekhez.
-
joysefke
veterán
Konfigurációs adatként szeretnék viselkedést definiálni az applikáció számára.
Az éppen járt megközelítés, hogy a konfigurációs adat némi forráskód lenne, amit szükség esetén futási időben fordít az applikáció és a továbbiakban a fordítás eredményét használja fel mint konkrét implementáció.
.Net 472 illetve PowerShell 5.1 áll rendelkezésre, ennél újabb nem. Az
Add-Type -ReferencedAssemblies $assemblies -TypeDefinition $sourceCode
commandlettel szemezek. Ez fordít C#-ot, az elkészülő Type -ot pedig az applikáció fel tudja használni.Találkozott valaki ezzel a feladattal? Van az adott platform-verzióra ennél jobb ötlet, kiszámíthatóbb, modernebb compiler dobozból? Van az "Add-Type"-pal tapasztalat? Alkalmanként egyetlen osztályt akarok fordítani, de az nem feltétlenül "Hello world"...
-
ReSeTer
senior tag
-
ReSeTer
senior tag
Helló!
Kicsit egyszerűsödött problémám, a Word dokumentumba való beillesztéssel kapcsolatban.
Elég lenne, ha a végfelhasználó egy gomb megnyomása után a vágólapjára másolódna egy formázott dokumentum képekkel is, és megnyitna manuálisan a felhasználó egy Word-ot, majd ctrl+v és beilleszti.Hogyan kellene ezt a feladatot megközelíteni? Először mondjuk valami köztes formátumban létrehozni a dokumentumot, vagy közvetlenül lehet "írni" a vágólapra? A dokumentumban táblázatnak is lennie kell, és adatok is vannak benne.
Így megtudnám kerülni az Office verzió problémákat, meg az open XML agyonbonyolított hülyeséget.
-
leslie23
tag
válasz
joysefke #9711 üzenetére
Többször is átolvastam, emésztem az infókat, de érteni vélem az érveidet és logikusan is hangzik az általad felvázolt koncepció, szóval nagyon köszönöm az idődet és a segítséget!
GitHubon és demo tutorialokban főleg egyszerű, néhány oldalas CRUD appokat látok mindig, szóval nehéz olyan realworld cuccost találni, ami komplex, mégis jól átgondolt, és követ valamiféle helyes gyakorlatot. Lassan, de kezd tisztulni a kép, köszi még egyszer! -
Alexios
veterán
válasz
martonx #9716 üzenetére
Biztos mennie kell macen is, eleve a Xamarin Studiot nevezték át anno vs for mac-re, ios fejlesztésnél kell mac eleve hozzá a buildhez, bár hobbi projekthez én is vagy maui-t(mondjuk ebből még mindig csak previewk vannak..) vagy react nativeot kezdenék inkább tanulgatni már.
Hogy a témához is hozzászóljak, milyen macről van szó?
[link] Itt ugyan erről a hibáról írnak, esetleg erre rá lehet nézni -
martonx
veterán
válasz
Alexios #9715 üzenetére
Mac-en az egyetlen komolyan vehető C# IDE a Rider, igen ez jogos (windows-on a mellettem ülő kolléga Riderezik, én VS, hát egyelőre még a VS jobb, de a Rider se rossz, illetve van amiben a Rider messze jobb azért a pénzért pl. tesztek).
Mondjuk az ingyenes VS Code-al is konzol appok, minimal web api-k szintjén el lehet lenni. Xamarinról abszolút nincs tapasztalatom OSX-en, tegyük rögtön hozzá, hogy szvsz a Xamarin még windows-on is macerásMac-en nem lepődnék meg, ha abszolút nem is működne a Xamarinos fejlesztés.
-
kkdesign
senior tag
Sziasztok!
Szeretnék segítséget kérni abban, hogy nemrég tértem át MAC-re, feltettem a Visual Studiot, C#ban szeretnék Xamarinban próbálkozni, tanulgatni, majd valami appot készíteni. Viszont már az elején az emulátornál elakadok. Próbáltam utánanézni neten, de Windowsos megoldást láttam csak, hogy szolgáltatásokban engedélyezzem a Hyper V egyes részeit. Ezt MACen elég nehéz megvalósítani, viszont lövésem sincs, hogy mi alapján tudnám ezt megoldani. Volt valaki hasonló cipellőben? Van ötletetek rá? Android studio is fent van, azért is, hogy hátha az sdk-val lett vna gond, de nem. Köszönöm előre is
-
joysefke
veterán
válasz
joysefke #9711 üzenetére
lemaradt:
Mivel DI-t és teszteket szeretnél használni (hogy az egész 1b arch egyáltalán értelmet nyerjen) ezért valahol össze kell állítanod a DI konténert (ez a composition root, a te esetedben a ConfigureServices metódus az ASP templétben).Magának az ASP projektnek értelemszerűen nem kéne sőtt nem szabadna dependenciája legyen mondjuk az Ef projekthez, de a composition rootnak (ConfigureServices metódusnak) szüksége van rá, mivel ez alapvetően a solutionben lévő összes függőséget referálja. Ez ezen az egy ponton rendben van. Ha zavar, akkor a DI-konténer összerakását kiszervezheted egy másik csproj-ba.
-
joysefke
veterán
válasz
leslie23 #9709 üzenetére
Két párhozamos dologról volt szó amelyek egymástól valamennyire függetlenek:
A fontosabb döntés:
1,
1a, N layer (Te nyilván háromban gondolkodsz) vs 1b Hexagonal (vagy ahogyan hívni szeretnéd) arch.másodjára
2,
2a, Generikus Repo/UoW mögé rejtett EF DbContext vs 2b Domain specifikus perzisztencia interfészek (nem tudom a nevüket bocsi)Én azt sugalltam, hogy ne próbálj meg tankönyvi N-layert csinálni.
Ezen felül nekem fenntartásaim vannak azzal kapcsolatban, hogy az DbContext-et bezárjuk egy generikus Repo/UoW mögé és majd az "applikációs réteg" használja a az Insert/Update/ etc metódusokat (az eredeti írásodból azt olvastam ki, hogy erre készülsz) .
Szóval anélkül, hogy tudnám, hogy egyáltalán mit akarsz csinálni, nekem az alap hozzáállásom egy újabb kis hobbiprojektemhez amiben van ASP meg DB a következő lenne (a nevek szabadon variálhatóak, csak próbáltam beszédes neveket varázsolni):
MyProjekt.ASP => MyProjekt.Core <= MyProjekt.Ef
Nincsenek rétegek és nincsen sem teteje sem alja, viszont van közepe meg vannak a többiek. A nyilak a dependencia irányokat mutatják.
Mindenki a közepét referálja, a közepe viszont nem referál olyan dolgokat amelyektől nem akar függeni. Nem referálja sem a saját EF vagy ASP függő projektjeidet sem magát az ASP vagy EF frameworkot
Amikor a közepe valamit akar a "széllétől", akkor azt egy saját magában definiált interfészt használva teszi meg
Ennek két hatása van:
-a közepe mindenki nélkül, önmagában is fordul, ez megteremti a lehetőségét, hogy könnyedén unit teszteld
-a közepe a függőségeket (pld EfPerzisztencia) DI formájában (leginkább konstruktoron keresztül) kapja meg, ez pedig megint erősíti a közepének a unit tesztelhetőségétAhhoz, hogy ez megvalósuljon, a dependenciák invertálva vannak:
Ha ez egy N-layer arch lenne, akkor az "Application layer" referálná a DAL-t (vagy közvetlenül, vagy interfészen keresztül, de az interfész is logikailag a DAL-ban lenne).
De itt nem, itt ez fordítva van. Itt amit a DAL (ábrán MyProject.Ef)-tól a Core használni akar, az interfész formájában definiálva van, és ez az interfész a "Core" része és a DAL valósítja meg.Másrészt a "Core"-ban lévő dolgoknak amelyek valamit akarnak a széllétől (pld perzisztálni) nyilván szükségük van olyan objektumokra amelyek ez meg is tudják csinálni (megvalósítják azt az interfészt amit a "Core" adott osztálya éppen használni akar). Ezek az objektumok DI-jal kerülnek be leginkább mint konstruktor paraméter. A DI konténert a te esetedben az ASP-s template ConfigureServices-ban tudod konfigurálni (ez gyak. az applikáció belépési pontjánál van).
Visszatérve a konkrét kérdéseidhez:
-Az ASP-s Controllerek, View-k Modell-ek (azok amelyek a Html-be szállítják az adatot) azok mind az ASP-s projektedbe kerülnek.-A Core-ba kerül minden "domain model" (első körben az entitásaid is mindenképpen akár van annotáció rajtuk akár nincs) meg mindenféle logika ami ezeket érinti.
-A "Core"-ból mindenféle frameworkos stabil osztály felé mehet dependencia, pld a DataAnnotation-t amit korábban felvetettél reálisan nem fog problémát okozni és a tesztelést sem nehezíti meg.
-Mehet külső dolgok irányába is, ha azok nem nehezítik a tesztelést meg nem akarod őket soha lecserélni. pld Newtonsoft.Json.
-A "Core" specifikálja interfészekkel, hogy mit kell tudjon a perzisztencia (meg egyéb függőségek amelyektől akar valamit) és ezek az interfészek a core-ban vannak.
-A külső projektekben lévő függőségek pedig megvalósítják a Core-ban azt/azokat az interfészeket amelyek miatt nekik egyáltalán helyük van a szolutionben.
Tehát ha maradsz a generikus repositorinál, "2a" akkor a Te általad tervezett ...
IPersonRepository
,IProductRepository
, ...IRepository<T>
...IProductRepository
...IRepository<Product>
interfészeid is mind a "Core" ba mennek,egy a lényeg, a Core-ba nem kerülhet be EF függőség (tehát az interfészeid metódusainaknak sem lehet EF ben deklarált paramétere, visszatérési értéke). A Repository interfészed konkért megvalósítása viszont az Ef-projektbe kerül.
Vagy dobod a generikus repository-t ez a "2b" és ekkor a Core-ban nem a fenti teljesen álltalános perzisztencia interfészek lesznek mint hogy az IPersonRepository-n lesz mondjuk egy void Save(Person person), hanem lesz mondjuk egy (csak a példa kedvéért)
IPersonCommands
{
void SetProfileImage(int personId, Picture picture);
}
ugyanúgy a "Core"-ban, ezt meg mondjuk megvalósítja egy EfPersonCommands az Ef projektben. Szintén csak a példa kedvéért:EfPersonCommands: IPersonCommands
{
IDbContextFactory<PersonContext> _factory
// vagy Optionst injektálsz (az a preferált ebből szintén elő tudsz állítani Contextet amikor kell) vagy factoryt, mindkét opció tiszta lesz DI-jal,
EfPersonCommands(IDbContextFactory<PersonContext> factory)
{
_factory = factory // throw if null..
}
void SetProfileImage(int personId, Picture picture)
{
using var context = _factory.Create();
//csinálsz valamit
context.Save() <= tranzakció
} <= dbcontext dispose
}
A kliens pontosan azt kapja amire szüksége van (cserébe potenciálisan több metódusod lesz), a megvalósításba már bele van csomagolva a tranzakció.
2a vs 2b az részletkérdés (könnyen tudsz változtatni bármelyik irányban), 1a vs 1b viszont egyáltalán nem. -
leslie23
tag
válasz
joysefke #9708 üzenetére
Igen, az mindenképpen cél, hogy a presentation layernek ne legyen EF Core dependenciája és ahogy Alexios is írta, ha éppen arra van szükség, gond nélkül cserélhető legyen a DataAccess layer akár Dapperre, sima ADO.NET-re, bármire.
Mivel saját hobbiprojektről van szó, így erre soha nem fog sor kerülni, de most valahol pont az elmélet érdekelne, hogy hogyan lehet és kell ezt jól megcsinálni. Olvastam a hivatkozott MS-os leírást is egyébként.„Ami nekem sokkal szimpatikusabb...”
Huhh, lehet, hogy valami nagyon hasonlóról beszélünk egyébként, próbálom értelmezni. Neten található projektek alapján most úgy legoztam össze, hogy a presentation layer egyIUnitOfWork
interfészt lát a DataAccessből, és aProgram.cs
-ben bele van rakva egy példánya aUnitOfWork
-nek DI konténerbe.IUnitOfWork
szintén interfészeket tartalmaz mint property-k (IPersonRepository
,IProductRepository
, stb.).
A generikus Repo-nak is van egy generikus interfésze (IRepository<T>
), ebben nincs pl. Update metódus, csak Add, Remove, GetAll, GetFirst.IProductRepository
örökölIRepository<Product>
interfésztől, illetve tartalmazhat specifikus metódusokat, mondjuk épp egy ilyet hogy:void Update(Product product)
.
A konkrét implementációk pedig pl.:ProductRepository : Repository<Product>, IProductRepository
,
vagyis öröklik a generikus repo metódusait, és implementálják az entitás-specifikus metódusokat, annak számít most mondjuk egy Update is.Ha jól értelmezem az általad írottakat, valami hasonlóra gondolsz, csak az interfészeket szerencsésebb lenne kiszervezni egy külön assembly-be, ami amúgy logikusan is hangzik.
Mondjuk ha jó a sejtésem, az EF Core-t teljesen nem lehet „száműzni” a presentation layerből, mert a DI miatt a kell a builder.Services.AddDbContext...Automapper témában sajnos csak másra tudok mutogatni, jómagam még nem kísérleteztem vele, így nem tudom mennyire validak az itt leírt ellenérvek...
-
joysefke
veterán
válasz
Alexios #9707 üzenetére
Nekem ezzel és ehhez hasonló generikus repositorikkal: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs
Az a bajom, hogy az ilyen metódusok mint Update<T>(T entity) , esetleg Save<T> (vagy Upsert<T>), Delete() elhitetik a hívó oldalon, hogy ennyire egyszerű a perzisztencia, hogy meghívod őket utána a UoW-ön egy Save()-t és kész. És hogy ez mindenre működik amit típus paraméterként át tudnak adni.
Holott
-nem feltétlenül értelmezhető/működik minden lehetséges T entitás típuson az összes művelet,
-nem hívhatsz egymástól függetlenül mindenféle Repository metódust egy UoW tranzakción belül,
-illetve lehet hogy mondjuk az Update<T>(T entity) működik, de mondjuk az adott konkrét entitásra nem a mindenkire érvényes implementáció-t akarná a kliens kód hajtani.
-Az is lehet hogy van egy entitásod ami már trackelve van, mivel az egyik repository metódus impliciten előkerítette, majd a másik ráhív egy attach-ot a már trackelt entitásra. => exception, holott amit a kliens el akar érni annak van értelme és meg is valósítható lenne egy tranzakción belül (DB engedné egy megfelelő SP-vel, illetve engedné az EF is, ha ügyesen lenne megcsinálva).Ami nekem sokkal szimpatikusabb:
Kliens kód kap egy interfészt amin azok a perzisztencia műveletek vannak amelyekre a kliensnek konkrétan szüksége van.
Az interfészt megvalósító osztály EF-függő, az adott metódusa pedig közvetlenül indít EF dbcontext-et (lehetőleg DI-on keresztül szerez ehhez egy DbContextFactoryt vagy azzal egyenértékű opciót amiből Contextet lehet előállítani), közvetlenül attach-csolhat entitást és állít EntityState-t, illetve menti a tranzakciót. Tehát kihasználja az EF tényleges tudását és azt biztosítja a hívónak amire annak szüksége van, lehetőleg egyetlen hívásból.
-
Alexios
veterán
válasz
joysefke #9706 üzenetére
2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.
Én ezzel szintén saját tapasztalat alapján nem értek egyet, nálunk pl. nagyon jól működött mikor legacy appot migráltunk ef6-ról ef core-ra, majd szintén mikor bizonyos részeket dapperre. A kliens kód oldaláról lényegében semmi változás nem történt csak az interfészek mögötti implementációk -
joysefke
veterán
válasz
leslie23 #9705 üzenetére
Én sem vagyok guru
N-tier architecture-t próbálok kialakítani
tankönyvekben jól működik....van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek...
Az én személyes nem feltétlenül objektív véleményem erről az EF+UoW/Repository a témáról.
Az Ef DbContext osztálya az már önmagában egy UnitOfWork, benne a DbSet<T> pedig egy Repository megvalósítás.
1,
Ezt becsomagolni egy másik UoW/Repository abszrakcióba csupán azért hogy legyen egy repositorid vagy UoW-öd önmagában semmi értelme.2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.Itt van pld a docs.microsoft.com oldalán egy Generikus Repository UoW sablon ami absztrakció mögé helyezi a Repo/UoW pattern konkrét megvalósítását, az EfCore DbContext-et: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs
Nekem ezt az absztrakciót mentésre (C/U) a legprimitívebb esetektől eltekintve nem sikerült érdemben használni. Orrán száján ereszt. A relációs adatbázis FK constraintjei illetve hogy az EF change tracker éppen melyik rigojáját alkalmazza fogják meghatározni, hogy egy Update az éppen működik vagy sem. Az relációs constrainttel nincs gondom, de a másik az nekem komoly probléma.
...Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye....
N-layerben az egyes layerek csak lefele dependálnak és ha egy mód van rá, akkor csupán a közvetlenül alattuk levő réteg felé. A ViewModel az prezentációs réteg (az ASP-kontrollerrel együtt).
...tetszik, hogy így a Data layerben nincs data annotation használat (Required és ErrorMessage stb.), hiszen ezek a dolgok logikailag gondolom inkább a Presentation layerhez tartoznak...
Optikailag nem néz ki jól, ha egy több projekt által használt model osztályon olyan speciális attributumok vannak definiálva aminek semmi köze az adott assembly céljához, DE a Te esetedben a "System.ComponentModel.DataAnnotations" az ugye része a Core frameworknek és része lesz a jövőben is és a visszafele kompatibilitás adott lesz. Ezért ez egy "nem-volátilis dependencia", reálisan soha nem lesz útban, soha nem romlik el, max a szemedet fogja szúrni. Szemben mondjuk az EF Core-ral, ami egy "volátilis dependencia": 1-2 évente újraírják és minden verzióugrás tele van funkció-törő változtatással.
Ráadásul ugye a "System.ComponentModel.DataAnnotations" használata vagy nem használata semennyiben nem fogja a tesztelhetőséget befolyásolni, míg a DAL tesztelése vagy tesztekben való kiváltása az egy téma amivel majd foglalkozni kell, szóval a DataAnnotations elhelyezése -szerintem- az utolsó prioritás amin töprengened kell.
szükségem van ... mappingre, ami manuálisan nyilván sok-sok favágó kód írásával járna, AutoMapperről pedig azt olvasom, hogy nem igazán jó megoldás, ha oda-vissza adatátadás történik.
Én is csak ezeket ismerem. Hogy két irányú mappelésnél mi lenne a probléma, azt nem tudom. N-layer esetén mivel a felső réteg ismeri/hívja az alsót, ezért logikusan a felsőbb rétegnek kell hívnia a mappelést is. (mivel az alsóbb réteg nem ismeri a felsőbb rétegben definiált modellt (fordítva viszont igen), hiszen nincsen oda dependenciája (projekt referálása)). A mappelés az logikailag infrastruktúra kód "plumbing". Minden réteg használhatja (dependálhat felé), ennek megfelelően be lesz betonozva a projektbe.
Egyáltalán helyes a megközelítésem? Köszi előre is!
Ha maradsz az N-layernél, akkor az, hogy minden réteg (ami nem valamilyen mindent átható infrastruktúra (mapper/logging)) az csak lefelé dependál. Ha az EF-Core-DAL-t reálisan ki akarod váltani vagy szeretnéd, ha egy EF Core 6 DAL => EF Core 7 DAL váltás sima legyen, akkor lehet hogy jó ötlet lenne az applikációs logikát a DAL-tól egy DAL interfész segítségével elválasztani, ami a saját önnálló assembly-jében van. Ez a stairway pattern. A DAL megvalósítás interfészen keresztül (amely külön assemblyben van) le van választva a használójától és a megvalósításától is. Ennek van egy pozitív hozadéka: Le tudod fordítani a solutiont működő DAL megvalósítás nélkül is. => És ez visszafele is igaz. Enélkül ha nem fordul a DAL projekt, akkor semmi sem fordul.Ahogy én állnék neki (és ez szubjektív és nem feltétlenül helyes megközelítés):
Dobnám az N-layert publikus generikus repositorival meg UoW-kel együtt.Lenne egy prezentációs projekted (ASP), lenne egy külön konkrét EF-Data access megvalósítás projekted meg lenne egy olyan projekted ami sem a prezentációs sem a data access projektet nem referálja. Ez tartalmazná az entitások modell osztályát is , illetve az összes interfészt amelyeken keresztül mondjuk a perzisztenciát akarja vezérelni. Az interfész pontosan azt és csak azt deklarálná amire a központi projektednek szüksége van. Meg tartalmazná az összes tiszta domain-logika kódot. A lényeg, hogy ez a központi projekted kifelé nem dependálhat volátilis dependenciák (EF Core, Adatbázis) irányába. Dependenciák invertálva vannak befelé.
A cél itt az, hogy volatilis dependenciák hiányában a központi projekted könnyedén unit tesztelhető legyen. Az emlegetett mappelgetés is sokkal kisebb probléma.Üdv
J. -
leslie23
tag
Sziasztok!
ASP-guruk tanácsára lenne szükségem, bár inkább általános jellegű a kérdés. Egy viszonylag egyszerű webappon dolgozok (.NET6 Razor Pages és néhány controller, amiket AJAX-hívásokkal használok) és N-tier architecture-t próbálok kialakítani.
Van egy Data rétegem, amibe csak a domain model class-okat rakom, van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek, illetve van egy Presentation project, ami maga a webapp.Az első kérdésem, hogy a ViewModel-eket hogyan lenne célszerű elhelyezni? Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye. A scaffolded Identity lapok tartalma alapján azt látom, hogy a MS fejlesztői a ViewModeleket magukba a RazorPage-ek PageModel-jébe rakják, minden laphoz tartozó .cshtml.cs fájlban van egy InputModel class, és ennek egy példányára alkalmazzák az adatkötést a [BindProperty] attribútummal. Ez a megoldás olyan szempontból is tetszik, hogy így a Data layerben nincs data annotation használat (Required és ErrorMessage stb.), hiszen ezek a dolgok logikailag gondolom inkább a Presentation layerhez tartoznak.
Viszont ha innen közelítem meg a dolgot, akkor minden esetben szükségem van Model - ViewModel mappingre, ami manuálisan nyilván sok-sok favágó kód írásával járna, AutoMapperről pedig azt olvasom, hogy nem igazán jó megoldás, ha oda-vissza adatátadás történik. Mi ilyenkor a bevett megoldás, vagy mi számít itt gold standardnek? Egyáltalán helyes a megközelítésem? Köszi előre is!
-
coco2
őstag
Sziasztok!
Van egy winforms alkalmazásom (c#), amit másik alkalmazásból indítok el _wsystem() winapival. El is indul, de megjelenik mellette egy extra shell ablak (üres konzol). Jó lenne, ha az nem lenne. Ha valaki találkozott már a problémával, valami bölcsesség jól jönne.
Előre is köszönöm
Ú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!
- Eredeti játékok OFF topik
- Nvidia GPU-k jövője - amit tudni vélünk
- Milyen SSD-t vegyek?
- Spórolós topik
- exHWSW - Értünk mindenhez IS
- Linux kezdőknek
- Elden Ring
- Megjelent a The Last of Us Part 1 PC-s kiadása
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- A hardverek is nehezen viselik a kánikulát
- További aktív témák...
- SZÉP Lenovo ThinkPad P15 G2 Tervező Laptop -75% 15,6" i9-11950H 64/2TB RTX A4000 8GB UHD OLED
- Szép! Lenovo Thinkpad T14s G2 Üzleti "Golyóálló" Laptop 14" -50% i7-1185G7 4Mag 16GB/512GB FHD IPS
- Eladó Apple MacBook Pro 13" A1706 (Late 2017, Silver - EMC 3163)
- Amazfit GTR 2 Classic okosóra dobozában töltőkábellel
- Mac mini M1 chip 8 magos CPU-val, 8 magos GPU-val
- Bomba ár! Dell Latitude 5590 - i5-8GEN I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W11 I Gari!
- Xiaomi 11T Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! Apple Watch SE/Apple Watch SE 2 (2022)
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- KATONAI ÜTÉSÁLLÓ!!! Getac S410 i5-6300u, G3: i5-8365u, G4: i5-1145G7
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest