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

quote:

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?

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:

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#:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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#:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

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#:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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!

HawVer wijzigde dit bericht 25-07-2008 09:45 (9%)

quote:

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

Hydra wijzigde dit bericht 25-07-2008 14:32 (4%)

Wat ik bijzonder vind:

quote:

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.