Objects + Acties en Lagen + Acties

[Verwijderd]

Stel ik heb een applicatie met de volgende lagen:

User Interface
Proceslaag
Business Logicalaag
Datalaag


In de Business Logiclaag zitten mijn businessobjects, bijvoorbeeld: dossier. Een dossier kan aangemaakt worden, verstuurd worden, behandeld worden etc.

C#:

+==========
| DOSSIER
|-------------
| CreateDate
| Creator
| Titel
| ...
|-------------
| + MaakAan()
| + Verstuur()
| + Behandel()
| ...
+=========+

Dit object komt via de proceslaag uit bij de UI, alwaar informatie uit het object op het scherm wordt getoond.

Als ik vanaf de UI een dossier wil aanmaken, moet ik dat via de proceslaag doen, zodat de proceslaag bijvoorbeeld kan controleren of de gebruiker de juiste rechten heeft. De Proceslaag roept vervolgens de juiste acties op het object aan.


Nu het probleem:
Omdat de UI de beschikking heeft over mijn object kan hij zonder tussenkomst van de Proceslaag acties uitvoeren met de objecten. Dit is niet de bedoeling.

Ik zit er dus over te denken om dan maar 'domme berichten' te gaan versturen vanuit de Business Logicalaag. Dat betekent wat mij betreft dat een Dossier wel de relevante properties heeft, maar geen enkele method meer.

Klinkt simpel eigenlijk. Dit zou dus al een gebruikelijke manier van werken kunnen zijn? Zie ik wat over het hoofd?

[wibra]

je zou bijvoorbeeld je processlaag nieuwe Objecten kunnen laten doorsturen naar GUI, met enkel de attributen die noodzakelijk zijn voor weergave. De GUI kan dan enkel aan deze (niet persistente) objecten, maar kan er wel acties op uitvoeren. Aan de hand van een gemeenschappelijke ID tussen het UI-object en het Business-Object kan je processlaag dan een vertaalslag uitvoeren.

[Flard]

Op zich is een proceslaag op zich wel gevaarlijk, aangezien een aantal dingen meestal ook direct van Business Layer afhangen. (Zo zitten users e.d. ook gewoon in je Business Layer denk ik)...

Is het wellicht geen oplossing om met behulp van Attributes (ik zie namelijk dat je C# als taal opgeeft bij je codeblock...) een model te maken, waarmee je kunt verifiëren of iemand de benodigde rechten heeft?

Een andere mogelijkheid is wellicht een vlag in je Business-Object te zetten, wat een zogenaamd 'schrijfrecht' is. Voordat er data gemanipuleerd worden moet dus eerst die vlag staan, en die vlag kan dan bijvoorbeeld gezet worden door de proceslaag.
(Of wellicht in combinatie met Attributes)

[Antediluvian]

Zoek eens naar het "Data Transfer Objects" of "Value Objects" pattern.

[LoekD]

Je idee is prima!
Als je in de proceslaag een overerving gebruikt/maakt van Dossier, waarin de methods worden toegevoegd, dan kan je de ('=dom bericht') gemeenschappelijke base definitie (met alleen de properties) aanbieden aan de 'buitenwereld'.

Sommigen gaan nog iets verder en bieden alleen een public IDossier (interface definitie, wederom alleen de properties) aan de buitenwereld, zodat er ook geen instanties kunnen worden aangemaakt door mensen die je niet kent. (internal constructor / factory)

[seamus21]

Wat je wilt doen is via het MVC model werken. Model View Controller. Waarbij Model de datalaag is, View de UI en de Controller in jou geval de proceslaag. Eigenlijk is de UI alleen maar de representatie van je data. Je UI zou alleen maar de waarde van de properties in je dataobject hoeven te laten zien. Controles en andere acties laat je het controllerobject doen. De UI heeft dus alleen maar toegang tot het dataobject.

[JHS]

seamus21: Over het algemeen heeft binnen het MVC model het V gedeelte alleen toegang tot door de controller beschikbaar gemaakte variabelen - wat op zich instanties van dataobjection (models) kunnen zijn. Het probleem is echter dat je zou willen kunnen afdwingen dat de view de models niet kan aanpassen, en al helemaal niet een method als save kunnen aanroepen. Daarvoor zijn methodes zoals Data Transfer Objects en andere hierboven gegeven oplossingen .

Volgens mij heeft de topicstarter overigens uitstekend begrepen hoe hij z'n applicatie in lagen op wil splitsen, en heeft hij de controller verder opgesplitst in een business logica en proceslaag.