Afwegingen bij de koppeling tussen webinterface en backend

[Verwijderd]

We zijn hier van plan een webinterface te bouwen voor een Windows applicatie. Deze applicatie gebruikt een backend in SQL server. De webinterface willen we waarschijnlijk in PHP ontwikkelen. Samen met de ontwikkelaar van de Windows applicatie staan we nu voor een aantal keuzes, waaronder die voor de gekozen koppeling tussen de webinterface en de backend.

Een optie is natuurlijk dat wij rechtstreeks vanuit PHP een koppeling maken met de SQL server. Dat is voor ons het eenvoudigst (qua ervaring ook), maar misschien niet het veiligst, omdat er geen controlerende laag tussen PHP en SQL zit.

Een andere optie is een webservice zoals SOAP. Daar hebben we niet veel ervaring mee, en ik vraag me af of dit een goede keuze is. Waarom zouden we wel of niet voor SOAP moeten kiezen? Wat zijn de beperkingen? We hebben hier al eens mee getest, en de ontwikkelaar kost dit natuurlijk extra tijd om deze laag goed op te zetten. Het voordeel is de platformonafhankelijkheid en de scheiding t.o.v. de database.

Of zijn er misschien nog andere goede opties, die we hier helemaal over het hoofd zien?

[djc]

Ja: een database-onafhankelijke library die zorgt dat je soort van (echt helemaal wordt het nooit) transparant van database server zou kunnen wisselen, mocht dat nodig zijn. Voor PHP 5.1 is PDO wellicht de geijkte oplossing, andere mogelijkheden zijn bijvoorbeeld ADODB of Metabase.

Verder lijkt een SOAP-laag tussen DB en applicatie me niet alleen overkill die je nooit nodig gaat hebben, maar ook een significante drag voor je performance. Al het serialiseren en ontserialiseren gaat je zeker niet in je koude kleren zitten.

[Verwijderd]

Dat overkill zou inderdaad goed kunnen. Naast de tijd die het ons kost om ons in SOAP te verdiepen kost het ook de ontwikkelaar tijd. En die performance die naar beneden knalt is natuurlijk ook niet ideaal.

Ik heb weleens met Ruby On Rails gewerkt en vindt de MVC scheiding die ze daar gebruiken erg goed. Zoiets moet ik misschien in PHP gebruiken. Waarbij we automatisch gegenereerde classes gebruiken in onze applicatie. Als de database dan een keer gewijzigd wordt hoeven alleen de classes bijgewerkt te worden.

[RobIII]

Verwijderd schreef op donderdag 07 september 2006 @ 09:56:
Ik heb weleens met Ruby On Rails gewerkt en vindt de MVC scheiding die ze daar gebruiken erg goed. Zoiets moet ik misschien in PHP gebruiken. Waarbij we automatisch gegenereerde classes gebruiken in onze applicatie. Als de database dan een keer gewijzigd wordt hoeven alleen de classes bijgewerkt te worden.

En waarom zou dat via PHP moeten en kan dat niet in de applicatie zelf?
Behalve dat je dus PHP nodig hebt om je app te kunnen draaien zit je gewoon een overbodige extra laag in te bouwen; een laag die ook bugs kan bevatten, uit kan vallen etc. Je maakt het jezelf alleeen maar moeilijk. Zorg dat je de classes waar je het over hebt schrijft in je windows-app (losse DLL of whatever) en mocht je ooit van DB switchen (niet dat dat vaak gebeurt) dan ben je waarschijnlijk "zo" klaar om die classes aan te passen naar de nieuwe DB.

[Verwijderd]

RobIII schreef op donderdag 07 september 2006 @ 10:38:
[...]

En waarom zou dat via PHP moeten en kan dat niet in de applicatie zelf?
Behalve dat je dus PHP nodig hebt om je app te kunnen draaien zit je gewoon een overbodige extra laag in te bouwen; een laag die ook bugs kan bevatten, uit kan vallen etc. Je maakt het jezelf alleeen maar moeilijk. Zorg dat je de classes waar je het over hebt schrijft in je windows-app (losse DLL of whatever) en mocht je ooit van DB switchen (niet dat dat vaak gebeurt) dan ben je waarschijnlijk "zo" klaar om die classes aan te passen naar de nieuwe DB.

Hoe dat in de applicatie zelf moet zou ik niet weten. De webinterface heeft geen koppeling met de applicatie, maar met SQL, of een eventuele webservice. Ik snap eerlijk gezegd niet helemaal wat je bedoelt.

[RobIII]

Wat ik bedoel is waarom je de applicatie geen verbinding laat maken met SQL (en dus gewoon compleet PHP er tussen uit). Waarom zou je applicatie via een webinterface moeten babbelen?

[Boss]

RobIII schreef op donderdag 07 september 2006 @ 11:18:
Wat ik bedoel is waarom je de applicatie geen verbinding laat maken met SQL (en dus gewoon compleet PHP er tussen uit). Waarom zou je applicatie via een webinterface moeten babbelen?

Volgens mij is interface hier een user-interface. Dezelfde data dus benaderen via het web. En niet een interface als in doorgeefluik tussen twee systemen.

[Verwijderd]

Boss schreef op donderdag 07 september 2006 @ 11:23:
[...]


Volgens mij is interface hier een user-interface. Dezelfde data dus benaderen via het web. En niet een interface als in doorgeefluik tussen twee systemen.

Dat klopt! Sorry als ik niet helemaal duidelijk was. De Windows interface is er al, en die laten we voor wat hij is. Er moet op de SQL database een webinterface komen.

[Boss]

Waarom moet de applicatie nu eigenlijk ook via het web aangeboden worden? Wordt dat een nieuwe versie met andere funcitonaliteiten of een (zoveel mogelijk) 1-op-1 kopie van de functionliteit?

Anders zou je ook gewoon de applicatie die je al hebt (betaald) kunnen aanbieden via een citrix achtige of remote desktop omgeving. Dan heb je in de toekomst ook maar 1 programma bij te houden.

[djluc]

Het lijkt me vooral niet wenselijk om zowel in de windows applicatie als de web-applicatie de business logic te gaan implementeren. Oftwel, eigenlijk zouden beide gebruik moeten maken van dezelfde software als backend. Is dit mogelijk?

[Verwijderd]

Gewoon PHP rechtstreeks met SQL server laten praten. In SQL Server instellen wat beveiliging betreft wat de webuser wel of niet mag. (Bijv alleen execute rechten op de Stored Procedures die nodig zijn...)

Als je gebruik hebt gemaakt van Stored Procedures voor de Windows App kun je die ook mooi hergebruiken voor je PHP-App.

[D-Raven]

Verwijderd schreef op donderdag 21 september 2006 @ 01:27:
Gewoon PHP rechtstreeks met SQL server laten praten. In SQL Server instellen wat beveiliging betreft wat de webuser wel of niet mag. (Bijv alleen execute rechten op de Stored Procedures die nodig zijn...)

Als je gebruik hebt gemaakt van Stored Procedures voor de Windows App kun je die ook mooi hergebruiken voor je PHP-App.

Dat lijkt me (gezien de situatie die omschreven word) niet echt wenselijk. Ik sluit me aan bij djluc. Als je voor een applicatie in feite 2 UI interfaces gaat maken. Waarbij je de windows interface al hebt, en dus nu een webinterface gaat bouwen. Dan is het beter om een backend applicatie te hebben die in feite al het werk doet, en waarbij je dan de UI interfaces laat doen waar ze voor bedoeld zijn. GUI interface zijn.

Op deze manier voorkom je een hele hoop problemen. In principe zou je de backend applicatie als dll kunnen laten draaien op je webserver, waar dan je webinterface en windows-client gebruik van maken.