[C#] Producten actualiseren met webserver

[Verwijderd]

Hoi mensen,

Ik ben bezig met het schrijven van een Windows applicatie bedoeld voor o.a. fotografen om hun klanten zelf makkelijk foto's en andere producten te laten bestellen.
Nu moet het mogelijk zijn voor de fotografen om de applicatie te beheren via een website (PHP).

Alle communicatie tussen de Windows applicatie en de website handel ik af met XMLRPC.

Ik heb 1 class met alle data die ik opgeslagen wil hebben wanneer de applicatie sluit zodat deze data de volgende keer dat de applicatie start weer beschikbaar is. Dit object sla ik bij sluiten geserialized op in een bestand die ik bij het opstarten weer deserialize. Ik vraag me af of dit een verstandige keuze van mij is geweest gezien wanneer er wat verandert in de structuur van 1 van de geserializde classes er fouten optreden.

Wanneer een klant inlogt in de Windows applicatie, zal de Windows applicatie alle instellingen en producten vanaf de website ophalen. De website houdt bij wie, wanneer voor het laatst in heeft gelogd en zal er vanuit gaan dat alle producten die niet gewijzigd zijn nadat er voor het laatste in is gelogd, nog recent in de applicatie staan gezien de producten geserialized opgeslagen worden. Maar zodra er dus iets fout is gegaan bij het serializen / deserializen van de data loopt alles dus in de soep.

Tips zijn dus van harte welkom!

[gorgi_19]

* gorgi_19 is eigenlijk wel benieuwd naar het feitelijke probleem?

[Verwijderd]

gorgi_19 schreef op woensdag 10 september 2008 @ 15:07:
* gorgi_19 is eigenlijk wel benieuwd naar het feitelijke probleem?

Het probleem is dat alles in de soep blijft lopen op deze manier en dat ik op het punt sta het deel te herschrijven wat verantwoordelijk is voor het opslaan van de huidige producten en instelling (wat momenteel dus via serialize/deserialize af wordt gehandeld).

Dit topic is dus bedoeld voor mensen die mij kunnen vertellen of serialize inderdaad geen goede opossing is en zonee wat wel een goede oplossing zou zijn.

[sig69]

Het kan wel, maar zodra je wat properties gaat toevoegen of veranderen aan je classes gaat het niet meer goed (zoals je gemerkt hebt). Je kan mi drie dingen doen:
• Custom serialization implementeren
• Als je properties toevoegd die je niet per se nodig hebt zo je het OptionField attribute kunnen toepassen
• Een ander manier van opslaan gaan gebruiken
Wat de beste oplossing voor jou is laat ik in het midden

[Verwijderd]

Wat is nu precies de bedoeling? Dat de fotograaf de applicatie beheert vanaf de website en dat klanten producten via de applicatie bestellen? Moet dit niet andersom zijn?

(Ik kan het ook niet begrepen hebben natuurlijk )

Als de structuur van de business laag zo vaak kan veranderen, zoals je zelf ook al aangeeft, kun je misschien beter voor een andere opzet kiezen waarbij een database gebruikt die alleen vanaf één punt beheerd gaat worden (ofwel vanaf de applicatie, ofwel vanaf de website). Vervolgens kan er dan met behulp van remote procedure calls (dus net zoiets als stubs in JAVA als ik me niet vergis, lang geleden) vanuit het andere punt (ofwel vanaf de website, ofwel vanaf de applicatie) data in de database bewerkt worden.

Daarnaast: Moet de applicatie bij de klanten zelf gaan draaien? Hoe ga je dan instellingen vanaf de website (die neem ik aan ergens anders draait) versturen naar de applicatie(s) die bij de klant(en) draaien?

[ Voor 14% gewijzigd door Verwijderd op 16-09-2008 14:32 ]

[Hydra]

IMHO is serializen / deserializen van classes absoluut geen mechanisme bedoeld voor persistente storage. IMHO is het zaak een eigen data access layer te creeren, of een bestaand iets als Hibernate te gebruiken.

[j.meijers]

De handigste oplossing lijkt mij dat je een interface implementeert die ervoor zorgt dat het object uitwisselbaar is, deze noemen we even IExchangeable. De interface voorziet in de functie CreateExchangeMessage van het type ExchangeMessage.

Een ExchangeMessage is dan vervolgens een object met een aantal key/value combinaties met bij elk key/value pair eventueel nog een type-aanduiding (text, integer, double, binary, etc). Tevens heeft dit object een versienummer. Dit versienummer is je protocolversie.

Nu maak je een object Exchanger die daadwerkelijk berichten van het type ExchangeMessage kan uitwisselen. Deze heeft dus een functie 'Exchange(ExchangeMessage msg)'. Deze functie doet het volgende:

- Bepaal de protocolversie
- Bepaal of de protocolversie bekend is, of dat de versie deprecated (< MIN_PROTOCOL_VERSION) of unknown (> MAX_PROTOCOL_VERSION) is (en gooi dus een ArgumentException of iets dergelijks)
- Verstuur het bericht met de functie SendMessageWithProtocolVersion1() (en SendMessageWithProtocolVersion2() voor versie 2 etc)
- Het versturen maakt een XML bestand met een structuur waarvan in elk geval de eerste paar regels NOOIT veranderen. Deze zijn bijvoorbeeld <exchangemessage version='x'> waarbij je dus met x de protocolversie aangeeft. Hiermee kun je dus bij het ontvangen weer bepalen welke versie je moet parsen!

Aan de andere kant maak je dan gebruik van de functie 'ReceiveMessage(ExchangeMessage msg)' met dezelfde opbouw, dus voor verschillende protocolversies.

Op deze manier bereik je:

- backward compatibility voor zover als jij wilt (te bepalen met MIN_PROTOCOL_VERSION)
- onafhankelijkheid van de classdefinitie (immers, je verstuurt alleen XML en niet de serialize data)
- een makkelijk te onderhouden applicatie

Mocht je hier eens meer over willen spreken kun je me eventueel even mailen.

[Creepy]

Mocht je hier eens meer over willen spreken kun je me eventueel even mailen.

Ja leuk, daar heeft de rest van de community hier wat aan
Post het AUB hier op het forum, voor iedereen een stuk interresanter.

[j.meijers]

Creepy schreef op donderdag 06 november 2008 @ 11:36:
[...]

Ja leuk, daar heeft de rest van de community hier wat aan
Post het AUB hier op het forum, voor iedereen een stuk interresanter.

Nee daar heeft de rest niets aan. Maar heeft de rest er wat aan als wij zeer diep ingaan op zijn applicatie? En: wil hij dat zelf wel? Als hij zijn vraag hier stelt dan ga ik er heus ook wel op in hoor

[RobIII]

j.meijers schreef op donderdag 06 november 2008 @ 13:38:
[...]


Nee daar heeft de rest niets aan. Maar heeft de rest er wat aan als wij zeer diep ingaan op zijn applicatie? En: wil hij dat zelf wel? Als hij zijn vraag hier stelt dan ga ik er heus ook wel op in hoor

"Mail me" is in principe gewoon niet de bedoeling hier. Als iedereen met elkaar ging zitten mailen waren we geen forum maar een contact-marktplaats geweest

En als je zeer diep in gaat op zijn applicatie (wat overigens niet eens per sé zou hoeven, je kan het ook globaal uitleggen) is dat alleen maar mooi. Mensen die ooit via een zoekopdracht op dit topic stuiten kunnen dan ook iets leren ervan (hoe zo'n besluit tot stand kwam om X of Y te gebruiken en waarom Z afviel enz.). Wel zo sociaal

[ Voor 23% gewijzigd door RobIII op 06-11-2008 13:57 ]

[j.meijers]

Allereerst wil ik even stellen dat het niet mijn bedoeling is om hier mensen te contacteren. Ik wilde gewoon uitleggen hoe de oplossing in elkaar steekt en volgens mij doe ik dat ook in mijn post, alleen in globale termen. Ik denk dat veel anderen hier al iets aan zouden kunnen hebben, aangezien het een redelijk generieke oplossing betreft.

Dus ik zal even mijn laatste zin anders formuleren: als je (of iemand anders) over dit topic nog vragen hebt, schroom niet om ze te posten.

Verder is het topic al wat ouder dus ik denk dat hij al een oplossing heeft. Desalniettemin leek het mij een nuttige aanvulling. Zoals ik al zei: mijn bedoeling is om een oplossing aan te bieden, niet om hem mij te laten mailen, dat had ik dus anders kunnen formuleren. Ik krijg namelijk al genoeg mails en telefoontjes etc. op een dag