[C#] Ottenere una Classe dal suo nome passato come parametro String?

[alka]

Probabimente non è semplice allora come credevo.
Vediamo se riuscite a capire od io a spiegarmi meglio.

Dipende: se provi a rispondere alle domande che ti vengono poste, forse qualcosa si capisce, ma se continui a ignorarle e a dire quello che ti passa per la testa senza alcun contesto, ne dubito.

Ma a me occorrono fortunatamente solo le proprietà di ogni classe C che qui sta per Articoli.

Sorvolando sul fatto che questa cosa non ha senso e sembra anche uno scioglilingua ("classe C per articoli", ma che vuol dire?), stai sempre tentando di spiegare dettagli riguardo la soluzione farraginosa e probabilmente non utile a cui hai pensato riguardo un problema che ti si continua a chiedere ma che invece non vuoi descrivere, quantomeno non in lingua italiana o comprensibile, il quale può essere magari facilmente risolto in un altro modo che non richiede assolutamente gli strumenti e gli accrocchi che stai mettendo in piedi, e per esperienza posso dire che al 99,9% la questione sta in questi termini.

Non so se è obbligatorio, ma generalmente per accedere alle precise proprietà di un oggetto occorre convertire l'oggeto generico che nell'esempio è objX nel oggetto particolare di cui si vogliono le proprietà.
Altrimenti come dici tutto si complica, e dovrei scartare tutte le proprietà inutili.

Se accedi alle proprietà scrivendo codice del tipo obj.Property, sì, ma tu stai usando la Reflection, per non si sa quale motivo peraltro, che invece non ha questi requisiti in quanto - appunto - è una API fatta apposta per prescindere dalla tipologia degli oggetti, che vengono ispezionati tramite altri oggetti che li descrivono.

Ovviamente ho più classi Articoli(DbSet<Articoli>), ma il concetto rimane quello.

Ma quale concetto? Sai cos'è una classe? Articoli(DbSet<Articoli>) non è una classe, ma il nome di una classe con delle parentesi e all'interno il nome di un'altra classe, che non ha alcun senso sintatticamente parlando e non si capisce a cosa serva, né evidenzia quale sia lo scopo finale di tutto ciò, ribadisco.

Non penso che nel 2023 queste cose siano irrisolte o poche funzionanti/ottimizzate

Di cose irrisolte non ce ne sono, questo è sicuro.
Se appaiono irrisolte, può essere che lo siano in quanto non in grado di supportare la soluzione senza senso che stai portando avanti e che non vuoi descrivere.

[alka]

Il fatto è che a fare questo, tutto si semplifica dopo, almeno penso.
Da quello che posso intuire ovviamente.

Mi sa che il problema è proprio qui.

Se ho mille Tabelle/Oggetti da cui estrapolare i dati posso farlo subito.
Indipendentemente dalla tabella.

Non si capisce se stai parlando di database, di SQL, di ADO.NET, di LINQ 2 SQL, ma a prescindere da tutto questo, ciò che dici è sempre possibile comunque, a prescindere da tutto il "castello di sabbia" che stai faticosamente costruendo e che continua a non avere un senso apparente.

[U235]

@U235:



Probabimente non è semplice allora come credevo.

Vediamo se riuscite a capire od io a spiegarmi meglio.

La tua potrebbe essere una soluzione.

Ma a me occorrono fortunatamente solo le proprietà di ogni classe C che qui sta per Articoli.

Non so se è obbligatorio, ma generalmente per accedere alle precise proprietà di un oggetto occorre convertire l'oggeto generico che nell'esempio è objX nel oggetto particolare di cui si vogliono le proprietà.
Altrimenti come dici tutto si complica, e dovrei scartare tutte le proprietà inutili.

Ovviamente ho più classi Articoli(DbSet<Articoli>), ma il concetto rimane quello.
Non penso che nel 2023 queste cose siano irrisolte o poche funzionanti/ottimizzate

Ok, il punto è: come vuoi poi utilizzare "y" del tuo esempio? se non conosci a priori cosa chiamare di y perché non è noto in compilazione, allora giustamente non ti serve fare poi il cast senza conoscere che fare con quell'oggetto... Mi potresti rispondere (suppongo... ma è questo quello su cui mi sembra che sia reticente) che tutte le classi hanno una proprietà "ID" di tipo int, in questo caso qualsiasi classe creata a partire da una tabella avrà la proprietà ID, quindi tu da "y" vuoi ricavare l'ID (a prescindere dal tipo, che sia Articoli oppure Ordini). In questo caso ci sarebbe una spiegazione, ma il modo migliore di ottenerlo è diverso da quello che stai pensando tu, ovvero si dovrebbe creare una classe base la quale andrebbero ad ereditare tutte le entità (tabelle), e tu fai il cast alla classe base. Puoi anche utilizzare le interfacce al posto di classi base, in questo modo potrai lavorare con più "derivazioni" o se ad esempio le classi già ereditano da altre classi. In ogni caso a quel punto il cast lo fai sulla classe base o sull'interfaccia e non sul tipo derivato, in quanto il tipo derivato lo dovresti conoscere in compilazione per poter fare il cast come intendi farlo tu. Da li nasce poi tutto il resto, tra cui anche sfruttare la reflection, ma soprattutto i Generics.

[optime]

@jabjoint, perché hai più classi Articoli?

[jabjoint]

Ok, il punto è: come vuoi poi utilizzare "y" del tuo esempio? se non conosci a priori cosa chiamare di y perché non è noto in compilazione, allora giustamente non ti serve fare poi il cast senza conoscere che fare con quell'oggetto... Mi potresti rispondere (suppongo... ma è questo quello su cui mi sembra che sia reticente) che tutte le classi hanno una proprietà "ID" di tipo int, in questo caso qualsiasi classe creata a partire da una tabella avrà la proprietà ID, quindi tu da "y" vuoi ricavare l'ID (a prescindere dal tipo, che sia Articoli oppure Ordini). In questo caso ci sarebbe una spiegazione, ma il modo migliore di ottenerlo è diverso da quello che stai pensando tu, ovvero si dovrebbe creare una classe base la quale andrebbero ad ereditare tutte le entità (tabelle), e tu fai il cast alla classe base. Puoi anche utilizzare le interfacce al posto di classi base, in questo modo potrai lavorare con più "derivazioni" o se ad esempio le classi già ereditano da altre classi. In ogni caso a quel punto il cast lo fai sulla classe base o sull'interfaccia e non sul tipo derivato, in quanto il tipo derivato lo dovresti conoscere in compilazione per poter fare il cast come intendi farlo tu. Da li nasce poi tutto il resto, tra cui anche sfruttare la reflection, ma soprattutto i Generics.

Sto derivando le classi e tentando di usare le generics. Capito bene questo è già un traguardo.

[U235]

Sto derivando le classi e tentando di usare le generics. Capito bene questo è già un traguardo.

Piano piano ci arriviamo... io credo di aver capito cosa cerchi di fare, ma tu ti dovresti impegnare a fare un esempio concreto. Ad esempio dovresti mettere le classi che usi come entità e cosa vorresti ottenere. Alle cose "difficili" ci arrivi per gradi, e vedrai che diventa tutto più chiaro.
Ad esempio potresti confermare (se è così) che a te interessa raggiungere, in maniera generica, proprietà comuni a tutti. Oppure ad esempio vorresti ricavare le proprietà del dbcontext (quindi articoli o ordini) per poi fare un toList(), e questo lo fai impostando dbcontext.set<T>().ToList(), dove T è il tipo della classe. Oppure tramite dbcontext.Set(articolo) (oppure Ordine), perché comunque chiaramente da qualche parte dovrai specificare cosa ti serve dal database, quindi la domanda si sposta per forza su cosa vuoi fare e dove lo vuoi fare.

Mi sembra che tu stia partendo da un qualche esempio che probabilmente cerchi di ricreare per comprenderlo, forse potrebbe essere utile, qualora sia così, farci conoscere l'esempio...

PS
Ad esempio potresti voler usare xamarin o wpf o avalonia ecc. e demandare al grafico che si occupa dello xaml il compito di richiedere arbitrariamente che tipo vuole ricavare da mettere in una ListView, ma senza che questa sia "predisposta" a priori da chi scrive il viewmodel, Quindi chiamando genericamente un membro comune a tutte le classi, ma lasciando specificare a lui quale con esattezza. In questo caso, come potrai notare, lo specificare il tipo avviene comunque, ma lo rimandi al grafico.

[jabjoint]

@jabjoint, perché hai più classi Articoli?

Oggetti non classi, ho sbagliato.

[optime]

quindi hai solo una classe Articoli?

[alka]

Piano piano ci arriviamo... io credo di aver capito cosa cerchi di fare [...]

Nonostante la tua spiegazione, che almeno usa termini corretti, mi sfugge completamente l'utilità di una simile implementazione e non vedo che tipo di semplificazione potrebbe portare.

Già si parla di "ereditare", che in genere è un imbrigliamento, soprattutto applicati a classi che vengono tendenzialmente generate a partire dal DB (se si fa reverse engineering) e quindi facilmente sovrascritte, per fare una implementazione basata su Reflection che è estremamente lento. Boh...

[optime]

@jabjoint, quindi hai solo una classe Articoli?