Multiplatform programmeertaal

[BryanD]

Beste tweakers,

Ik heb een bepaald project in mijn hoofd zitten die ik graag wil uit werken.
Echter heb ik hier een vraagje over. Ik wil graag een CMS ontwikkelen (webdevelopment (wrs. PHP en SQL)). Dit lukt mij wel geen probleem. Nu wil ik echter een programma schrijven voor desktops, dus Windows, Linux en Mac. Echter heb ik daar een paar eisen aan:

- Het moet kunnen communiceren met een webserver (lighttpd, apache maar ook een SQL Server (mySql etc. etc.))
- Moet een GUI ondersteunen
- Multi-Platform

Zitten verder geen eisen aan. Maar ik wil het wel graag leren, het gaat me er niet om dat ik direct binnen 10 minuten een compleet programma uitpoep wat zo goed is dat ik morgen miljonair ben, maar ik wil wel graag weten op welke taal ik mij moet gaan focusen..

heeft iemand aanraaders?
Ik heb al wat talen voorbij zien komen op verschillende andere fora, maar wat terug blijft komen is Java, is dat de betere taal om te gebruiken, of kan ik beter een C o.i.d gebruiken?

B.v.d,

[Brilsmurfffje]

met welke talen heb je zelf al ervaring ?

[Keiichi]

Java is wel het makkelijkste op crossplatform the programmeren. In C/C++ is het opzich ook wel te doen, maar kunnen nog wat haken en ogen aanzitten.

Waar je ook naar kunt kijken is het .NET platform. Met mono onder linux is hier ook een aardig crossplatform iets aan vast te breien.

[BryanD]

Zelf heb ik met echter programeer talen (desktop) alleen maar C++ ervaring (niet al te veel btw). Echter voor het web e.d. JavaScript (begin ik nu net vrij goed te begrijpen), PHP, SQL, en ik ben op het moment ASP.NET aan het leren (VB).

Dat is het verder nog wel, maar ik wil wel graag verder met leren, ik vind het namelijk wel super tof, en ook desktop programming wil ik leren, vandaar deze vraag

P.S. Iedereen nog een gelukkig nieuwjaar!

[ymoona]

Je zou kunnen kijken naar c# op .net. Dit is inprincipe windows only. Maar met mono kom je echt heel ver onder OSX (inclusief GUI). Mono is ook beschikbaar voor Linux, maar daar heb ik alleen commandline ervaring mee. Voor zover ik weet zit zon beetje heel 2.0 ook in mono.

btw, de mysql connector en log4net werken ook prima onder mono. Kan je in ieder geval bij de database communiceren en logfiles maken.

[ Voor 20% gewijzigd door ymoona op 01-01-2011 22:02 ]

[reddevil001]

Actionscript (Adobe Air) is eigenlijk Flash als desktop applicatie.

[Avalaxy]

reddevil001 schreef op zaterdag 01 januari 2011 @ 22:01:
Actionscript (Adobe Air) is eigenlijk Flash als desktop applicatie.

Dat moet je niet willen

Gewoon lekker Java, is het makkelijkst imho Zeker als je van PHP af komt is dat in mijn ogen de makkelijkste taal om te leren.

[BryanD]

Dank voor de snelle antwoorden heren.
@ymoona: Oke, echter zou ik het graag zo zien dat men geen mono hoeft te instaleren om mijn programma te draaien. Ik ben zelf alleen nog maar windows gewend, dus ik weet niet hoeveel OSX gebruikers of *NIX gebruikers bekend zijn met het principe Mono en hoevaak dat gebruikt word, maar het liefst zou ik gewoon één programma willen hebben wat ik gemaakt heb zonder dat het een compatibility programma werkt.

@reddevil001: AIR is niet bepaald de optie waar ik naar kijken wil, is mij te zwaar en ik ben afhankelijk van de instalatie van AIR op de desbetreffende PC/MAC

@Avalaxy: Java zeg jij dus, oke, heb er al een beetje van gezien en ziet er inderdaad een beetje uit als PHP/C++ (basiskennis C++ he, dus geavanceerd kan ik niet zeggen)

[ Voor 12% gewijzigd door BryanD op 01-01-2011 22:06 ]

[Boudewijn]

Dan is Java of bijvoorbeeld Python prima te doen.

[RaZ]

Er is nog geen multi-platform programmeer taal wat native ondersteund wordt voor Windows, Mac & *nix.

Ook met Java moet een Windows gebruiker nog Java installeren. (Of dat op Mac & 8nix zo is, weet ik niet).

Je zal de eind-gebruiker dus eigenlijk altijd moeten lastig vallen met het installeren van andere zaken. Of je moet echt voor elk platform een andere applicatie schrijven.

[ Voor 6% gewijzigd door RaZ op 01-01-2011 22:09 ]

[FTL]

Avalaxy schreef op zaterdag 01 januari 2011 @ 22:03:
[...]


Dat moet je niet willen

Gewoon lekker Java, is het makkelijkst imho Zeker als je van PHP af komt is dat in mijn ogen de makkelijkste taal om te leren.

Java is alleen extreem zwak op desktop UI niveau kan ik zeggen uit ervaring.
Je hebt natuurlijk Swing en AWT maar je zal snel veel missen.

[FTL]

Een oplossing zou C, C++ met GTK of QT kunnen zijn.

[BryanD]

@boudewijn: Java of Python, zeg jij dus. Oke, ik ben helemaal niet bekend met Python maar dat maakt het des-te leuker.

@RaZ: Hmm, ik vind dat die er komen moet , maar goed, java hebben de meeste mensen al wel geinstaleerd, python ben ik niet zo zeker over, en mono weet ik helemaal niets van af...

EDIT:

@FTL: C, C++. Maar zou je ook kunnen uitleggen waarom java met GUI zwak is (wat is overigens de definitie van zwak in deze context?)

[ Voor 19% gewijzigd door BryanD op 01-01-2011 22:13 ]

[Boudewijn]

RaZ schreef op zaterdag 01 januari 2011 @ 22:08:
Er is nog geen multi-platform programmeer taal wat native ondersteund wordt voor Windows, Mac & *nix.

Ook met Java moet een Windows gebruiker nog Java installeren. (Of dat op Mac & 8nix zo is, weet ik niet).

Je zal de eind-gebruiker dus eigenlijk altijd moeten lastig vallen met het installeren van andere zaken. Of je moet echt voor elk platform een andere applicatie schrijven.

In het geval van java kun je er vanuit gaan dat het meestal wel geinstalleerd is.
Dit alleen al vanwege allerlei spelletjes en dergelijke.


OS X heeft het standaard volgens apple:

Every version of Mac OS X comes with Java out of the box. No download, installation, or setup is necessary to run applications, view Applets, or even build your own Java code from the command line. New Java releases are made easily available through Software Update, and developer packages can be found at the Java Downloads page.

Linux users weten wel hoe het moet en met ubuntu enzo is dat ook geen echt issue.

FTL schreef op zaterdag 01 januari 2011 @ 22:10:
[...]


Java is alleen extreem zwak op desktop UI niveau kan ik zeggen uit ervaring.
Je hebt natuurlijk Swing en AWT maar je zal snel veel missen.

Zoals? Imo zonder onderbouwing een redelijk loze kreet. Tools zoals Eclipse of Netbeans zou ik niet 1-2-3 grafisch zwak willen noemen.

[Avalaxy]

FTL schreef op zaterdag 01 januari 2011 @ 22:10:
[...]


Java is alleen extreem zwak op desktop UI niveau kan ik zeggen uit ervaring.
Je hebt natuurlijk Swing en AWT maar je zal snel veel missen.

Ik vind Swing niet fijn om mee te werken, maar vertel? Wat zou het niet kunnen wat hij (waarschijnlijk) nodig heeft?

Overigens zie ik hier meerdere keren C en C++, maar dat is nog een stuk complexer dan Java of C#, dus ik zou gewoon daarmee beginnen.

[ Voor 15% gewijzigd door Avalaxy op 01-01-2011 22:20 ]

[Verwijderd]

C++, met Qt voor je GUI

[Erwinvz1]

XUL een optie?
https://developer.mozilla.org/En/XUL

[Verwijderd]

OS X heeft het standaard volgens apple:

nieuws: Apple stopt met ontwikkeling OS X-versie Java

Kortom hier stoppen ze mee.

Linux users weten wel hoe het moet en met ubuntu enzo is dat ook geen echt issue.

Raar argument, linux users weten ook hoe ze mono moeten intstalleren netzoals dat windows gebruikers zelf ook wel java kunnen installeren.

[Verwijderd]

Waarom niet Adobe Air? Voldoet aan al je eisen, aangezien je daar gehele html, javascript e.d. (en dus ajax etc.) apps in kunt laten draaien. Het is platform onafhankelijk, je hoeft geen nieuwe taal naast php te leren om het te ontwikkelen en de GUI kan volledig uit html/css/javascript opgebouwd worden. Daarbij is een webapp (wat een Adobe Air applicatie in theorie is) het voorbeeld van een multi-platform, of platform onafhankelijke applicatie.

Adobe Air is GEEN flash, meer een soort wrapper waarin je html, javascript en actionscript kunt draaien, waarmee je dus prima kunt communiceren met een LAMP omgeving o.i.d.

[ Voor 12% gewijzigd door Verwijderd op 01-01-2011 22:34 ]

[FragFrog]

BryanD schreef op zaterdag 01 januari 2011 @ 21:49:
maar ook een SQL Server (mySql etc. etc.))

Je wilt dat elke gebruiker direct met je database kan praten? Weet je dit wel heel zeker?

Als ik jou was zou ik eens kijken naar iets van een webservice als backend van je applicatie. Daar kun je vrij simpel met PHP + HTML een webbased frontend aan bakken en het mooie is dat je diezelfde backend ook gelijk kan gebruiken voor niet alleen een GUI app in JAVA, maar ook prima voor bijvoorbeeld eenzelfde app in C++ of C# mocht je dat later willen. Je krijgt dan iets als dit:

code:

 [Browser]         [Desktop]
     |                 |
 PHP & HTML]    [JAVA / C# GUI]
     |                 |
     -------------------
              |
         [Webservice]
           |      |
    [Database]  [Webserver etc]

Op deze manier kun je simpel en centraal low-level functionaliteit aanpassen en makkelijk meerdere frontends gebruiken. Ideaal als je later ook nog een keer een iPad app ervoor wilt maken bijvoorbeeld. Waar je de webservice in maakt is min of meer aan jezelf: deze hoeft immers niet cross-platform te zijn, dus dat kan prima in C#, Python, PHP, JAVA, etc.

Overigens zit er ook een nadeel aan deze manier van werken: de extra laag tussen je data en je frontend kan vertragend werken. Helaas eens in de praktijk gezien met een JAVA service die ruim drie seconden nodig had om een SOAP request op te bouwen (ok, 't was wel een request van 700Kb, maar toch). Vreemd genoeg ging het parsen aan de PHP frontend kant wel weer in een fractie van een seconde.. Maargoed, daar zul je niet heel snel tegenaanlopen

Verwijderd schreef op zaterdag 01 januari 2011 @ 22:30:
nieuws: Apple stopt met ontwikkeling OS X-versie Java

Kortom hier stoppen ze mee.

Nee, dat doen ze niet

[ Voor 11% gewijzigd door FragFrog op 01-01-2011 22:39 ]

[_Erikje_]

Verwijderd schreef op zaterdag 01 januari 2011 @ 22:30:
[...]


nieuws: Apple stopt met ontwikkeling OS X-versie Java

Kortom hier stoppen ze mee.

Oracle and Apple Announce OpenJDK Project for Mac OS X

AHUM, ze zijn er juist mee bezig.

java is prima voor GUI desktop applicaties.

[Caelorum]

ymoona schreef op zaterdag 01 januari 2011 @ 21:59:
Je zou kunnen kijken naar c# op .net. Dit is inprincipe windows only. Maar met mono kom je echt heel ver onder OSX (inclusief GUI). Mono is ook beschikbaar voor Linux, maar daar heb ik alleen commandline ervaring mee. Voor zover ik weet zit zon beetje heel 2.0 ook in mono.

btw, de mysql connector en log4net werken ook prima onder mono. Kan je in ieder geval bij de database communiceren en logfiles maken.

C#, mono en GTK# werkt ook wel lekker, imo. Overigens is mono tot .net 4.0 wel redelijk compleet, als je bij een paar probleem gevallen uit de buurt blijft
Je kan ipv GTK# ook qt4dotnet gebruiken.

BryanD schreef op zaterdag 01 januari 2011 @ 22:05:
Dank voor de snelle antwoorden heren.
@ymoona: Oke, echter zou ik het graag zo zien dat men geen mono hoeft te instaleren om mijn programma te draaien. Ik ben zelf alleen nog maar windows gewend, dus ik weet niet hoeveel OSX gebruikers of *NIX gebruikers bekend zijn met het principe Mono en hoevaak dat gebruikt word, maar het liefst zou ik gewoon één programma willen hebben wat ik gemaakt heb zonder dat het een compatibility programma werkt.

Tja... Met een goede installer (repo op *NIX) valt er weinig lastig te vallen.

[BryanD]

@FragFrog, precies wat ik zoek zo'n model, Dat is precies het model wat ik voor ogen heb. Een dekstop program die in het principe precies hetzelfde doet als de browser van een client. Alleen dan zonder browser.
@Erwinvz1, Dat ziet er wel geinig uit, ik zal er eens een keer naar kijken, maar ik denk niet dat het is wat ik graag wil, aangezien ik graag ook in non-gecko browsers (*kuch*IE*kuch*) het wil laten werken.
@shadow, congrats En jij zegt C++ dus.
@gitkua, Ik wil juist een nieuwe programeer taal leren, ik wil niet zo 1,2,3 een programma bouwen, ik wil het al lerend van een nieuwe programeer taal doen.

Bedankt voor de snelle berichten mensen!

[Sebazzz]

Ik zou zelf voor C++ met QT of WxWidgets gaan. Je leert er enorm veel van, maar de complexiteit van C++ valt nog wel mee, zolang je maar goed op je pointers let.

Java is een optie, maar er gelden dezelfde nadelen die je bij C# ook zou hebben. Uiteindelijk maakt het niet uit, ken je C# zal je de overstap naar Java kunnen maken (waarschijnlijk met wat meer moeite) en vanaf Java kan je makkelijk op C# overstappen. Een taal leren is geen permanente keus.

[BryanD]

@Sebazzz, dat is waar, kan altijd meerdere talen leren.

Maar met alle post's op deze thread zit ik nu te twijfelen tussen Java en 1 van de 3 C's (C,C++ of C#)
C# wou ik zowieso voor ASP.NET nog leren dus tja

[RaZ]

Als je desktop app hetzelfde moet doen als de webapp, moet je dus een webservice maken ook. Je wil echt niet dat users direct je database kunnen aanspreken. Want als je iets veranderd, moet je ook de desktop apps updaten, anders gaat er riant wat fout.

Dus je hebt er nog een taak bij, het schrijven van een webservice.

[BryanD]

Naja kijk wat ik wil is het volgende:

Men moet in het CMS gewoon pagina's kunnen aanpassen, foto's upload etc. doen wat je in een CMS doet.

Echter in het tijdperk van nu, waarin mensen smartphones hebben, tablets steeds populairder groeien. En dus wil ik (in eerste instantie) een desktop app schrijven wat eigenlijks gewoon het CMS is, alleen dan offline.

Men maakt dus connectie met de server, en vervolgens logt men in, en past men de gegevens in de DB aan. Vervolgens word alles gewoon weer opnieuw opgehaald (nieuw verzoek versturen = nieuwe content ophalen).

Ik hoop dat dat het wat duidelijker maakt...

[Boudewijn]

En hoe ga je er dan voor zorgen dat de data in je DB enigzins blijft kloppen? Dit klinkt alsof het heel makkelijk wordt om in je DB te gaan rotzooien.

[RaZ]

Het is mij prima duidelijk. Alleen als jij je wachtwoorden in de app hebt zitten, kan men dus bij je database, en alles verwijderen.

Je kan dus ook gewoon een goeie frontend maken die op smartphones er ook goed uitziet.

Want je kan namelijk als je desktop-app met de database kan praten, alles sniffen. Denk dat je na je launch van je app direct de inhoud van je CMS kwijt bent.

Je moet het aanpassen van data altijd server-side houden, anders heb je nergens de controle meer. Dat wil je niet, echt niet.

[BryanD]

En hoe wou je dat dan doen met die desktop app?
Ik bedoel, hoe moet ik dat voor mij zien?

Is het een soort van programma wat je opstart die connectie legt met mijn server, die vervolgens connectie legt met de database? En dat er vervolgens data uit de database terug gestuurd word die dan client side aangepast word en vervolgens via de server terug naar de DB gestuurd word? want zo had ik het in mijn hoofd, en als ik jou nou goed begrijp gaat dat niet werken i.v.m. security.

Hoe zou je dit dan moeten oplossen?

[dragontje124]

nou een heel simpel voorbeeld is dat je desktop app bij bijvoorbeeld het aanmaken van een nieuwe pagina
een POST request doet naar een php pagina, dit php script gooit dan alles in de DB
let hierbij op dat je ook in het php script nog moet checken of iemand wel de juiste rechten heeft om dingen te doen, want dat php script is gewoon publiekelijk opvraagbaar

[ Voor 31% gewijzigd door dragontje124 op 02-01-2011 00:06 ]

[Boudewijn]

BryanD schreef op zaterdag 01 januari 2011 @ 23:20:
En hoe wou je dat dan doen met die desktop app?
Ik bedoel, hoe moet ik dat voor mij zien?

Is het een soort van programma wat je opstart die connectie legt met mijn server, die vervolgens connectie legt met de database? En dat er vervolgens data uit de database terug gestuurd word die dan client side aangepast word en vervolgens via de server terug naar de DB gestuurd word? want zo had ik het in mijn hoofd, en als ik jou nou goed begrijp gaat dat niet werken i.v.m. security.

Hoe zou je dit dan moeten oplossen?

Maarruh zijn wij nu jouw software architectuur aan het maken?

[Verwijderd]

Je desktop app rechtstreeks met de DB laten connecten is wel een 'no-go' IMHO. De DB alleen op de localhost (of server cluster / lokale IP range) toegankelijk maken... Ik heb ooit wel eens een desktop app gemaakt die inderdaad met de PHP applicatie dmv. curl communiceerde. Inderdaad met HTTP Post requests dus. Rechten inderdaad in de PHP app checken maar dat heb je toch sowieso als iemand inlogt op de back-end van het CMS?

[ Voor 25% gewijzigd door Verwijderd op 02-01-2011 00:49 ]

[ErikKo]

Na het lezen van dit topic gaat mijn aanrader naar een fatsoenlijke frontend.
De desktop app die zogenaamd "offline" moet werken, moet toch online gaan om gegevens op te halen van het CMS. Kun je net zo makkelijk de webinterface gebruiken. En webinterfaces zijn prima te optimaliseren voor smartphones, tablets, etc.

Ik zie de toegevoegde waarde niet in een standalone desktop app.

[ Voor 4% gewijzigd door ErikKo op 02-01-2011 02:17 ]

[Boudewijn]

Lokale rekenkracht, efficientere (?) caching, interface opties?

Maar dat lijkt $TS niet te hebben .

[ Voor 24% gewijzigd door Boudewijn op 02-01-2011 02:23 ]

[bloody]

Voor TS (en ook voor de mensen die vinden dat java zwak is in desktop GUI development): kijk eens naar de Eclipse RCP (rich client platform) en de combinatie JFace/SWT.

Links:
Wikipedia: Standard Widget Toolkit
Wikipedia: JFace

Bekijk ook de screencast op http://www.eclipsezone.com/eps/10minute-rcp/ eens

[YopY]

Lichtelijk offtopic, een CMS met een clientisde backend (om het zo maar eens te noemen) is niet eens zo'n heel gek idee, als je ziet hoe traag / zwaar de (webbased) backend van het cms dat we nu gebruiken is ;D. Props voor de TS hiervoor, mits goed uitgewerkt.

En hoe wou je dat dan doen met die desktop app?
Ik bedoel, hoe moet ik dat voor mij zien?

Is het een soort van programma wat je opstart die connectie legt met mijn server, die vervolgens connectie legt met de database?

Ja, zo moet je dat zien. Eenvoudig voorbeeld, je hebt een paar admin scripts op je website (evt. PHP, maar kan in elke server-side taal als je wilt) die bepaalde acties ondernemen - pagina's ophalen, opslaan, etc. In je client applicatie roep je die pagina's / 'services' aan met wat authenticatie. Dus dan heb je een client-applicatie die een URL aanroept met GET of POST-parameters (afhankelijk van de actie, ophalen of opslaan / wijzigen van gegevens).

[BryanD]

@YopY, maar ja zoals eerder al gezegt, client side back-end kan toch een enorm veiligheids risico zijn? (thnx voor de props )

En verder had ik het ook zo in mijn hoofd zoals mijn voorbeeld, ik denk dat ik een paar van jullie wat bang heb gemaakt door een slecht geformuleerde post.
Maar wat ik dus bedoel is een app die connectie legt met een server waar dan scripts op draaien die connectie maken met een MySQL server o.i.d.

[Janoz]

Wat bedoel je met "client side back-end"? Daar kan ik me even geen voorstelling van maken.

[RobertMe]

Ik neem aan dat hij bedoeld dat het aanmaken van pagina's, wijzigen van pagina's etc. via een applicatie gebeurt, en niet via de browser.

Overigens zou ik ook gaan voor C++ met Qt.

Een oplossing met POSTs uitvoeren naar de webapplicatie lijkt me wel 3 keer niks, ik zou of voor een webservice gaan, of voor rechtstreeks met de database connecten maar de tabellen afschermen doormiddel van views & procedures, op die manier kun je wel per user (groep) regelen wie welke actie op de database kan doen. Zo kun je ook alle logica in de database plaatsen, wat je dubbel ontwikkelen scheelt (in plaats van een keer in PHP en een keer in de "applicatie taal" hoeft het dan alleen in de database)

[BryanD]

@Janoz, het wijzigen van de data gebeurt dan client side en het word terug naar de server gestuurd

@RobertMe, Wat bedoel je met webservice, ik zie de term vaker voorbij komen maar ik snap niet echt wat je er mee bedoelt.

[Janoz]

Dat zal best kunnen hoor, maar ik heb afgeleerd om dingen zomaar aan te nemen. Bij back-end denk ik persoonlijk altijd aan de tiers die achter de presentatie-laag komen (business en data layer).


Verder zou ik niet voor de SP aproach gaan. Business logic implementeren in de database zelf is iets dat je eigenlijk alleen nog maar ziet bij de old school DBA-ers. Ook je '2x logica implementeren' argument snijdt geen hout. Wanneer je je webservices ook via php laat lopen (webservices zijn niet veel anders dan http requests met een wat strakker ingericht formaat voor request en response wat vervolgens in een wsdl is vastgelegd) kun je gewoon dezelfde code gebruiken. Je hebt dus exact dezelfde opstelling, alleen is de businesslogic geimplementeerd in php ipv SP's. Vervolgens heeft dit weer als extra voordeel dat je alleen een webserver hoeft te exposen. Je hoeft dus niet je DB voor de hele wereld toegankelijk te maken en je hebt ook nog het voordeel dat je geen geneuzel met firewalls en proxies krijgt.

[Janoz]

BryanD schreef op maandag 03 januari 2011 @ 14:55:
@Janoz, het wijzigen van de data gebeurt dan client side en het word terug naar de server gestuurd

Hmm, daar was ik al bang voor. Dat is een beetje raar. Nu lijkt het net alsof je je database gaat downloaden naar de client, aanpassen en vervolgens weer in zijn geheel uploaden. Dat is een beetje een vreemde manier.

Het lijkt mij veel logischer op de client inderdaad te editen, maar vervolgens de nieuwe waarde naar de server te sturen die het vervolgens in de database aanpast.

[BryanD]

Zoiets had ik mij ook in gedachten inderdaad janoz, echter jouw post voor je laatste is nog wat moeielijk als ik het zo even door lees, ik zal er thuis nog even wat meer aandacht aan besteden, maar wat ik er van begrijp is het volgende:

- Programma word opgestard
- Er word een verbinding gelegt met de server (HTTPRequest)
- De client verstuurt een opdracht (inloggen, get content etc.)
- Server doet wat hem verteld word en legt evt. connectie met de DB.
- DB poept gegevens uit en de server stuurt die terug naar de client.
- Client doet lekker zijn ding en stuurt op een gegeven moment de data (gemodificeerd) weer terug.
- Server stuurt het door naar de DB en de DB slaat het op.

Iets in die trand?

[Janoz]

De post daarvoor was meer een reactie op RobertMe. (SP staat voor stored procedure, dat is logica die in de database zelf geimplementeerd is).

Mbt je stappen lijstje: Ja, maar dan zonder stap 2. Er is niet een lopende verbinding oid. Elke actie is gewoon een los request. Een request kan inderdaad inhouden dat je 1 (of meerdere) items opvraagt, wijzigt of toevoegt. Je zult wel zelf wat dingen bij moeten gaan houden mbt het ingelogd zijn en blijven, maar daarvoor zijn vaak standaard oplossingen (afhankelijk van de gebruikte client taal en server oplossing).

[ZpAz]

_Erikje_ schreef op zaterdag 01 januari 2011 @ 22:44:
java is prima voor GUI desktop applicaties.

Onder Windows misschien, onder OSX is het _eigenlijk altijd_ een vreemde eend in de bijt. De applicatie voelt nooit native aan. En ja, als er als voorbeelden aan wordt gedraafd als 'netbeans of eclipse' dan bevestig je enkel mijn punt.

Cross platform apps voelen altijd op bepaalde platformen niet native aan. Tenzij je voor elk platform apart de GUI gaat maken.

[ Voor 32% gewijzigd door ZpAz op 03-01-2011 16:22 ]

[Sebazzz]

Wat dat betreft komt C++ met WxWidgets of C# met Mono nog het dichtst in de buurt. WxWidgets wrapped om de Windows API heen of op Linux om GTK heen, hetzelfde met Mono.

[bloody]

ZpAz schreef op maandag 03 januari 2011 @ 16:20:
[...]


Onder Windows misschien, onder OSX is het _eigenlijk altijd_ een vreemde eend in de bijt. De applicatie voelt nooit native aan. En ja, als er als voorbeelden aan wordt gedraafd als 'netbeans of eclipse' dan bevestig je enkel mijn punt.

Aha, weer eentje die zo te zien nog niet naar SWT gekeken heeft

[YopY]

BryanD schreef op maandag 03 januari 2011 @ 14:06:
@YopY, maar ja zoals eerder al gezegt, client side back-end kan toch een enorm veiligheids risico zijn? (thnx voor de props )

Hoezo? Je zult natuurlijk wat beveiliging in moeten bouwen (gebruikersauthenticatie per request, evt. encrypten van de requests dmv HTTPS als het over HTTP gaat), maar anders zie ik niet wat daar het veiligheidsrisico van is. Je browser maat immers ook verbinding met die backend? Effectief hetzelfde, alleen ipv HTML krijg je een ander formaat gegevens terug, en ipv een browser heb je je client applicatie.

Vergelijk het bijvoorbeeld ook met API's van bijvoorbeeld Twitter of Hyves, daarmee kun je een website dingen laten doen op die sites. Effectief wordt je eigen site dan een client applicatie van die sites.

Maar misschien heb je er een ander beeld bij.

@Janoz, het wijzigen van de data gebeurt dan client side en het word terug naar de server gestuurd

Ja, dat gebeurt ook in een browser. Die stuurt de te wijzigen data naar je browser (die het in een formulierveld toont) en stuurt het na bewerken weer terug.

En je lijstje klopt ongeveer wel. Je zou je nog kunnen verdiepen in web services, remote procedure calls, SOAP, etc.

[Verwijderd]

Je zou ook eventueel kunnen kijken naar het Titanium Framework. Dit biedt de optie om een sandbox webkitbrowser aan te leveren voor bijna elk platform. Zo doende hoef je alleen maar in PHP/JS te programmeren en de rest door het Titanium Framework af te laten handelen.

[Zoijar]

Ik zou ook voor C++ met Qt gaan. Qt is veel meer dan een GUI. Zo heb je bijvoorbeeld (qt)webkit support. Daar kan je al je web taken mee doen, je kan er zelfs javascript mee uitvoeren etc. Je kan ook ruwe network requsts doen etc. Dan heb je ook meteen database support voor mysql/odbc/postgresql. Het werkt erg makkelijk en het is erg simpel crossplatform met qmake.

[farlane]

Janoz schreef op maandag 03 januari 2011 @ 15:00:Je hoeft dus niet je DB voor de hele wereld toegankelijk te maken en je hebt ook nog het voordeel dat je geen geneuzel met firewalls en proxies krijgt.

is het echt zo dat tegenwoordig alle db access van dat soort applicaties via webservices gaat? Of is dit weer zo'n hype waar iedereen aan mee moet doen? Waarom is het eigenlijk zo slecht om je db toegankelijk te maken? De db heeft toch ook zijn veiligheidsmaatregelen? Waarom is het via een webservice veiliger? Wat doet het met de performance van je applicatie?

* farlane vraagt het zich af

[ZpAz]

bloody schreef op maandag 03 januari 2011 @ 16:27:
[...]


Aha, weer eentje die zo te zien nog niet naar SWT gekeken heeft

Leuke Mac OS 10.3 look inderdaad, een beetje outdated

Dit is hoe osx apps er uit moeten zien

Ik kan me geen enkele java app voor de geest halen waarvan ik zeg _wow_ onder OSX

[ Voor 22% gewijzigd door ZpAz op 03-01-2011 22:23 ]

[Sebazzz]

bloody schreef op maandag 03 januari 2011 @ 16:27:
[...]


Aha, weer eentje die zo te zien nog niet naar SWT gekeken heeft

Helaas zit SWT niet in de Java base libraries en moet je dus per platform een andere jar meeleveren met de SWT toolkit.

[Ramon]

Wat ik echter mis in dit hele topic is het waarom van het willen van een desktop app.... ? Wat mist de topicstarter aan zijn web app wat je wel met een desktop app zou kunnen?

[Gomez12]

Ramon schreef op maandag 03 januari 2011 @ 22:34:
Wat ik echter mis in dit hele topic is het waarom van het willen van een desktop app.... ? Wat mist de topicstarter aan zijn web app wat je wel met een desktop app zou kunnen?

Ach, ik zie er wel een hoop voordelen in hoor. Het hele GUI-stuk zit op desktopnivo nog steeds wat meer op elkaar afgestemd dan op webnivo.

Simpel voorbeeldje is bijv om met 1 knopje 2 foto's gelijk in je verhaal te kunnen inserten, je kan gaan zitten klooien met java/flash dingetjes voor multiple uploads maar dat past veelal weer niet direct in een toolbar. En zo blijf je alles customizen en aanpassen aan webkant. Het is wel te doen, maar het vereist veel handwerk en op desktop nivo werken dat soort dingen gewoon al.
Snelheid is een 2e, als je met foto's etc werkt dan wil je veelal niet 5 sec wachten op een upload om dan te zien dat het plaatje verkeerd is en net iets aangepast moet worden. Nee, je wilt gewoon alles snel/flitsend klaarzetten en dan mag het overzetten wel weer wat langer duren.

Maar alhoewel ik zeker wel voordelen zie aan een desktop app zou ik er nooit aan gaan beginnen. Om de heel simpele reden dat ik er juist overal vandaan bij wil kunnen en dan heb ik een redelijk uitgebreid webkant nodig. En dan zit je dus alles 2x te bouwen.
Webservices / business logica gaat je niet magischerwijs een Rich Text Editor geven. Dat moet je gewoon ook nog een keer aan de webkant gaan bouwen.

[RaZ]

farlane schreef op maandag 03 januari 2011 @ 21:41:
[...]


is het echt zo dat tegenwoordig alle db access van dat soort applicaties via webservices gaat? Of is dit weer zo'n hype waar iedereen aan mee moet doen? Waarom is het eigenlijk zo slecht om je db toegankelijk te maken? De db heeft toch ook zijn veiligheidsmaatregelen? Waarom is het via een webservice veiliger? Wat doet het met de performance van je applicatie?

* farlane vraagt het zich af

Omdat de username en wachtwoord van de database over de lijn gaat. De login om alles met een database te doen dus heel eenvoudig (met 1x connecten) uit te lezen is.

De eerste met een applicatie kan die hele database dus naar wens aanpassen, kopieren, of gewoon wissen.

Zelfde als je aan je sleutelbos je adres hebt hangen. Dan kan je wachten dat je huis leeg gehaald wordt.

Werk je met een webservice (waar dus alle controle plaats vindt), gebeurt dat niet. Vergelijk het op GoT. Als alle users ineens mod-rechten hebben, wordt het 1 grote chaos.

[ZaZ]

RaZ schreef op dinsdag 04 januari 2011 @ 00:24:
[...]

Omdat de username en wachtwoord van de database over de lijn gaat. De login om alles met een database te doen dus heel eenvoudig (met 1x connecten) uit te lezen is.

De eerste met een applicatie kan die hele database dus naar wens aanpassen, kopieren, of gewoon wissen.

Zelfde als je aan je sleutelbos je adres hebt hangen. Dan kan je wachten dat je huis leeg gehaald wordt.

Werk je met een webservice (waar dus alle controle plaats vindt), gebeurt dat niet. Vergelijk het op GoT. Als alle users ineens mod-rechten hebben, wordt het 1 grote chaos.

Gaat natuurlijk niet per definitie op. Je moet je ook aanmelden bij je service en dat zou dan in dit verhaaltje net zo goed onderschept kunnen worden waarna full access.
En voordat je komt met "maar beveiligde verbinding etc." Dat kan ook natuurlijk met een rechtstreekse verbinding.

[RaZ]

Klopt. Alleen ik wilde het even in zeg maar jip-en-janneke taal verduidelijken. Als termen als webservice niet begrepen worden, vond ik dit een mooi voorbeeld.

[Hooiopdevork]

Misschien is "Real basic" iets voor jou: http://www.realsoftware.com/realstudio/

[Bigs]

Een multiplatform desktop applicatie voelt volgens mij nooit meer native dan een web app, maar als je het toch graag wil zou ik C++/Qt aanraden. Qt is een volwassen platform met aardige developer tools. Of het in dit geval geschikter is dan Java durf ik niet te zeggen, maar volgens mij is Mac OS X het enige OS dat standaard met Java wordt geleverd.

[BryanD]

een hoop reacties, met veel advies, ik dank u allen.
Ik ga er denk ik nog even over nadenken hoe ik dit zou gaan aanpakken en of ik dat zou doen. Ik blijf het topic in de gaten houden, dus voel je vrij om verder te discussieren. Nogmaals bedankt voor de feedback en de hulp!

[YopY]

Ramon schreef op maandag 03 januari 2011 @ 22:34:
Wat ik echter mis in dit hele topic is het waarom van het willen van een desktop app.... ? Wat mist de topicstarter aan zijn web app wat je wel met een desktop app zou kunnen?

Zelf zou ik snoeiharde performance als argument noemen. Werk dagelijks in een nogal duur CMS, en het is zwaar irritant als je voor elke muisklik een paar seconden moet wachten. Het is een nogal euh, 'feature-rich' backend, om het zo maar te noemen, . Je kunt natuurlijk zeggen dat ze dat maar moeten gaan versnellen, maar dan boet je weer in aan features. Zelfs een snelle website - zoals tweakers.net - doet nog sowieso een seconde per klik aan totale verwerkingstijd, in de snelste browser, op een 100 mbit lijn, en dat is niet eens een heel erg complexe site aan de gebruikerskant. Zelfde verhaal met Gmail, al is dat nog vlotter met het openen van emails.

Nu hoeft een desktop applicatie niet per sé sneller te zijn natuurlijk, . Maar in theorie kan het sneller gemaakt worden dan een webapp.

Bovenstaand is puur speculatief, imho, en niet representatief voor wie dan ook.

[farlane]

RaZ schreef op dinsdag 04 januari 2011 @ 00:24:
Omdat de username en wachtwoord van de database over de lijn gaat. De login om alles met een database te doen dus heel eenvoudig (met 1x connecten) uit te lezen is.

De eerste met een applicatie kan die hele database dus naar wens aanpassen, kopieren, of gewoon wissen.

Zelfde als je aan je sleutelbos je adres hebt hangen. Dan kan je wachten dat je huis leeg gehaald wordt.

Werk je met een webservice (waar dus alle controle plaats vindt), gebeurt dat niet. Vergelijk het op GoT. Als alle users ineens mod-rechten hebben, wordt het 1 grote chaos.

De punten die jij noemt gaan net zo hard op voor een webservice, als ik de goede login te pakken heb kan ik ook alles.
Ihgv een directe verbinding moet je natuurlijk ook zorgen voor een secure verhaal.

RaZ schreef op dinsdag 04 januari 2011 @ 01:22:
Klopt. Alleen ik wilde het even in zeg maar jip-en-janneke taal verduidelijken. Als termen als webservice niet begrepen worden, vond ik dit een mooi voorbeeld.

Ja dank je voor je jip-en-janneke taal, ik begreep ook al niet wat een webservice is.

[Woy]

farlane schreef op maandag 03 januari 2011 @ 21:41:
[...]


is het echt zo dat tegenwoordig alle db access van dat soort applicaties via webservices gaat? Of is dit weer zo'n hype waar iedereen aan mee moet doen? Waarom is het eigenlijk zo slecht om je db toegankelijk te maken? De db heeft toch ook zijn veiligheidsmaatregelen? Waarom is het via een webservice veiliger? Wat doet het met de performance van je applicatie?

* farlane vraagt het zich af

Het voordeel van een web-service is dat je veel meer controle hebt over wat er daadwerkelijk gebeurt, en dat je bovendien flexibeler bent als er in de toekomst iets in de structuur van de database veranderd, of zelfs een andere database gekozen word.

Natuurlijk kun je ook op database nivo best veel regelen wat betreft wel en niet mag, maar het is IMHO niet handig om uitgebreide checks in je database te doen. Bij een CMS zul je per item willen controleren of de betreffende user daar wel rechten op heeft. Die rechten check kun je niet eenvoudig in je database doen aangezien dat een stukje logica van je applicatie is, en je dus niet eenvoudig op een hele tabel wel/niet rechten kunt uitdelen ( Het kan natuurlijk wel in een SP, maar dan ga je je complete logica in de database leggen ). De check wil je natuurlijk al helemaal niet in je client applicatie doen, dus dan is een web-service een logische oplossing.

[ Voor 4% gewijzigd door Woy op 04-01-2011 11:15 ]

[farlane]

Woy schreef op dinsdag 04 januari 2011 @ 11:14:
Het kan natuurlijk wel in een SP, maar dan ga je je complete logica in de database leggen.

Wat is dan het grote nadeel van het hebben van die logica in bv een SP ipv van in een webservice? Dat maakt toch eigenlijk geen reet uit?

Het enige wat ik me zou kunnen bedenken dat je in een SP taal minder mogelijkheden zou hebben, maar dat is toch redelijk achterhaald inmiddels?

[Janoz]

farlane schreef op dinsdag 04 januari 2011 @ 09:38:
De punten die jij noemt gaan net zo hard op voor een webservice, als ik de goede login te pakken heb kan ik ook alles.
Ihgv een directe verbinding moet je natuurlijk ook zorgen voor een secure verhaal.

Een webservice kun je precies die functionaliteit laten implementeren die je wilt ontsluiten en verder niks. Dat is in principe ook met een database mogelijk, maar dan moet je je volledige business logic die je normaal in je webservice zou implementeren in een stored procedure implementeren. Daar zou je voor kunnen kiezen, maar dan nog is er een groot verschil.

Wanneer je vanaf de client rechtstreeks met een database server verbindt zul je die database toegankelijk
Dat zou allemaal nog kunnen, maar dan blijft staan dat je je database zelf toegankelijk moet maken van buitenaf. Je kunt de user dan wel zo dichtbouwen dat deze alleen bepaalde stored procedures aan mag roepen, maar feit blijft wel dat er database verbindingen van buitenaf opgezet kunnen worden. Er hoeft maar een keer een config foutje gemaakt te worden (met de user, maar ook een willekeurige andere user!) of een exploit beschikbaar zijn en men heeft toegang tot je database. En aangezien je zelf nog het tunnelen moet regelen om een secure verbinding te krijgen (is niet heel standaard bij database connecties)..

Webservices daarentegen draaien bovenop http. Dit protocol is van de grond af aan bedoeld om vanaf overal aangeroepen te worden en heeft dan ook legio ondersteuning voor authenticatie en authorisatie (sessie gebaseerde serverside code, maar ook http specifiek als BASIC, NTLM, Digest of middels certificaten. Uiteraard de zo goed als standaard aanwezige https niet te vergeten) . Ook is security 1 van de kernpunten. Voor systeembeheerders is het inrichten van een veilige webserver over het algemeen a walk in the park. Verder zorgt een exploit in je webserver of in je code er alleen voor dat je webserver compromised is, en nog niet dat je hele database open ligt.

En tot slot hebben we dan natuurlijk nog de gebruikers. Zeker wanneer je thuis zit is er geen enkel probleem om een verbinding te maken op een willekeurige poort naar een willekeurige server, maar dat is lang niet overal zo. Zeker in kantooromgevingen is dat vaak een stuk lastiger vanwege proxies en firewalls die ook beperkingen op uitgaand verkeer leggen. Het aanmaken van een https verbinding is in die omgevingen vaak een stuk makkelijker dan het opzetten van een ssh tunnel.

Rechtstreeks met de database verbinden zou ik persoonlijk alleen maar doen in een kleinschalige intranet omgeving, maar zelfs daar lang niet altijd. Vaak heb je al code die bepaalde usecases ontsluit (omdat je bijvoorbeeld je gegevens ook middels een webapp/site ontsluit) of zit dit er aan te komen omdat uberhaupt de behoefte bestaat om de gegevens extern te gaan ontsluiten. Het toevoegen van een webservice laag op die code is dan een stuk minder werk dan je business logic nog een keer implementeren.

Ja dank je voor je jip-en-janneke taal, ik begreep ook al niet wat een webservice is.

Voor de TS was het een niet zo bekende term.

farlane schreef op dinsdag 04 januari 2011 @ 11:31:
Het enige wat ik me zou kunnen bedenken dat je in een SP taal minder mogelijkheden zou hebben, maar dat is toch redelijk achterhaald inmiddels?

Je business logic implementeren in SP is juist eerder hetgeen achterhaald is. Er zijn nog wel DBA-ers die standvastig vast blijven houden, maar over het algemeen is dat een gepasseerd station.

[ Voor 6% gewijzigd door Janoz op 04-01-2011 11:39 ]

[Cartman!]

farlane schreef op dinsdag 04 januari 2011 @ 09:38:
[...]

De punten die jij noemt gaan net zo hard op voor een webservice, als ik de goede login te pakken heb kan ik ook alles.
Ihgv een directe verbinding moet je natuurlijk ook zorgen voor een secure verhaal.

Als je systeem nog mutaties bijhoudt kun je gewoon reverten bijvoorbeeld of anders gewoon de ene login disabled die gelogged is. Als jij een (semi-)root password voor je database in je requests meestuurt is het gewoon wachten totdat iemand al je tables dropt. Met een webservice ben je veel flexibeler en is het onderhoud veel simpeler imo.

[Woy]

Cartman! schreef op dinsdag 04 januari 2011 @ 11:51:
[...]

Als je systeem nog mutaties bijhoudt kun je gewoon reverten bijvoorbeeld of anders gewoon de ene login disabled die gelogged is. Als jij een (semi-)root password voor je database in je requests meestuurt is het gewoon wachten totdat iemand al je tables dropt. Met een webservice ben je veel flexibeler en is het onderhoud veel simpeler imo.

Je kunt op een DB natuurlijk ook gewoon meer users aanmaken, met verschillende rechten. Maar Janoz legt al mooi het voordeel van een web-service uit.

Buiten dat is het gewoon fijn om niet al je logica in je database te hoeven stoppen. SQL is en blijft een set based taal, terwijl veel logica juist meer procedureel gericht is. Natuurlijk kun je met T-SQL ook dat soort logica wel maken, maar IMHO kun je beter een taal/platform gebruiken wat er ook daadwerkelijk voor ontwikkeld is. De data ophalen/opslaan laat je lekker aan de database over, en de logica aan bijvoorbeeld een web-service.

[Avalaxy]

farlane schreef op dinsdag 04 januari 2011 @ 11:31:
[...]

Wat is dan het grote nadeel van het hebben van die logica in bv een SP ipv van in een webservice? Dat maakt toch eigenlijk geen reet uit?

Dat je doorgaans alle data uit de database wilt halen zoals het ooit is opgeslagen zodat je de data op verschillende manieren kunt bewerken indien nodig. Als je al logica in je database stopt heb je niet meer de originele data (of je moet het dubbel op gaan slaan).

[Sh4wn]

Als ik voor multiplatform app zou gaan, zou ik ook voor Python gaan, ik heb C++/Qt ook wel eens gebruikt, maar in Python is het heel veel simpeler, en samen met py2exe kan je ook windows executables maken zonder dat je eindgebruiker python geinstalleerd hoeft te hebben. En op OSX/Linux zit python er al standaard in.

Python is echt een simpele taal, met uitgebreide standaard library die een heleboel werk uit handen neemt, en er zijn ook Qt bindings voor Python.

[farlane]

Janoz schreef op dinsdag 04 januari 2011 @ 11:34:
Je business logic implementeren in SP is juist eerder hetgeen achterhaald is. Er zijn nog wel DBA-ers die standvastig vast blijven houden, maar over het algemeen is dat een gepasseerd station.

Je verhaal is duidelijk en op het punt van het hele "HTTPS is bijna standaard aanwezig" verhaal kan ik je alleen maar gelijk geven.

De andere punten lijken me lood om oud ijzer eigenlijk, als ik mijn db via een webservice beschikbaar maak moet ik ook een mogelijkheid hebben om data weg te kieperen bijvoorbeeld, en als de verkeerde het webservice-administrator password te weten komt heb ik hetzelfde probleem toch?

Maar mijn vraag is juist: Waarom is het een gepasseerd station? Is dat puur omdat HTTPS zo lekker makkelijk is of heeft het te maken met 'de trend van vandaag'?

Nu ben ik zelf geen database specialist, maar ik meende dat je bij MSSQL bijvoorbeeld de sp's/business logica ook in C# geschreven kunnen worden?
"Business logica in de database" is dan toch gewoon een andere plek dan "Business logica op de webserver"? Wat is nou *het* grote voordeel van die logica op een webserver hebben ipv in een db?

[mcdronkz]

De data van een applicatie hoeft natuurlijk niet persé uit een database te komen, resources kunnen van allerlei soorten types zijn. Het lijkt me echter wel wenselijk om het serveren van die resources vanuit een centraal punt te regelen. Een webservice is dan sowieso een stuk flexibeler, omdat het voor de client niets uitmaakt waar de bewuste data vandaan komt. Als je morgen besluit om op een ander soort database over te gaan, om maar iets te noemen, hoef je niet al je client software aan te passen wanneer je gebruik maakt van een webservice als interface.

[Moraelyn]

farlane schreef op dinsdag 04 januari 2011 @ 13:56:
[...]
Nu ben ik zelf geen database specialist, maar ik meende dat je bij MSSQL bijvoorbeeld de sp's/business logica ook in C# geschreven kunnen worden?

Beetje offtopic, maar C#, of eigenlijk .NET, in MSSQL staat standaard uit en als je het aanzet is het standaard ook nog eens in SAFE mode. Dit houd in dat je geen toegang tot externe bronnen hebt (niet eens het bestandssysteem van de server). Dat is natuurlijk niet voor niets. Voor External Access of Unsafe moet je nog door een aantal extra hoepels en wordt het al snel omslachtig.

[Janoz]

farlane schreef op dinsdag 04 januari 2011 @ 13:56:
Je verhaal is duidelijk en op het punt van het hele "HTTPS is bijna standaard aanwezig" verhaal kan ik je alleen maar gelijk geven.

De andere punten lijken me lood om oud ijzer eigenlijk, als ik mijn db via een webservice beschikbaar maak moet ik ook een mogelijkheid hebben om data weg te kieperen bijvoorbeeld, en als de verkeerde het webservice-administrator password te weten komt heb ik hetzelfde probleem toch?

Er hoeft helemaal geen webservice administrator password te zijn. Je ontsluit niet je database, maar je ontsluit alleen die serivce methoden die je wilt ontsluiten met standaard A&A ondersteuning en verder niks. Wanneer je een webservice maakt die als parameter een sql statement accepteert dan ben je natuurlijk dom bezig .

Maar mijn vraag is juist: Waarom is het een gepasseerd station? Is dat puur omdat HTTPS zo lekker makkelijk is of heeft het te maken met 'de trend van vandaag'?

Separation of concerns. Laat elke laag doen waar die laag goed voor is en niet meer dan dat. Dat houd het simpel en overzichtelijker. Of je dat 'trend van de dag' of 'voortschrijdend inzicht' wilt noemen mag je zelf bepalen.

Nu ben ik zelf geen database specialist, maar ik meende dat je bij MSSQL bijvoorbeeld de sp's/business logica ook in C# geschreven kunnen worden?

"Business logica in de database" is dan toch gewoon een andere plek dan "Business logica op de webserver"? Wat is nou *het* grote voordeel van die logica op een webserver hebben ipv in een db?

Het punt is dat business logica over het algemeen niet in de webserver of de database server, maar in de applicatieserver draait. Die applicatie server is dan vervolgens vaak wel weer onderdeel van een grote suite aan onderdelen.

Dat MSSql nu C# ondersteund als SP taal lijkt me meer handig voor rapid prototyping. Zeker ook omdat je je code volgens mij relatief simpel kunt hergebruiken wanneer je je POC gaat uitwerken.

[RobertMe]

Een ding wat ik nog mis in het hele verhaal over webservice vs. SP is hoe je over langere tijd iets consistent wilt houden. Als je rechtstreeks met de database connect kun je een transactie starten, doen wat je wilt, en dan de transactie commiten of rollbacken, hoe wil je dit in een webservice doen? Ik heb niet zoveel ervaring met webservices, maar het lijkt mij niet makkelijk, of onmogelijk, om meerdere acties netjes binnen een transactie te doen. Klopt dit of moet ik mij toch eens wat meer in webservices gaan verdiepen?

En ten opzichte van het programmeer opzicht, in MSSQL kun je schijnbaar C# gebruiken, voor PgSQL geld ongeveer hetzelfde, je kunt in "standaard SQL" (PL/SQL) of de procedurele taal PostgreSQL (PL/PGSQL), maar daarnaast zijn er ook Perl versies (Perl en een unsafe Perl, met als verschil dus ook weer toegang tot het filesystem etc.), C++ is een mogelijkheid, PHP word volgensmij aan gewerkt, en zo zijn er nog legio talen waarin je je stored procedurs kunt schrijven. Door gebruik te maken van een van de normale programmeertalen en daarin een kleine lagen architectuur toe te passen lijkt het mij ook mogelijk om, indien nodig, van database te switchen en bv. een webservice ervan te maken, dit doordat de logica dus in zijn eigen laag zit waarvoor je weer snel een andere "controller" of DAL laag kunt maken.

En naar mijn idee is het ook makkelijker, en logischer, om business constraints in de database vast te leggen. Waarom zou je bv. wel een foreign key aanmaken of een not null, of een unique constraint/index, maar niet een check inbouwen of een telefoonnummer wel een telefoonnummer is, of een postcode wel een postcode is etc., dit zijn allemaal voorwaarden die rechtstreeks op de data zitten, en de enige manier om er zeker van te zijn dat deze altijd correct zijn opgeslagen, is door de controle in de database te doen.

[Janoz]

Een webservice kan ook gewoon een transactie starten. Je moet alleen niet de transactie starten in de ene call en pas afsluiten in de andere call. Maar dergelijke langlopende transacties zou je eigenlijk ook niet moeten gebruiken wanneer je rechtstreeks verbindt.

Wat je je goed moet beseffen is dat je gewoon je ontkoppelvlak opschuift. De logica die jij normaal zou implementeren in je client, implementeer je op de server. Je client roept die webservice aan en die voert de verschillende acties uit. Uiteraard zul je constraints ook in je database moeten implementeren, maar businesslogic is vaak meer dan alleen een beetje validatie.

[farlane]

Janoz schreef op dinsdag 04 januari 2011 @ 15:17:
Er hoeft helemaal geen webservice administrator password te zijn. Je ontsluit niet je database, maar je ontsluit alleen die serivce methoden die je wilt ontsluiten met standaard A&A ondersteuning en verder niks. Wanneer je een webservice maakt die als parameter een sql statement accepteert dan ben je natuurlijk dom bezig .

Ik bedoelde ook meer de webservice functies die bv alleen de 'CMS administrator' ( dus niet de db administrator oid ) zou gebruiken om data weg te gooien, niet dat je letterlijk querystrings naar je webservice-interface gooit. Bv de 'gooi user x weg' methode die alleen mag worden uitgevoerd door de CSM administrator.

Maar dergelijke langlopende transacties zou je eigenlijk ook niet moeten gebruiken wanneer je rechtstreeks verbindt.

Wanneer mag je die wel gebruiken dan?

[ Voor 10% gewijzigd door farlane op 04-01-2011 16:44 ]

[Woy]

Maar dat security probleem zal je altijd houden. Als iemand met veel rechten zijn credentials kwijtraakt, dan kan iemand daar misbruik van maken. Dat is bij elke aanpak zo.

[Janoz]

farlane schreef op dinsdag 04 januari 2011 @ 16:42:
Ik bedoelde ook meer de webservice functies die bv alleen de 'CMS administrator' ( dus niet de db administrator oid ) zou gebruiken om data weg te gooien, niet dat je letterlijk querystrings naar je webservice-interface gooit. Bv de 'gooi user x weg' methode die alleen mag worden uitgevoerd door de CSM administrator.

Klopt. Maar bij de SP oplossing is de andere situatie verre van ondenkbaar.

Wanneer mag je die wel gebruiken dan?

Eigenlijk nooit. Je kunt beter kijken of het ook middels optimistic locking scenario's op te lossen is wanneer je denkt ze nodig te gaan hebben. Bij de opmerking van de topicstarter kreeg ik een beetje het gevoel van een transactie starten wanneer de gebruiker begint te wijzigen en pas committen wanneer de gebruiker op save drukt.

[BryanD]

@janoz, dat was niet 100% wat ik in gedachten had.

Transactie starten zodra er op save gedrukt word en dan committen