[C#] Combineren Fields aan reeds gecreeerde object (runtime)

Hoi allemaal,

Na vele onderzoeken en het testen van allemaal zaken wil ik mijn topic start opnieuw gaan opbouwen. Ok, hier gaan we.

Op school zijn we momenteel bezig met het 5 lagen structuur:

Presentatielaag --> Controlclasslaag --> BusinessLaag --> Persistentielaag --> Database

Hierbij wil ik een standaard communicatie middel maken tussen de presentatielaag en de controlclasslaag. Hierbij wil ik de programmeur aanbieden dat via deze communicatie object list van string arrays, dictionary's of objecten aangemaakt kunnen worden waarmee deze op de presentatielaag gebruikt kunnen worden. Op het moment van terugsturen wil ik ook de mogelijkheid aanbieden dat vanuit de reeds genoemde list / dictionary's dat deze omgezet kunnen worden naar objecten zodat de businesslaag objecten krijgt aangeboden ipv allemaal losse strings e.d. Ik heb heel wat bereikt om het al zo te maken dat de programmeur dictionary's terug kan krijgen en list string arrays. Ik heb ook het al zover gekregen om deze informatie terug om te zetten naar een object.

Ik heb van de volgende onderdelen gebruik gemaakt:

Develop programma: Visual Studio 2008
Taal: C#
System classes:

• using System;
• using System.Data;
• using System.Collections;
• using System.Collections.Generic;
• using System.Configuration;
• using System.Linq;
• using System.Reflection;

Ok mijn probleem nu zoals eerder vermeld in de topicstart is dat ik eigenlijk objecten wil maken die je ook echt met properties kunt aanspreken. Alleen het probleem is dat via designtime geen properties e.d. aangesproken kunnen worden of ik zou het nieuwe object moeten interperen als object zijnde. (Inherentice) alleen dit was helaas ook niet helemaal gelukt. Ik heb IL commiting gebruikt en dat ging niet helemaal hoe ik het wou. Verder heb ik die keyvaluecollection (data dictionary) gebruikt om zo de objecten aan te maken. Alleen ik wil dus echt rechtstreekse properties gebruiken. Ik heb ook verschillende manieren geprobeerd om dit voor elkaar te krijgen alleen het wilt me niet lukken. Ik hoop dat we er samen uit kunnen komen. Ik zal even als voorbeeld mijn code hieronder plaatsen.

*snip*

Ik hoop dat we samen nogmaals dit kunnen uitvogelen. Ik zou het echt super op prijs stellen.

Creepy wijzigde dit bericht 17-07-2008 13:01 (182%)
Reden: code verwijderd...

Ik snap niet echt wat je probeert te doen, maar ik denk dat je Reflection wilt gebruiken?

quote:

Haan schreef op vrijdag 04 juli 2008 @ 16:08:
Ik snap niet echt wat je probeert te doen, maar ik denk dat je Reflection wilt gebruiken?

Heb even de topic start aangepast.

Mijn bedoeling is...

Als eerste wordt een object aangemaakt. Aan dit object wil ik dan fields koppelen tijdens het uitvoeren van het programma. Hoe moet ik dit aanpakken?

Wat voor 'fields'

Dat kan niet volgens mij. Sowieso, als je dit wil, zou ik nog eens goed naar het ontwerp van je programma gaan kijken...

Ik bedoel de fields waar alle info wordt opgeslagen. Zoals private int eengetal = 0; Zon soort van fields wil ik eigenlijk tijdens runtime koppelen. Ik vermoed dat dit wel mogelijk is en hopelijk (dacht ik)konden we dit samen misschien oplossen. Als het echt niet mogelijk is moet ik ook ergens lezen dat het niet mogelijk is .

IL emitting ?

Maareh, of je dat wilt.

Een andere optie is natuurlijk ook dat je je class een Dictionary member geeft, waarbij de key de naam van het veld is, en de value dan de waarde die dat veld moet krijgen.

whoami wijzigde dit bericht 04-07-2008 16:29 (67%)

whoami

IL Emetting heb ik iets ergens van gelezen maar zag hierin geen oplossing. Hoe werkt deze methode?

Hang een public KeyValueCollection aan je object en klaar is klara

quote:

IL Emetting heb ik iets ergens van gelezen maar zag hierin geen oplossing. Hoe werkt deze methode?

Lastig, en je moet er gedegen kennis van hebben of willen krijgen. Anders ga je het niet voor elkaar krijgen. IL emitting: Via code eimt je direct IL in je assembly. Normaal gesproken gaat C#-> IL (compilen). Runtime wordt dan de IL geinterpreteerd en uitgevoerd. Met IL emitting injecteer je IL in je gecompilede C#/VB code.

In principe kan je hiermee in je class een field toevoegen at runtime. Maar het maakt je code slecht leesbaar, is lastig te implementeren en maakt dus je code slecht onderhoudbaar. Een KeyValueCollection, zoals RobIII aangeeft is veel simpeler, makkelijker te begrijpen voor jezelf en andere developers en gemakkelijker onderhoudbaar te houden.

Ruudjah wijzigde dit bericht 06-07-2008 21:44 (4%)

De TS moet IMHO eerst maar aangeven waarom de velden niet at compiletime beschikbaar zijn, en dus at runtime moeten worden aangemaakt. Ik gok op het fenomeen 'custom tables/fields aangemaakt at runtime', klopt dat?

*Bump* voor nieuwe topic start

Beantwoord geljk even de vraag van EfBe ook

Verder geef je aan dat een aantal zaken "niet helemaal zijn gelukt". Wat lukte er dan wel en op welke manier heb je dat dan precies gedaan? Wat ging er mis? Kreeg je foutmelding etc?

Je post nu een enorme lap code met een behoorlijke open vraag. Blijkbaar heb je zelf al het 1 en ander geprobeerd maar je laat nu achterwege wat je nu precies hebt geprobeerd en wat er niet mee lukte. Los daarvan is het uiteindelijke doel van je oplossing voor een aantal personen onduidelijk. Wat wil je nu precies bereiken en waarom? Kan je een stuk concreter zijn? Ik heb je code weggehaald want zo'n hoeveelhheid voegt niet zoveel toe. Op het moment dat je wat concreter bent kan je zeer waarschijnlijk ook wat relevante code geven (dus niet alle code).

Creepy wijzigde dit bericht 17-07-2008 13:00 (13%)

Wat is er relevant aan het opsommen van die using statements ?

Verder ben ik ook benieuwd naar het antwoord op EfBe's vraag .... Dit is gewoon een clue naar de oplossing en waarschijnlijk riekt het naar een slecht ontwerp ...

Ok, mijn fout dat ik bepaalde zaken nog niet heb aangegeven. Mijn bedoeling hiervan is dat ik eigenlijk objecten kan aanmaken die je in de presetielaag kunt gebruiken. Hierbij is het zo dat properties aangesproken kunnen worden.

Ik wil eigenlijk dat het mogelijk is dat iedere business unit klasse ingeladen kan worden en de propeties hiervan geladen kunnen worden. Het is zo dat de presentatielaag niet de businesslaag kent dus ook niet de eigenschappen van alle klassen die daarin beschreven zijn. De presentatielaag kent echter wel de controlclass laag waarbij dus in de controlclass laag deze klasse die ik heb geschreven kan gebruiken voor het converteren. Dit betekent dus dat de velden en properties niet beschikbaar zijn in developtime (compile time) maar ze moeten wel @ runtime beschikbaar zijn. Hierbij ontstaan dan ook het probleem dat properties niet rechtstreeks in de presentatielaag aanspreekbaar zijn. Ik bedoel dan dit.

string test = object.GetName;

Dat is eigenlijk wat ik wil. Dus ik moet ook iets zien te verzinnen om de properties zover te krijgen dat ik die kan gebruiken in de presentatielaag. Als ik de vraag van EfBe antwoord is het ja inderdaad deze moeten aangemaakt worden tijdens runtime maar echter in develop time moet hij de eigenschappen kunnen lezen.

Ik heb geprobeerd om als je een type opgeeft dat hij inherentice hiervan maar dit is helaas niet gelukt (Ik bedoel op deze manier Converter<T> : NieuwsBericht bijvoorbeeld). Qwa dictionary (key value collection) werkte wel maar het is niet hetgene wat ik wou gebruiken. Ik kon dan op de volgende manier de informatie ophalen Object['GetName']; maar hierbij kon ik gewoon al van de eerst gemaakte code al gebruik maken. Het liefst wil ik gewoon het OOP principe ook in de presentatielaag behouden. Ik heb verder ook geprobeerd om IL emetting te gebruiken zodat fields / properties worden aangemaakt @ runtime alleen jammer genoeg kreeg ik dit niet aan de praat. Verder heb ik ook geprobeerd om aan het object de type op te slaan en dat deze dan via een property opgehaald worden zodat ik dan eventueel gebruik kan maken van de properties van het type en dit werkte ook helaas niet. Verder heb ik ook met andere mensen van mijn opleiding overlegd en zeiden dat ik misschien eerder gebruik moest gaan maken van generalisatie maar daar zag ik even het nut niet van in en hoe ik dit moest opvatten.

Ik hoop dat ik door deze post heel wat helderder maak wat eigenlijk mijn echte bedoeling is.

Even kort samengevat:

Velden en properties zijn niet beschikbaar in compiletime.
Velden en properties moeten aangemaakt worden @ runtime.
Velden en properties moeten de waarden dan aannemen die meegestuurd worden aan het object.
Properties moeten eigenlijk tijdens developtime (compiletime) aangesproken kunnen worden bij de presentatielaag.
Ik wil graag het OOP principe handhaven

En waarom zijn je properties, definities niet beschikbaar at design time ? Als ik het zo lees, dan mappen die objecten (presentatie-classes) gewoon naar je business class, dus weet je perfect hoe een 'customer' business object mapt naar een customer presentatie-object ?

Der bestaan trouwens tools waarmee je je business classes kunt mappen naar presentation layer objects, maar de naam ervan ontsnapt me even.

Het is zo dat de businessclasses de presentatieclasses (user interface e.d.) niet van elkaar afweten. Dit zou dan via de controlclasses moeten lopen. Ik zou dan eventueel een link moeten leggen naar de businessclasses in de presentatielaag maar qwa principe zou dit niet mogen...

Je control class kan de zaken via de business laag de zaken binnenhalen en weer aan de presentatielaag doorgeven in de door de presentatielaag gewenste classes? Omdat de controller beide kanten kent lijtk het me niet nodig om @runtime een class te gaan definieren met de juiste methodes en properties en die daarna door te geven aan de presentatie laag.

quote:

Creegfire schreef op vrijdag 18 juli 2008 @ 10:53:
Het is zo dat de businessclasses de presentatieclasses (user interface e.d.) niet van elkaar afweten. Dit zou dan via de controlclasses moeten lopen.

Dat hoeven ze toch ook niet ? Je presentatie-objecten hoeven niet in dezelfde assembly te zitten als je business classes.

Het liefste zou ik dit via objecten willen doen dus dat de businesslaag naar de controlclass laag stuurt die gooit ff alles om voor de presentatielaag zodat deze laag het kan gebruiken. Als de presentatielaag kan dan ook weer deze objecten terugsturen naar de controlclass laag en die laag kent ze dan toe aan de businesslaag waar ze toe behoren dat is mijn bedoeling. Het oop principe handhaven. Daarom wil ik ook een nieuw object maken die eigenlijk totaal onafhankelijk is op de presentatielaag gebruikt kan worden zonder de businessunit laag vanaf te weten.

quote:

Het liefste zou ik dit via objecten willen doen dus dat de businesslaag naar de controlclass laag stuurt die gooit ff alles om voor de presentatielaag zodat deze laag het kan gebruiken. Als de presentatielaag kan dan ook weer deze objecten terugsturen naar de controlclass laag en die laag kent ze dan toe aan de businesslaag waar ze toe behoren dat is mijn bedoeling. Het oop principe handhaven. Daarom wil ik ook een nieuw object maken die eigenlijk totaal onafhankelijk is op de presentatielaag gebruikt kan worden zonder de businessunit laag vanaf te weten.

De denkfout die je hier maakt is dat de presentatie en logicalaag (jij noemt het de controllayer) niet de definities van de objecten (classes) mag weten. In de datalaag specificeer je een class Klant met de velden Naam en Adres. Dat wil je misschien valideren in je controle klassen. Het is prima design als je controle laag van de definities af weet. Dan kan je dus zeggen
C#:

bool ControleerPostcode(Klant k)

, die intern een methode heeft bool
C#:

PostcodeLengte(Klant K)

. Ook de UI weet van de definities af, in de UI heb je dan bijvoorbeeld code als
C#:

Klant k=new Klant();
txtKlantNaam.DataBindings.Add(New Binding("Text", k, "Naam"));

Uiteindelijk drukt de user op de Opslaan knop. Dan stuur je de Klant instantie k naar de controlclass, die verder dingen ermee doet zoals validatie en persisteren naar de datalaag.

Of wilde je in je data, ui en logicalaag alleen met objecten werken, dus instanties van het type Object?

Ruudjah wijzigde dit bericht 18-07-2008 14:24 (3%)

Mijn bedoeling hierbij is dat je dus gewoon nieuwe reeds aangemaakte objecten wil gebruiken om de communicatie tussen de userinterface en de controlclass layer te voorzien. Hierbij mag dus niet de userinterface afweten van de dataclasses (businessclasses) afweten want anders gaat het in strijd met de layers . Je moet het dus zo zien:

UI --> CC --> BU --> DAL --> DB

Er is in principe maar één weg die bewandeld kan worden. Het is natuurlijk vreemd als je gegevens gaat ophalen of terugsturen want dan gaat het de andere weg op. Hiervoor kan ik ook niet direct de verklaring voor geven waarom ze dit zo op school hebben verteld , maar anyway de UI mag dus zoals eerder gezegd niet afweten van de BU. Alleen de CC weet af van de UI en weet af van de BU. Het ziet er wel echter na uit dat ik wel op deze manier moet gaan werken zoals jij net zei dat de UI ook van de BU komt af te weten... en verkracht ik dus hierbij echte principe van de layers

quote:

Creegfire schreef op woensdag 23 juli 2008 @ 18:04:
Mijn bedoeling hierbij is dat je dus gewoon nieuwe reeds aangemaakte objecten wil gebruiken om de communicatie tussen de userinterface en de controlclass layer te voorzien. Hierbij mag dus niet de userinterface afweten van de dataclasses (businessclasses) afweten want anders gaat het in strijd met de layers . Je moet het dus zo zien:

Dataclasses zijn niet hetzelfde als business classes.

Dus, jij wilt extra complexiteit introduceren (wat meer ontwikkeltijd kost en lastiger te onderhouden is), gewoon om jouw geweten mbt die layers te sussen ?

Trouwens, waarom mag je UI geen weet hebben van je business classes ? Je user interface is toch geschreven om het 'domein' (== business classes) aan de gebruiker te kunnen voorstellen zodat hij deze gegevens kan zien en onderhouden. Waarom zou je dan de UI daar zo van loskoppelen ?
Hoe ga je dan die gegevens aan je user tonen ? Ga je er nog een extra soort objecten tussenfrommelen of ga je gewoon alles met primitieve datatypes gaan tonen. (Dat laatste is handig ).

quote:

en verkracht ik dus hierbij echte principe van de layers

Nee, dat doe je niet.
Een layer is geen 'opzichzelf staand stuk' van een applicatie die geen weet mag hebben van andere lagen ....

Dus eigenlijk in officiele termen gezegd is dus eigenlijk best bull**** wat ze op school vertellen rondom dat layers elkaar niet mogen kennen? Hmmm nu wordt het zeker interessant . Heb je misschien een bevestiging ergens op internet of een bron waar dit in staat? Want dan kan ik dit namelijk ook op school aantonen . Het is gewoon een stuk makkelijker en meer logischer als je rechtstreeks de objecten van de business classes kunt aanspreken (types). Ik wou dus hierbij eigenlijk inderdaad een nieuw type er tussen maken waarmee eigenlijk hetzelfde gebeurd.

Als geen enkele layer 'weet heeft' van een andere layer, hoe kan je dan een applicatie maken die uit verschillende layers bestaat ? Ik bedoel: op de een of andere manier moeten die layers toch met elkaar communiceren ?
Op de een of andere manier zal er altijd een communicatie zijn tussen layers, echter, die communicatie gaat niet in 2 richtingen:
Je UI layer heeft bv weet van je business classes, maar, je business classes mogen geen kennis hebben van de UI. Je BL staat los van je UI en hoeft niet te weten of er nu winforms, webforms, ASP.NET MVC, command line interface, ... gebruikt wordt als UI.
Je BL hoeft ook niet te weten wat je gebruikt als data-storage. Is dat een text-file, is dat een DBMS, welk DBMS het is, ... hoeft niet gekend te zijn. Echter, je data-laag zal dan wel weer weet moeten hebben van je business objecten, want je data-laag moet die business objecten in kunnen saven.