[alg]keuze applicatie framework

[djluc]

Ik ben op dit moment bezig om een keuze te maken tussen verschillende frameworks om een applicatie op te gaan ontwikkelen. Het uiteindelijke doel is het creëren van een website met daarop een productcatalogus, klantenlogin, klantendossier met daarin alle offertes/orders/facturen/factuurstatussen enzovoorts. Verder dient de site compleet onderhouden te kunnen worden. Dit alles geheel webbased.

We hebben uiteraard een compleet plan van eisen opgesteld en hebben geen kant-en-klaar product kunnen vinden. Daarom denken we over het ontwikkelen van een maatwerp applicatie. Om een snelle ontwikkeling mogelijk te maken lijkt het ons handig om gebruik te maken van een framework.

Maar waarop baseer je de keuze van een framework? We hebben geen kennis van alle talen, alleen PHP. Het is voor ons dus onmogelijk om zaken als technische mogelijkheden/modulaire opbouw e.d. ook daadwerkelijk te controleren. Het maken van de applicatie wordt echter uitbesteed. Is het logisch om bij applicatie-ontwikkeling eerst een framework keuze te maken of kies je voor een bedrijf en neem je aan de hand daarvan hun meest gebruikte basis?

[Tux]

Het ligt er vooral aan welk framework het bedrijf fijn vindt werken denk ik.

[djluc]

Tux schreef op 11 augustus 2004 @ 11:46:
Het ligt er vooral aan welk framework het bedrijf fijn vindt werken denk ik.

Is het een onlogische redenering om te gaan kijken welk framework het beste voor ons is en vervolgens te gaan kijken welke bedrijven hier mee kunnen werken?

[Alarmnummer]

Voor een keuze van een bepaald framework heb je inzicht nodig en moet je verschillende frameworks met elkaar kunnen vergelijken. Als je er geen ervaring mee hebt, dan gaat dit een onmogelijke zaak worden. Ik denk dat je het beste aan het bedrijf over kan laten om dat soort keuzes (in samenwerking met jullie) te maken.

De kans bestaat ook dat het aantal mogelijkheden wordt beperkt door het bedrijf waar je mee samenwerkt. Stel dat ze Java oriented zijn, of .NET.. dan zal hun keuze ook meer richting die kant opliggen.

[Infinitive]

Het zou eigenlijk moeten zijn dat je het "framework" (wat je daar ook onder verstaat) kiest wat het beste bij de gestelde eisen past...
... maar in de praktijk geldt dat degene die de keuze maakt alleen keuzen waar hij bekend mee is als mogelijkheden aanziet.

[Orphix]

Wat Tux zegt zal een bedrijf geneigd zijn om met een oplossing te komen waar ze al ervaring mee hebben. Dit is op zich niet verkeerd, het geeft jullie als klant een snellere en betere oplossing. Wanneer het bedrijf zich op terreinen gaat begeven wat ook nieuw voor hen is valt dat voordeel weg.

Verder denk ik dat een van de belangrijkste factoren die je framework bepalen de integratie met je hudige back-end is. Stel dat het bedrijf volledig op windows software draait. Het is dan logischer om ASP.NET erbij te pakken dan bv PHP. Voor UNIX achtige systemen zou je kunnen kijken naar Java-oplossingen.
Wanneer de applicatie volledig los staat van de huidige software is het probleem een stuk simpeler. Dan is het zaak meer te letten op de snelheid van het ontwikkelen en de kostprijs. Veel offertes aanvragen en vergelijken

[Verwijderd]

Dit is een vraag met geen vast of goed antwoord. Iedereen heeft zo zijn voorkeuren en ervaringen.

Mijn ervaringen...

Het .NET Framework is erg goed (mijn voorkeur) voor het ontwikkelen van data-driven websites m.b.v. asp.net. Er is veel gedocumenteerd, er staan veel sourceprojects op www.asp.net, veel andere voorbeelden staat op gotdotnet.com, en de nieuwsgroepen van microsoft zijn snel en behulpzaam.

J2EE heeft voor mij het nadeel hoe het met data en de synchronisatie ervan omgaat. In .NET heb je de dataset waarin je kan werken en deze naar de database kan sturen waardan alle updates worden doorgevoerd. In J2EE moet je alles handmatig met SQL statements doen (of je moet 3rd party software kopen).

Een vergelijking van J2EE en .NET die specifiek handig voor jou kan zijn staat op:

http://www.devx.com/Java/Article/21602/0/page/1

Daarnaast zou je ook bitpipe.com kunnen raadplegen voor andere onderzoeken.

[Tux]

Wat naar mijn mening ook een goede manier is om tot de keuze van het juiste framework te komen, is om zelf een aantal frameworks te vergelijken en daar het framework uit te kiezen wat jullie het beste lijkt voor deze applicatie. Laat vervolgens een softwarebedrijf ook zo'n keuze maken, zij kiezen naar alle waarschijnlijkheid voor een framework waar ze al ervaring mee hebben.
Vraag het bedrijf om een aantal argumenten voor het gebruik van dit framework, in het geval dat jullie elk een ander framework uitkiezen. Zo kan met een discussie tussen het bedrijf waar de TS werkt aan de ene kant en het softwarebedrijf aan de andere kant de beste keuze gemaakt worden.

[Infinitive]

Orphix schreef op 11 augustus 2004 @ 11:52:
Veel offertes aanvragen en vergelijken

De TS heeft de rol als klant; dat maakt de discusse mogelijk interessant.

Want als ik kijk naar offertes dan denk ik twee dingen:
- vast bedrag voor applicatie / uurloon
- tijdschatting die het bedrijf geeft voor de applicatie

Maar als zo'n bedrijf "even" een offerte maakt, dan vraag ik me af hoe goed die tijdschattingen zullen zijn. En daarmee dus de echte waarde van de offerte. Ofwel, hoe ga je hier als klant mee om? Ben je als klant bijv. bereid om tegen een gereduceerd urentarief eerst een vooronderzoek door het kandidaatbedrijf te laten doen? Etc.

[ Voor 22% gewijzigd door Infinitive op 11-08-2004 12:03 ]

[djluc]

Jullie punten zijn heel logisch en duidelijk hoor maar waarom zouden wij gebonden zijn aan 1 bedrijf? Een bedrijf hoeft niet een nieuwe techniek te leren omdat ze niet met framework X om kunnen gaan: we kiezen dan voor een bedrijf wat wel met die techniek kan werken met alle voordelen vandien.

Je mag gewoon uitgaan dat we op punt 0 staan en een geheel nieuw systeem willen ontwikkelen.

Infinitive schreef op 11 augustus 2004 @ 11:59:
[...]
De TS heeft de rol als klant; dat maakt de discusse mogelijk interessant.
Want als ik kijk naar offertes dan denk ik twee dingen:
- vast bedrag voor applicatie / uurloon
- tijdschatting die het bedrijf geeft voor de applicatie
Maar als zo'n bedrijf "even" een offerte maakt, dan vraag ik me af hoe goed die tijdschattingen zullen zijn. En daarmee dus de echte waarde van de offerte. Ofwel, hoe ga je hier als klant mee om?

Interessant punt inderdaad. Waarom zou een bedrijf dat framework X aanraad en een gelijk aantal uren offereert ook daadwerkelijk een even goede applicatie afleveren.

[ Voor 48% gewijzigd door djluc op 11-08-2004 12:02 ]

[Verwijderd]

Lees zelf wat algemene info over de verschillende frameworks die er zijn en laat potentiele leveranciers maar hard maken waarom ze een bepaald framework gebruiken.

[Alarmnummer]

Verwijderd schreef op 11 augustus 2004 @ 11:58:
J2EE heeft voor mij het nadeel hoe het met data en de synchronisatie ervan omgaat. In .NET heb je de dataset waarin je kan werken en deze naar de database kan sturen waardan alle updates worden doorgevoerd. In J2EE moet je alles handmatig met SQL statements doen (of je moet 3rd party software kopen).

Dikke stierepoep.

Er zijn genoeg goeie (gratis/opensource) oplossingen voor J2EE:EJB-CMP, Hibernate, JDO, OJB om maar een paar te noemen waardoor je dus geen kont meer nodig hebt met SQL-code.

[ Voor 10% gewijzigd door Alarmnummer op 11-08-2004 12:07 ]

[djluc]

Verwijderd schreef op 11 augustus 2004 @ 12:02:
Lees zelf wat algemene info over de verschillende frameworks die er zijn en laat potentiele leveranciers maar hard maken waarom ze een bepaald framework gebruiken.

Het punt is dat ik toch niet aan ieder bedrijf een offerte kan gaan vragen? Ik zal toch eerst een globale shifting moeten maken om het kaf en het koren te scheiden?

[Verwijderd]

Alarmnummer schreef op 11 augustus 2004 @ 12:05:
[...]

Dikke stierepoep.

Er zijn genoeg goeie oplossingen voor J2EE:EJB-CMP, Hibernate, JDO, OJB.

Standaard framework kent geen dataset achtige dingen.. daarom zijn er ook die dingen zoals jij genoemt hebt voor ontwikkelt....

Ik vind persoonlijk dat een framework zeker een aantal basis dingen goed voor elkaar moet hebben en dat hoe het met data omgaat.

Maar dit gaat de kant op van een j2ee vs .net discussie en daar wil ik best aan meedoen maar dan zie ik je graag terug in een ander topic dat speciaal daarvoor geopend is, laten we het hier on-topic houden.

De keuze van een framework kan van belang zijn als je de applicaties zelf gaat hosten. Mocht je voor .NET kiezen dan is een iis 5/6 machine en SQL server een voor de handliggende keuze.

Mochten jullie oracle databases hebben staan en linux/unix webservers dan zou ik weer eerder naar een J2EE platform gaan.

[djluc]

Interessant punten Philip! alvast bedankt.

We hebben geen eigen server staan en zijn dit in principe ook niet van plan. Er zijn zo'n 2 personen die de gegevens aan moeten passen en daarvoor is een goede ADSL verbinding met een server van een provider volgens ons voldoende. Voor zowel ASP.NET als bijvoorbeeld PHP en andere oplossingen zijn wel hosters te vinden dus dat maakt weinig verschil lijkt mij.

[Alarmnummer]

Verwijderd schreef op 11 augustus 2004 @ 12:09:
[...]
Standaard framework kent geen dataset achtige dingen.. daarom zijn er ook die dingen zoals jij genoemt hebt voor ontwikkelt....

Zeker wel. EJB-CMP is een onderdeel van de EJB specs. JDO is een nieuw kindje van Sun. En dan hoef je niet eens te werken met dataset achtige prut, maar kan je gewoon met een object model werken en al dat gezever van het relationele model daar mooi aan overlaten.

Ik vind persoonlijk dat een framework zeker een aantal basis dingen goed voor elkaar moet hebben en dat hoe het met data omgaat.

Ben ik met je eens. Maar om nu te concluderen dat Java niet goed met data kan omgaan vind ik getuigen van gebrek aan kennis. Ik heb geen verstand van .NET in enterprise omgevingen en heb daarom ook nog met geen woord negatief/positief advies gegeven. Jij geeft de indruk dat Java niet goed met data kan omgaan en ik zeg dat dat onzin is. Jij loopt dus leugens te verkondigen (en dit keer is het door gebrek aan kennis). Maar jij bent dus een van de dingen waar de it last van heeft: mensen die lopen te blaten.

De keuze van een framework kan van belang zijn als je de applicaties zelf gaat hosten. Mocht je voor .NET kiezen dan is een iis 5/6 machine en SQL server een voor de handliggende keuze.

J2EE draait ook heerlijk op een windows omgevingen en kan ook goed samenwerken met SQL-server.

Mochten jullie oracle databases hebben staan en linux/unix webservers dan zou ik weer eerder naar een J2EE platform gaan.

[ Voor 7% gewijzigd door Alarmnummer op 11-08-2004 12:17 ]

[zneek]

Verwijderd schreef op 11 augustus 2004 @ 12:09:
[...]


Standaard framework kent geen dataset achtige dingen.. daarom zijn er ook die dingen zoals jij genoemt hebt voor ontwikkelt....

Ik vind persoonlijk dat een framework zeker een aantal basis dingen goed voor elkaar moet hebben en dat hoe het met data omgaat.

Maar dit gaat de kant op van een j2ee vs .net discussie en daar wil ik best aan meedoen maar dan zie ik je graag terug in een ander topic dat speciaal daarvoor geopend is, laten we het hier on-topic houden.

De keuze van een framework kan van belang zijn als je de applicaties zelf gaat hosten. Mocht je voor .NET kiezen dan is een iis 5/6 machine en SQL server een voor de handliggende keuze.

Mochten jullie oracle databases hebben staan en linux/unix webservers dan zou ik weer eerder naar een J2EE platform gaan.

Verzin je je redenatie nu ter plekke? Heb je uberhaupt een poging gedaan om je uitspraken te verifieren?

Als je J2EE noemt, moet je wel weten waar je het over hebt. De componenten van J2EE zijn:

- EJB
- Servlets
- JSP
- JNDI
- JDBC
- JMS
- JTA
- JAXP
- JavaMail
- J2EE Connector API
- JAAS
- RMI
- IDL

Waarbij JDBC een SQL ingang is, maar nog interessanter EJB met zijn CMP variant een (bijna) SQL loze manier is van persistentie. Dus zo even roepen dat J2EE slecht met data omgaat getuigd wel van erg weinig inzicht in de materie. Ik sluit me dan ook helemaal aan bij de post van Alarmnummer. Als je niet weet waar je het over hebt, zegt dan gewoon niets.

[edit] daar komt nog eens bij dat je met J2EE niet met een DataSet oplossing hoeft te werken. als je EJB CMP goed in zet heb je helemaal niets met je database te maken, en kun je 100% OO blijven programmeren. Probeer dat maar eens met .Net! Dan heb je toch echt ook allerlei plugins/toevoegingen nodig, of je moet zelf een ellendige hoeveelheid programmeerwerk doen.

[ Voor 11% gewijzigd door zneek op 11-08-2004 12:39 ]

[djluc]

Ik kan wel een concreet voorbeeldje geven:
We hebben al wat gesproken met software leveranciers en 2 hebben expliciet 2 pakketten genoemd:
Typo3: PHP gebaseerd
dotnetnuke:.NET technologie

Typo3 heeft een mooie site voor de "marketing" waarop duidelijk staat wat de voordelen en mogelijkheden zijn e.d. Op de .org site kan je zien dat er al veel modules voor gemaakt zijn en dat dit mogelijk is met een soort van Kickstarter. Ook consultants zijn er genoeg te vinden.

Dotnetnuke heeft een "vage" site waarop je als klant zijnde maar weinig kan vinden. Wel zijn er vele modules dus het maken daarvan schijnt ook goed mogelijk te zijn. Hoe kan ik nou ooit op een gefundeerde manier een keuze maken?

Als ik het met deze gegevens zou moeten doen zou ik overigens kiezen voor Typo3 omdat we toch al een PHP/MySQL hostings pakket hebben en ik zelf ook een aardige kennis van PHP heb maar dat is geen goede onderbouwing.

[Verwijderd]

@ zneek en alarmnummer..

Zitten die componenten er allemaal standaard bij het framework? Of aparte download's / installs?

[-FoX-]

Ik weet dat het niet de bedoeling is om hier met pakketten te gaan gooien, maar het eerste pakket dat in mij opkwam en dat aan jouw voorwaarden voldoet is LynxTrader. Misschien moet je daar eens naar kijken.

En ik denk overigens dat het niet zoveel uitmaakt in welke taal er ontwikkelt wordt en op welk framework er gebasseerd wordt, maar kijk eerst eens naar een bedrijf waar je een goede indruk over hebt, ze een niet te duur (maat)pakket aanbieden en die natuurlijk voor 100% aan jouw voorwaarden voldoen...

[Verwijderd]

djluc schreef op 11 augustus 2004 @ 12:39:
Ik kan wel een concreet voorbeeldje geven:
We hebben al wat gesproken met software leveranciers en 2 hebben expliciet 2 pakketten genoemd:
Typo3: PHP gebaseerd
dotnetnuke:.NET technologie

Typo3 heeft een mooie site voor de "marketing" waarop duidelijk staat wat de voordelen en mogelijkheden zijn e.d. Op de .org site kan je zien dat er al veel modules voor gemaakt zijn en dat dit mogelijk is met een soort van Kickstarter. Ook consultants zijn er genoeg te vinden.

Dotnetnuke heeft een "vage" site waarop je als klant zijnde maar weinig kan vinden. Wel zijn er vele modules dus het maken daarvan schijnt ook goed mogelijk te zijn. Hoe kan ik nou ooit op een gefundeerde manier een keuze maken?

Als ik het met deze gegevens zou moeten doen zou ik overigens kiezen voor Typo3 omdat we toch al een PHP/MySQL hostings pakket hebben en ik zelf ook een aardige kennis van PHP heb maar dat is geen goede onderbouwing.

Bij DotNetNuke moet je even kijken naar de ontwikkelaars van die modules, veel ervan maken ook maatwerkoplossingen gebaseerd op DotNetNuke.

Mijn eigen website draait ook op DotNetNuke : http://www.wagenaar.123.nl

[zneek]

Verwijderd schreef op 11 augustus 2004 @ 12:46:
@ zneek en alarmnummer..

Zitten die componenten er allemaal standaard bij het framework? Of aparte download's / installs?

Zit allemaal standaard in J2EE. Zie: http://java.sun.com/products/ejb/index.jsp en http://java.sun.com/j2ee/.

Maar uiteraard ga je je J2EE server niet belasten met onderdelen die je niet gebruikt. Afhankelijk daarvan zet je dingen aan of uit.

[ Voor 18% gewijzigd door zneek op 11-08-2004 12:51 ]

[Verwijderd]

zneek schreef op 11 augustus 2004 @ 12:50:
[...]


Zit allemaal standaard in J2EE. Zie: http://java.sun.com/products/ejb/index.jsp en http://java.sun.com/j2ee/.

Maar uiteraard ga je je J2EE server niet belasten met onderdelen die je niet gebruikt. Afhankelijk daarvan zet je dingen aan of uit.

Ik baseer me op http://www.devx.com/Java/Article/21602 ...

[djluc]

Ik vind het best interessant om jullie discussie over de onderdelen te volgen maar we drijven eigenlijk een beetje af van het daadwerkelijke onderwerp.

Hoe kan ik de juiste keuze maken? Ik heb ook al gedacht om een topic te maken met enkele mogelijkheden en daar over te gaan discussiëren maar dat is niet echt interessant omdat je dan altijd weer bepaalde producten niet meeneemt in je vergelijking.

[OkkE]

Ik zou je keuze als eerste laten afhangen van de hardware; is het de bedoeling dat alles gaat draaien op een Windows machine dan zou ik voor .NET gaan, anders PHP. Maar wanneer er een nieuwe machine aangeschaft gaat worden denk ik dat je het beste kunt kijken naar welk bedrijf je mee samen wil werken, en in samenwerking met hun beslissen welk framework gebruikt gaat worden.

[ Voor 7% gewijzigd door OkkE op 11-08-2004 13:11 ]

[djluc]

OkkE schreef op 11 augustus 2004 @ 13:10:
Ik zou je keuze als eerste laten afhangen van de hardware; is het de bedoeling dat alles gaat draaien op een Windows machine dan zou ik voor .NET gaan, anders PHP. Maar wanneer er een nieuwe machine aangeschaft gaat worden denk ik dat je het beste kunt kijken naar welk bedrijf je mee samen wil werken, en in samenwerking met hun beslissen welk framework gebruikt gaat worden.

Systeem maakt ons in principe niets uit met een lichte voorkeur naar PHP omdat we toch al een dergelijk pakket hebben.

Eigenlijk maak ik uit jouw reactie op dat de verschillen tussen de frameworks niet echt groot zijn en dat het dus niet zo heel erg veel uit maakt welke we kiezen? Of zit er toch nog wat meer achter?

[Peetman]

Het probleem van zowel het .Net framework als J2EE is dat er niet zo snel een goede hoster voor gevonden kan worden. Dus zal je waarschijnlijk zelf een systeem gaan aanschaffen. Aangezien een J2EE applicatieserver als bijvoorbeeld Websphere zowel op Linux/Solaris/Windows prima draait, is je keuze baseren op hardware nogal kortzichtig. Ook je DB platform erachter heeft er weinig mee te maken.

Waar moet je het dan wel op baseren. Dat is moeilijk te zeggen, al helemaal omdat je geen ervaring hebt met frameworks. Ik zou een aantal partijen in deze om een offerte vragen. Leg uit wat je bedoelingen zijn en vraag om een technische onderbouwing. Het ene software bedrijf heeft meer ervaring met J2EE, het andere weer met .Net of bijvoorbeeld PHP, of Lotus Domino

Eigenlijk maak ik uit jouw reactie op dat de verschillen tussen de frameworks niet echt groot zijn en dat het dus niet zo heel erg veel uit maakt welke we kiezen? Of zit er toch nog wat meer achter?

Mijns inziens is het verschil tussen .Net en J2EE in de basis niet zo heel erg groot. Het grootste voordeel van J2EE vind ik het EJB-CMP verhaal en het feit dat omdat het een open standaard is, er meerdere leveranciers zijn voor applicatie servers.

PHP is misschien voor het systeem dat je nu voor ogen hebt geschikt, maar moet het IMHO toch afleggen op basis van uitbreidbaarheid en ondersteuning.

[ Voor 29% gewijzigd door Peetman op 11-08-2004 13:28 ]

[OkkE]

djluc schreef op 11 augustus 2004 @ 13:25:
[...]
Eigenlijk maak ik uit jouw reactie op dat de verschillen tussen de frameworks niet echt groot zijn en dat het dus niet zo heel erg veel uit maakt welke we kiezen? Of zit er toch nog wat meer achter?

Je moet zeker niet op alleen mijn reactie afgaan, aangezien ik nog vrij weinig ervaring heb met .NET. Maar dat is de manier hoe ik het - op dit moment - zelf zou aanpakken.

[djluc]

peetman schreef op 11 augustus 2004 @ 13:26:
Het probleem van zowel het .Net framework als J2EE is dat er niet zo snel een goede hoster voor gevonden kan worden.

Ik ga zometeen eens rondkijken hoe het met die hosting zit en wat er mogelijk is wat betreft het uitbesteden daarvan.

Waar moet je het dan wel op baseren. Dat is moeilijk te zeggen, al helemaal omdat je geen ervaring hebt met frameworks. Ik zou een aantal partijen in deze om een offerte vragen. Leg uit wat je bedoelingen zijn en vraag om een technische onderbouwing. Het ene software bedrijf heeft meer ervaring met J2EE, het andere weer met .Net of bijvoorbeeld PHP, of Lotus Domino

Ik heb wel ervaring met verschillende frameworks. Maar ik moet mijn keuze nu onderbouwen. Voor verschillende kleine websites heb ik gewoon een framework gebruikt wat door wat forumbezoekers als goed werd gezien en waar een goed artikel over geschreven was. Daar kon ik gewoon wat mee aan rommelen. Dat kan nu niet omdat de keuze tot gevolg heeft dat er een flink bedrag geïnvesteerd gaat worden. Een foute keuze zou dus wel ernstige gevolgen hebben.

Mijns inziens is het verschil tussen .Net en J2EE in de basis niet zo heel erg groot. Het grootste voordeel van J2EE vind ik het EJB-CMP verhaal en het feit dat omdat het een open standaard is, er meerdere leveranciers zijn voor applicatie servers.

* djluc is ook voorstander van open standaarden. De voordelen hiervan zijn bekend en open software krijgt wat ons betreft ook daadwerkelijk een extra pluspuntje. Echter is dat misschien niet een belangrijk punt om de keuze te funderen.

PHP is misschien voor het systeem dat je nu voor ogen hebt geschikt, maar moet het IMHO toch afleggen op basis van uitbreidbaarheid en ondersteuning.

Ik heb Typo3 toevallig eens wat beter bekeken en vind dat dit pakket ook goed in elkaar zit, vele mogelijkheden heeft. Verder wordt het op Internet door velen gezien als één van de beter ontwikkelde pakketten gemaakt in PHP. Verder zijn er voorbeelden van sites die er op draaien en die zijn zeker niet mis. Vrij dubieus dus.

[Alarmnummer]

djluc schreef op 11 augustus 2004 @ 13:41:
* djluc is ook voorstander van open standaarden. De voordelen hiervan zijn bekend en open software krijgt wat ons betreft ook daadwerkelijk een extra pluspuntje. Echter is dat misschien niet een belangrijk punt om de keuze te funderen.

Open standaarden zijn leuk.. maar met Java kan het soms ook tegen je werken. Met MS heb je gewoon een aantal mogelijkheden en daar zal je het mee moeten doen. Met java heb je een heel scala aan mogelijkheden, maar dat kan de keuze ook een stuk complexer maken. Uiteindelijk moet jij als niet wetende klant daar niets mee te maken hebben en volledig kunnen overlaten aan het bedrijf dat de software voor je maakt. Het is hetzelfde als je openhart chirurg adviseren welk mes hij moet gebruiken voor je openhart operatie. Laat dat die goeie man doen.. hij heeft er ervaring mee.

Als bedrijfszijnde kunnen open standaarden mijn rug op. Ik wil een goed product, voor een zo laag mogelijke prijs en politiekcorrectheid en dat soort onzin kan ik missen als kiespijn. Java? .NET? PHP? zal me worst zijn.. als ik maar krijg wat ik wil.

Ik heb Typo3 toevallig eens wat beter bekeken en vind dat dit pakket ook goed in elkaar zit, vele mogelijkheden heeft. Verder wordt het op Internet door velen gezien als één van de beter ontwikkelde pakketten gemaakt in PHP. Verder zijn er voorbeelden van sites die er op draaien en die zijn zeker niet mis. Vrij dubieus dus.

Ik vraag me af of de keuze voor PHP voor een bedrijfs kritische applicatie wel zo goed is. Het slag mensen dat met Java/.NET werkt is vele malen professioneler dan PHP`ers.

[ Voor 11% gewijzigd door Alarmnummer op 11-08-2004 13:50 ]

[Verwijderd]

Of je kunt zelf een eenvoudige implementatie van MVC inbouwen Op zich is het een ideaal design pattern wat goed gebruikt kan worden in frameworks

[Alarmnummer]

Verwijderd schreef op 11 augustus 2004 @ 13:58:
Of je kunt zelf een eenvoudige implementatie van MVC inbouwen Op zich is het een ideaal design pattern wat goed gebruikt kan worden in frameworks

MVC is leuk, maar als je een klein beetje thuis bent in enterprise omgevingen voor bv Java of .NET dan zie je dat het maar een heel klein onderdeel van het geheel is.

[zneek]

djluc schreef op 11 augustus 2004 @ 13:41:
[...]
Ik ga zometeen eens rondkijken hoe het met die hosting zit en wat er mogelijk is wat betreft het uitbesteden daarvan.
[...]

Als je een J2EE server of een .Net server gehost moet hebben kan ik je wel verder helpen, wij bieden beide aan. J2EE met JBoss, incl support e.d.
[/schaamteloze reclame]

Ik denk dat je je in dit hele verhaal beter kunt concentreren op de eisen aan de applicatie, dan op specifieke platformen. Zoals Alarmnummer al zegt, laat de specialisten zich daar maar over buigen. Jij geeft aan wat het moet kunnen, mag kosten en hoe uitbreidbaar het moet zijn. Dan vindt je implementatie partner wel een passende oplossing.

[nogmaals schaamteloze reclame]
Ook daar zouden we je mee kunnen helpen
[/nogmaals schaamteloze reclame]

[Verwijderd]

djluc schreef op 11 augustus 2004 @ 12:39:
Ik kan wel een concreet voorbeeldje geven:
We hebben al wat gesproken met software leveranciers en 2 hebben expliciet 2 pakketten genoemd:
Typo3: PHP gebaseerd
dotnetnuke:.NET technologie

om J2EE niet helemaal uit te sluiten:
http://www.jboss.org/products/nukesjboss


(en in de .NET vs J2EE discussie ga ik me niet mengen aangezien ik .NET ook niet zo goed ken, maar de J2EE trolls hier zijn mooi afgeslagen vind ik. Keuzevrijheid rouleert )

[Infinitive]

Je kan je bovendien nog afvragen of je wel een multi-tier enterprise applicatie wilt... tenminste, als iemand met Typo3 aan komt zetten, dan zullen je business rules niet al te ingewikkeld zijn en erg veel database functionaliteit zul je ook niet nodig hebben.

[djluc]

Infinitive schreef op 11 augustus 2004 @ 19:54:
Je kan je bovendien nog afvragen of je wel een multi-tier enterprise applicatie wilt... tenminste, als iemand met Typo3 aan komt zetten, dan zullen je business rules niet al te ingewikkeld zijn en erg veel database functionaliteit zul je ook niet nodig hebben.

Graag hier enkele argumenten voor Voorbeeldje was trouwens omdat we toch redelijk ingewikkelde dingen gezien hebben die met Typo3 mogelijk waren.

Leuk dat enkele mensen zelf al een aanbod doen om er eens naar te kijken, maar nog steeds heb ik niet echt antwoord op mijn vraag:
Hoe kan ik kijken welke het beste geschikt is voor ons?

[Infinitive]

djluc schreef op 11 augustus 2004 @ 21:19:
Graag hier enkele argumenten voor Voorbeeldje was trouwens omdat we toch redelijk ingewikkelde dingen gezien hebben die met Typo3 mogelijk waren.

Typo3 is in mijn ogen een eenvoudige user-unfriendly_{flame intended} CMS. Het biedt mogelijkheden om door de gebruikers zelf pagina's met tekst te vullen, in lijstjes te zetten, etc. Voor code geldt hetzelfde. Maar daar houdt het bij op. De rest zal via php scripts geregeld moeten worden.

Als ik het idee van je applicatie doorlees heb je toch wat gegevens die in de database staan zoals een dossier, offertes, etc. Ofwel, in feite komt het met de CMS oplossing er op neer dat je eigenlijk alleen PHP + database gebruikt; het CMS gebeuren is verder alleen voor de opmaak een hulpmiddel. Typo3 komt samen met MySQL, dus dat zal dan ook wel als database backend aangedragen worden.

Deze oplossing leidt tot een 2-tier oplossing. Je hebt je php front-end en je mysql backend. Nu ben ik persoonlijk niet zo gecharmeerd van MySQL. Als je een 2-tier oplossing gebruikt en je wilt toch de business rules scheiden van je front-end (bijv. het plaatsen van orders en alle checks die daarbij komen kijken), dan zul je vast Stored Procedures en Triggers willen gebruiken, die naar mijn weten niet door MySQL ondersteund worden.

Zo'n 2-tier oplossing kan je simpel en snel zo'n website in elkaar zetten. Visual Studio .Net heeft bijv. nog wat RAD tooltjes om snel ASP .Net sitejes te bouwen direct op de database. Ook interessant is het als je voor het vullen een tool als MS Access wilt gebruiken. Bijv. omdat toch maar een select aantal mensen de website onderhouden en je met Access nu eenmaal zeer geschikt is voor invoer van dit soort factureringsprogramma's.

Aan de andere kant heb je meer-dan-twee-tier oplossingen. Bekende frameworks hiervoor zijn J2EE en .Net Webservices. Vergeet verder Oracle niet, maar daar kan ik je niet veel over vertellen. Het idee hierbij is dat je een soort van driedeling maakt: client, appl server, database. De client ziet alleen de applicatie server en geen database. De applicatie server vormt de brug tussen client en verschillende databronnen. Op deze middel laag plaats je een stuk code die "Hooglevel" diensten aanbied aan de client. Bijvoorbeeld het plaatsen van een order. Het opvragen van gegevens van een gegeven factuur, etc. Hoe dat precies zit met database tabellen, controles, security, transacties, etc zoekt je middel laag uit. Er zijn nog wel meer abstractieniveau's te onderscheiden, maar dat is het ongeveer.

Zo'n multi-tier oplossing kost vooral bij simpele programma's veel meer programmeerwerk. Die middellaag is bij zoiets niet veel meer dan een doorgeefluik en dat moet toch allemaal geprogrammeerd worden. Voor ingewikkeldere applicaties waarbij je verschillende front-ends hebt, verschillende back-ends (meerdere databases, of programmatuur als microsoft exchange, etc), ingewikkelde business rules, is zo'n drie deling beter geschikt. Bovendien ben ik van mening dat een multi-tier applicatie beter onderhoudbaar is.

(wanneer te kiezen voor een 2-tier oplossing en wanneer voor een meer-tier-oplossing heb ik op GoT eigenlijk nog geen topic over gezien)

Anyway, de manier die je kiest heeft effect op bijvoorbeeld ontwikkeltijd, onderhoudbaarheid, kosten (evt. duurdere programmeurs). Neem zo'n keus dus ook in overweging. Vraag het expliciet aan je klant welke van de twee manieren ze aanraden, 2-tier of multi-tier.

Ik hoop dat deze post iets meer onderbouwing geeft. En als ik loop te blaten laten anderen dat vast wel weten

[djluc]

Zeer interessante en uitgebreide post, bedankt!

Typo3 is in mijn ogen een eenvoudige user-unfriendlyflame intended CMS. Het biedt mogelijkheden om door de gebruikers zelf pagina's met tekst te vullen, in lijstjes te zetten, etc. Voor code geldt hetzelfde. Maar daar houdt het bij op. De rest zal via php scripts geregeld moeten worden.

Ja, maar wat is daarvan het probleem? Of je een module toevoegt aan een framework in PHP of in een andere taal? Verder heb je het niet over mogelijkheden met betrekking tot authorisatie, afbeeldingen, "modern template building" zoals ze dat zo leuk noemen en nog een hoop andere zaken. Ik zie het eigenlijk niet zo zitten om vanaf 0 te beginnen en we hebben toch CMS mogelijkheden nodig voor enkele informatie pagina's.

De rest van je post is duidelijk. Enkele puntjes die ik nog wel even aan wil halen:

Ook interessant is het als je voor het vullen een tool als MS Access wilt gebruiken.

We willen webbased kunnen werken. Zowel webbased als met bijvoorbeeld Acces is een luxe maar niet noodzakelijk.

Mijn uiteenzetting van de applicatie die we willen hebben is overigens totaal niet volledig en heeft wel wat meer omhande. Dat is echter niet van toepassing op de doelstelling van dit topic.

[Infinitive]

djluc schreef op 11 augustus 2004 @ 23:45:
Ja, maar wat is daarvan het probleem? Of je een module toevoegt aan een framework in PHP of in een andere taal? Verder heb je het niet over mogelijkheden met betrekking tot authorisatie, afbeeldingen, "modern template building" zoals ze dat zo leuk noemen en nog een hoop andere zaken. Ik zie het eigenlijk niet zo zitten om vanaf 0 te beginnen en we hebben toch CMS mogelijkheden nodig voor enkele informatie pagina's.

Dat je CMS handig is voor het bouwen van een groot informatief deel van je website lijkt me duidelijk. Maar wat ik wilde benadrukken is dat voor de aspecten waarmee je aan komt dragen wat betreft webbased formulieren, Typo3 daar verder weinig over zegt: je kan met php scripts bouwen om de formulieren mee te vullen maar voor die scripts biedt het niets bijzonders aan. Op misschien die authorisatie na, maar je kan je afvragen in hoeverre je dat op dat niveau wilt afhandelen en in hoeverre je dat kan gebruiken.

Dit in tegenstelling tot enterprise-frameworks als J2EE en .Net bijvoorbeeld ook. Maar dat is in dit topic al tersprake gekomen dus dat laat ik even zitten.

Ik zie een CMS dus meer als een aanvulling, niet als een basis. Als het CMS bovendien wat faciliteiten aanbied op gebied van authorisatie en dergelijke, dan heb ik ook zo het idee dat je dat gaat mixen met je eigen datamodel. En ik weet niet wat voor consequenties dat kan hebben mocht je misschien naar een ander soort front-end overgaan.

Maar wat ik vooral bedoelde te zeggen is dat de Typo3 keuze zal leiden tot een 2-tier applicatie, terwijl in dit topic voornamelijk over meer-tiers-applicaties gesproken werd.

We willen webbased kunnen werken.

De reden waarom ik Access hier noemde is dat stel je hebt een groot aantal eenvoudige invoerschermen waar maar een paar personen mee hoeven te werken voor administratietaken. Dat zijn dergelijke schermen in Access nog altijd vele malen sneller geproduceerd dan als je dat moet maken in een webapplicatie. Dat webbased werken een hype is geef ik toe, maar vergeet ook de outjes niet.

[Verwijderd]

Infinitive schreef op 12 augustus 2004 @ 10:03:
Dat webbased werken een hype is ..

Hoe kom je daar bij?

[djluc]

Verwijderd schreef op 12 augustus 2004 @ 10:28:
[...]
Hoe kom je daar bij?

Volgens mij is het geen hype. Maargoed, er is gewoon besloten dat het webbased wordt en dat is ook beargumenteerd op degelijke wijze dus dat is iets wat vast staat. Zoals al eerder vermeld zou het een luxe kwestie zijn en nu niet van toepassing.

Verder is Typo3 een framework. Het CMS is gebouwd op dat framework. Maargoed het gaat nu even niet over het feit of Typo3 wel of niet geschikt is. Het gaat er over waarop we deze vergelijking gaan baseren.

Tot nu toe heb ik enkele punten genoteerd:
• platform/os/server
• multi-tiers-applicaties
• alarmnummer: "Het slag mensen dat met Java/.NET werkt is vele malen professioneler dan PHP`ers." //vrij subjectief

quote: alarmnummer

Als bedrijfszijnde kunnen open standaarden mijn rug op. Ik wil een goed product, voor een zo laag mogelijke prijs en politiekcorrectheid en dat soort onzin kan ik missen als kiespijn. Java? .NET? PHP? zal me worst zijn.. als ik maar krijg wat ik wil.

quote: zneek

Ik denk dat je je in dit hele verhaal beter kunt concentreren op de eisen aan de applicatie, dan op specifieke platformen. Zoals Alarmnummer al zegt, laat de specialisten zich daar maar over buigen. Jij geeft aan wat het moet kunnen, mag kosten en hoe uitbreidbaar het moet zijn. Dan vindt je implementatie partner wel een passende oplossing.

Deze 2 quotes volgen leuk op elkaar. We willen echter niet dat een bedrijf ons een bepaalde techniek op gaat leggen. We willen weten waar we het precies over hebben, hoe het in elkaar steekt. We willen zeker niet proberen om zelf zoveel kennis te vergaren zodat we de applicatie zelf kunnen bouwen maar willen wel weten waarom een bepaald platform voor ons hét platform is.

[ Voor 4% gewijzigd door djluc op 12-08-2004 11:12 ]

[kaandorp]

Maakt het eigenlijk wat uit waarin het geschreven wordt? Zolang het voldoet aan de eisen die jullie stellen... Jullie gaan het zelf toch niet verder uitbreiden o.i.d., toch?

Ik zou wel kiezen voor een algemeen bekend framework. Dat maakt het makkelijker overstappen naar een eventueel ander bedrijf in geval van een meningsverschil o.i.d.

[djluc]

kaandorp schreef op 13 augustus 2004 @ 00:46:
Maakt het eigenlijk wat uit waarin het geschreven wordt? Zolang het voldoet aan de eisen die jullie stellen... Jullie gaan het zelf toch niet verder uitbreiden o.i.d., toch?

In principe zou je ons alles aan kunnen praten. Wij willen weten waarop we zaken kunnen waarderen, waarom is x beter dan yop een beargumenteerde manier. Dit schijnt echter nogal ingewikkeld te zijn.

Ik zou wel kiezen voor een algemeen bekend framework. Dat maakt het makkelijker overstappen naar een eventueel ander bedrijf in geval van een meningsverschil o.i.d.

Zeker mee eens. Bij onze keuze voor een framework zal het aantal aanbieders zeker een puntje zijn.

[kaandorp]

djluc schreef op 13 augustus 2004 @ 01:00:
[...]
In principe zou je ons alles aan kunnen praten. Wij willen weten waarop we zaken kunnen waarderen, waarom is x beter dan yop een beargumenteerde manier. Dit schijnt echter nogal ingewikkeld te zijn.
[...]
Zeker mee eens. Bij onze keuze voor een framework zal het aantal aanbieders zeker een puntje zijn.

Wij hebben ooit een website laten ontwikkelen een aantal jaar geleden en die mensen hadden het gemaakt in sybase met c++ modules die een soort html uitpoepten. Koste toen enkele tienduizenden euro's.
We hebben dit door een ander bureau moeten laten herschrijven, omdat niemand anders iets kon met de modules. Nu is het ASP met MySQL geworden en dat draait prima. Voordeel is dat het zo door een ander bureau overgenomen kan worden.
Nog een tip! Leg vast wie de eigenaar wordt van de broncode. Zodat je er altijd mee verder kunt na failliesement van de bouwer o.i.d. (Heb ervaring )