[ALG] waar conversie van objects naar xml in n-tier app?

[zoepercavia]

Ik ben bezig te kijken of ik zelf een framework voor een n-tier app kan schrijven, wat me aanzienlijk kan schelen voor volgende projecten. Ik ben bekend met Xml/Xsl en dat leek me uitstekend voor de GUI en de Gui Support Tier.
Daarnaast heb ik een klein ontwerpje gemaakt, ik zit alleen met de vraag waar de conversie van object naar xml moet (en weer terug). Moet die in de GUI Support of kan die ook in de Business Logic.

M.a.w. moet er een .toXML in de objecten of een functie om objecten naar xml om te zetten in de GUI Support?. Strict genomen zou ik namelijk denken dat het eigenlijk niet in de business logic tier hoort.

[mbravenboer]

Ik zou altijd proberen om de manier van data uitwisseling, remoting of hoe je het ook wilt noemen altijd zoveel mogelijk gescheiden te houden van de kern van de applicatie. Het is dus niet fraai om overal in de applicatie (in de domein objecten in dit geval) code op te nemen die uitgaat van een specifieke wijze van remoting, data uitwisseling of transport.

Zie ook:
[rml][ SOAP] Business logic in een SOAP server[/rml]

[zoepercavia]

Maar wat is dan een goede manier om objecten in xml om te zetten zonder dat in het object zelf te doen. Ik zou me namelijk geen functie voor kunnen stellen die generiek genoeg is om alle objecten automatisch naar xml om te zetten (objectToXML()) ofzo iets. In .Net zit XmlSerializer, maar of dat voor mijn doeleinden geschikt is kan ik moeilijk zeggen.
Het zou er denk ik toch op neer komen dat er vrij specifieke code moet geschreven worden voor elk object om het naar Xml om te zetten (je wilt ook niet altijd alles in je Xml).
Eén oplossing die ik me zo kan bedenken is om de domein klasse over te erven, naar een applicatie specifieke klasse die wel Xml kan brouwen.
bv. class Person in business logic layer
class XmlPerson : Person, IToXmlConvertable in GUI support layer.
Of blaat ik nu heel erg?

[mbravenboer]

zoepercavia: Maar wat is dan een goede manier om objecten in xml om te zetten zonder dat in het object zelf te doen.

Noem me 1 reden waarom je het wel in de klasse zelf zou kunnen doen en niet in een externe klasse?

De enige goede reden is private data, maar ik kan me maar weinig situaties voorstellen waarin je data wel wilt transporteren naar een client, maar niet zichtbaar wilt maken via accessors.

Ik zou me namelijk geen functie voor kunnen stellen die generiek genoeg is om alle objecten automatisch naar xml om te zetten (objectToXML()) ofzo iets. In .Net zit XmlSerializer, maar of dat voor mijn doeleinden geschikt is kan ik moeilijk zeggen.

Elke functie die generiek objecten naar XML omzet zal XML simpelweg misbruiken als object serializatie mechanisme. Dat is op zich niet zo'n heel groot probleem, maar dan moet je wel beseffen dat je niet meer pure data in XML formaat uitwisselt. Je creeert dan al snel een afhankelijkheid tussen de implementatie van de client en de server.

Het zou er denk ik toch op neer komen dat er vrij specifieke code moet geschreven worden voor elk object om het naar Xml om te zetten (je wilt ook niet altijd alles in je Xml).

Je kan met attributen voorkomen dat je specfieke code moet gaan schrijven. Met attributen kan je goed beschrijven hoe je een object wilt serializeren naar XML. Kijk dit artikel bijvoorbeeld eens door:
XML Data-Binding: Comparing Castor to .NET
Als data binding niet genoeg flexibiliteit biedt, kan je ook denken aan code generatie voor een wat specifiekere situatie dan willekeurige object structuren.

Eén oplossing die ik me zo kan bedenken is om de domein klasse over te erven, naar een applicatie specifieke klasse die wel Xml kan brouwen.

Dat is vies. Je breidt de klasse dan uitom niet de bestaande functionaliteit uit te breiden of aan te passen, maar om een totaal ander aspect toe te voegen. Het gevolg is bijvoorbeeld dat je met je uitbreiding nooit meer een andere Person kan serializeren (een andere subklasse van Person dus).

[whoami]

Het serializen van domain objects naar XML zou ik ook niet in het object zelf doen.

Maar, kan je niet mbhv reflection een generiek object/method maken die een object naar xml serialized?

[Alarmnummer]

Je zou het ook in de 'mapping' (eigelijk heet dat de datalayer) layer kunnen plaatsen. Je moet dan wel wat extra werk verrichten, maar je hebt wel meer controle. Eventueel zou je ook kunnen kijken naar een XML binding framework. Dus java erin, xml eruit, of andersom. Geen gedonder meer met generieke XML interfaces, maar gewoon specifieke informatie ophalen => compiletime veiligheid en makkelijker te programmeren.