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

[Creegfire]

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.

[ Voor 182% gewijzigd door Creepy op 17-07-2008 13:01 . Reden: code verwijderd... ]

[Haan]

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

[Creegfire]

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?

[kenneth]

Wat voor 'fields'

[sig69]

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

[Creegfire]

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 .

[whoami]

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.

[ Voor 67% gewijzigd door whoami op 04-07-2008 16:29 ]

[Creegfire]

whoami

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

[RobIII]

Hang een public KeyValueCollection aan je object en klaar is klara

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 100% gewijzigd door Ruudjah op 02-12-2009 00:16 ]

[EfBe]

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?

[Creegfire]

*Bump* voor nieuwe topic start

[Creepy]

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).

[ Voor 13% gewijzigd door Creepy op 17-07-2008 13:00 ]

[whoami]

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 ...

[Creegfire]

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

[whoami]

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.

[Creegfire]

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...

[Creepy]

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.

[whoami]

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.

[Creegfire]

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.

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 101% gewijzigd door Ruudjah op 02-12-2009 00:16 ]

[Creegfire]

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

[whoami]

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 ).

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 ....

[Creegfire]

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.

[whoami]

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.

[Creegfire]

whoami schreef op woensdag 23 juli 2008 @ 21:43:
Je UI layer heeft bv weet van je business classes, maar, je business classes mogen geen kennis hebben van de UI.

Spreek je hier dan niet over 3 lagen systeem?

[HawVer]

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:

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

Een centrale controller class die de afhandeling van de communicatie verzorgt is op zich een prima concept. Het is alleen belangrijk dat je het niet zo ver doordrijft dat het concept niet meer te implementeren is of het ononderhoudbare code oplevert.
Het idee van layers is dat je de verschillende lagen verschillende verantwoordelijkheden geeft. Daarbij mag de ui nog best weten wat voor objecten hij op het scherm moet tonen.

Een goede toepassen van meerdere lagen is het toepassen van klantspecifiek maatwerk. Als klant B bijvoorbeeld een extra export wil draaien na het opslaan van zijn data kun je een overerving maken van je model. De ui hoef je dan niet aan te passen. Het enige wat belangrijk is is dat je controller weet dat hij niet het standaard model moet toepassen maar de overerving daarvan.

Hierbij een sterk vereenvoudigd voorbeeld van de meerdere lagen.

Controller:

C#:

   public class Controller
   {
      private Model model;
      private View view;

      internal Form Execute()
      {         
         model = new Model();
         view = new View();

         view.Data = model.Data;

         view.Save += new EventHandler(model.SaveData);
         return view;
      }
   }

UI:

C#:

   public partial class View : Form
   {
      private DataObject data;

      public DataObject Data
      {
         get { return data; }
         set { data = value; }
      }

      public event EventHandler Save;

      public View()
      {
         InitializeComponent();
      }

      private void button1_Click(object sender, EventArgs e)
      {
         Save(this, new EventArgs());
         // Refresh data here
      }
   }

Businesslaag (model)

C#:

   public class Model
   {
      private DataObject data;

      public DataObject Data
      {
         get { return data; }
         set { data = value; }
      }

      public void SaveData(object sender, EventArgs e)
      {
         data.CustomerName = "NewName";
      }
   }

De UI hoeft geen methode aan te roepen op de business laag maar vuurt een event af. De controller bepaalt welk instantie van het model dit event zal afhandelen. Zo hoeft de UI niet op de hoogte te zijn van het model en het model niet op de hoogte te zijn van de UI. Het afschermen van de verschillende lagen is helemaal niet zo moeilijk. Het belangrijkste is dat je het jezelf niet te moeilijk maakt.

Wees niet teveel gefocust op mooie modellen zonder een praktische toepassing te hebben!

[ Voor 9% gewijzigd door HawVer op 25-07-2008 09:45 ]

[Hydra]

HawVer schreef op vrijdag 25 juli 2008 @ 09:42:
Hierbij een sterk vereenvoudigd voorbeeld van de meerdere lagen.

Controller:
[code=c#]
public class Controller
{
private Model model;
private View view;

[...]

Het MVC model is sowieso geen 'lagen' systeem waarbij de lagen 'fysiek' gescheiden zijn. Het model krijgt updates vanuit de controller en signaleert dmv events als er iets gewijzigd is, de view vangt wijzigingssignalen op en past de view aan, en de controller laag vang interactie op en voert wijzigingen uit. M.a.w. 'kennen' die lagen elkaar.

Onder de model laag zit dan weer een DAL en een DB waar de view en controller geen weet van hebben, maar dat is andere koek en valt ook onder het 'model' deel.

Edit:
zo iets dus

[ Voor 4% gewijzigd door Hydra op 25-07-2008 14:32 ]

[wasigh]

Wat ik bijzonder vind:

Creegfire schreef op vrijdag 18 juli 2008 @ 09:16:
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.

Je geeft hier aan dat je in je presentatielaag een property aan wilt kunnen roepen @ runtime. Maar ondertussen geef je een voorbeeld van hoe je het aan zou roepen @compile time. Hier zit volgens mij een onoverkoombare tegenstelling.

Als je nu methodes op je op dataobjecten @runtime wilt aanroepen zonder dat je de objecten @compile time kent kun je dat natuurlijk doen door gebruikt te maken van interfaces of van reflectie en custom attributes.