TOOMIX: Klasickej úkol je pouštět nějaký obskurní starý nativní c++ v zbrusu novém c# gui. To je samozřejmě nuda, kterou umí každej zpaměti.

Opačnej úkol je mít např c++ síťovej server a business logiku v c#. Čili c++ musí být ten driver a c# je potom volanej z c++ částí.
Příklad jak to dělat je zde: https://github.com/dotnet/docs/blob/master/docs/core/tutorials/netcore-hosting.md
Ve frameworku 4.7.2 to mam hotový a funguje to hezky a jednoduchý to neni. V .net core je to trochu složitější a způsobů jak to dělat je víc a chtěl bych vědět, jestli na to jdu dobře a tak..

MAIMONIDES: jak to myslíš, v nativním procesu? Pustit v konzoli jako exe nebo jako windows service?

EUCHRID: Jenže ta třída by IMHO měla dávat smysl sama o sobě, neměl bys mít třídu, která jde zkonstruovat jen reflexí. Ale samozřejmě to můžeš vyřešit vhodnými přístupovými právy: třeba ten konstruktor udělat internal, jestli to máš v jednom assembly s tím, kdo to vyrábí. Anebo si z toho udělat interface a mít privátní implementace. Ale je to všechno IMHO zbytečný oser jen proto, abys někomu zakázal vyrábět instance, což taky nechápu, proč se tak bráníš.

Anebo místo reflexi na callera dej jako jeden z parametrů toho konstruktoru instanci nějaké třídy, jejíž instanci umí vyrobit jen ta databázová třída (public sealed třída s privátním konstruktorem, uvnitř té databázové třídy), tím zajistíš, že ti to nikdo jiný nevyrobí. Ale jak píše MAIMONIDES, je to celé úplně zbytečný fašismus.

(vím, že to jde, mám sample.. jen bych to chtěl mít trochu příčetněji strukturovaný a pochopitelnější)

Hostoval jste někdy někdo netcoreapp3+ v nativním procesu?

Jde o to, že nechci, aby ve vyšších vrstvách s některými vlastnostmi někdo manipuloval, ale chci mu umožnit je číst. Veřejný konstruktor s takovými parametry bych dělal jen kvůli db, nikde jinde bych ho ale nechtěl dovolit použít (a tohle by řešilo problém).
Když udělám parametrický konstruktor, a někdo mi ve vyšších vrstvách vytvoří ten objekt, tak do těch parametrů dá co chce, a tomu se potřebuji vyhnout. Neměl by tyhle položky mít možnost nijak měnit.
Pokud je tohle to řešení, budu muset nakonec použít parametrický konstruktor, a potom děkuji za radu.

MORMEGIL: Ony se mají nastavovat jen, když vytahuju objekt z db, nikde jinde. Jak píšu, běžně to dělá i microsoftí EF (https://thedatafarm.com/data-access/entity-framework-private-constructors-and-private-setters/) a s Dapperem to v jiné třídě normálně funguje.

EUCHRID: Nechápu, jak se tedy ty hodnoty toho objektu mají nastavovat, když má privátní settery. To je tam nějaká metoda, která jich nastavuje víc najednou, nebo se nastavují jenom v parametrickém konstruktoru nebo jak? (Pokud ten objekt tu vlastnost nastavovat vůbec nedovoluje, tak máš prostě smůlu a _chceš_ ho znásilňovat a prasárna to bude vždycky…)

Zdravím všechny, po mnohahodinovém pátrání se obracím zde, zdali by mi někdo neporadil, nebo nenavedl správným směrem.
V práci nemůžu používat EF, jen Dapper. Mám objekt, který má některé settery propert privátní, ale jejich hodnoty potřebuji dostat z db do toho objektu. EF to umí (jak to dělá se mi nepodařilo najít, ale nějak vyžívá privátní konstruktor), Dapper také, ale musí se shodovat názvy sloupců v db s názvy propert v objektu. Toho ale nemůžu využít, protože Dapper vyžaduje bezparametrický konstruktor a ten objekt parametry má, takže to v datové vrstvě musím sestavovat pomocí non-generic api, jak to mají popsané v dokumentaci (MojeVlastnost = row.MojeVlastnost). Což mě vrací k problému, že samozřejmě nejde vložit hodnotu z db do property s privátním setterem. Řešení, která jsem našel se mi moc nelíbí: buď to znásilnit pomocí reflexe, nebo mezi db a daný objekt vložit další třídu a slepit to v nějaké továrně (to by šlo, ale zase se musím starat o nějakou mezitřídu). Nebo to vyřešit tím, že se objekt bude umět sám uložit a načíst z db a potom je problém s přístupem vyřešen, ale byl bych raději, kdyby se o databázi starala nějaká třída k tomu určená.
Nerad bych udělal nějakou prasárnu a fakt si tady nevím rady, ale možná se jenom špatně ptám googlu...
Nesetkal se někdo s něčím podobným? Mohlo by mě navést i to, jak se to řeší v ado.netu?

[ OFFERING WORKNABÍZÍM PRÁCI: junior C++ Software Engineer / Prague / 60000 CZK ] shanime absolventa nebo proste C++ juniora, nevite o nekom? posta pls

PJOTRIK: "tenhle code analyzer" mel byt https://github.com/SergeyTeplyakov/ErrorProne.NET , nevim co ten odkaz po ceste spolklo

PJOTRIK: Situace, kterou to řeší je, že máš někde velký structy a předáváš si je v parametru bez refu a bereš je jako readonly a zároveň je to v něčem časově kritickym. Trochu teoretická situace.

MAIMONIDES: Ja vnimam jako uzitecny i samotny fakt ze deklaruju ze parametr je "in", zvysena rychlost je fajn, ale resil bych ji jen na konkretnich mistech na hot path (a to jsem nijak nemeril).
Chybu jsem v te souvislosti objevil jednu, netykala se ale konkretne in parametru. Na upravy jsem vyuzil tenhle code analyzer, ktery odchytil ze nekdo pouzil KeyValuePair jako klic v Dictionary.

MORMEGIL: ale jo, smysl to dava, ale libilo by se mi kdyby kompilator umel rozlisit ty opravdu problematicky pripady a ty kde se lambda pouziva jen treba kvuli citelnosti. Na druhou stranu, to ze se tam pouziva takova konstrukce asi znamena ze to nebude nekde uvnitr vykonnostne kritickyho mista, tak se to da chapat i jako signal ze tady ten "in" parametr neni potreba.

A u toho dynamic dispatche teda nechapu ani duvod.

MORMEGIL: To je validni pohled. Pak se najdou jini, kteri jsou nastvani ze to "funguje jen nekdy" (coz je tedy pripad temer vseho v .NET ceho jsem dotkl - pravda, neni toho moc :-)

Ja osobne radeji preferuji ortogonalitu, kam vede tenhle pristup "nejdulezitejsi je vykonostni optimalizace" je videt pekne na C++.
Ale to jsme OT, ja jen odpovidal na MORMEGIL a MORMEGIL

MAIMONIDES: Tak primární motivací je výkonnostní optimalizace (méně kopírování), úplně bych nečekal, že se tím odhalí nějaká chyba… (Jedinou možnost vidím v tom, že někdo ve struktuře předávané hodnotou něco změní, protože si myslí, že se to projeví někde jinde, ale to je vcelku obskurní scénář, řekl bych.)

PJOTRIK: a odhalilo to zavádění jedinou chybu nebo přineslo nějakej užitek?