OOP gedachtengang

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer Datawarehouse

.NET Developer Datawarehouse Werk jij als software developer het liefst met uitdagende systemen? Wil jij je steentje bijdragen aan een betere en efficiëntere zorg? Dan kun jij je bij onze vestiging in Amsterdam volledig uitleven als .NET Developer Datawarehouse. Jouw baan Je ontwerpt, ontwikkelt, ondersteunt en onderhoudt je eigen Datawarehouse module binnen HiX, onze ICT-totaaloplossing voor de zorg. Je schrijft objectgeoriënteerde code (we werken met Microsoft technologie, wat betekent dat je veel met C# gaat werken), speurt naar verbeteringen, werkt aan vernieuwende projecten, doet code reviews en voert testen uit. Een uiterst verantwoordelijke job, want dankzij jouw software kunnen zorginstellingen

Bekijk vacature »

Fulltime Softwareontwikkelaar Windows Applicaties

Fulltime Softwareontwikkelaar Windows Applicaties Velp-Grave Bij Zomerdam zoeken we een gedreven softwareontwikkelaar voor deze fulltime functie. Je wordt in de eerste plaats verantwoordelijk voor het ontwikkelen en testen van maatwerksoftware voor de machines die wij maken. Dat gaat zowel om het maken van Windowsapplicaties met databases, als het kunnen ontwerpen en bouwen van PLC-programma’s. Wat ga je doen? Tijdens het uitvoeren van je werkzaamheden heb je veelvuldige afstemming met de collega’s van je team en met de klant. Je bent in staat om op basis van wensen en eisen van de klant de juiste implementatiekeuzes te maken. Je volgt de

Bekijk vacature »

Ervaren .NET C# ontwikkelaar, inhouse, complex maa

Ben je als ervaren ontwikkelaar op zoek naar een analytische omgeving? Waar hoogopgeleiden en ervaren collega’s jouw kennis naar een hoger niveau kunnen tillen? Waar je met een leuk team samen aan innovatieve producten werkt? Dan zou de deze organisatie wel eens goed bij je kunnen passen. Voor een organisatie in Delft zoeken we momenteel een ervaren .NET C# ontwikkelaar. De organisatie richt zich op innovatieve en complexe maatwerk systemen met een maatschappelijke raakvlak. Hierbij moet je (afhankelijk van je niveau) mee kunnen denken met functionele en architectonische vraagstukken. De projecten kunnen uiteenlopend zijn en het is maar net wat

Bekijk vacature »

C# .NET Developer

Bedrijfsomschrijving Onze klant bouwt dynamisch en voornamelijk op .NET gebaseerde software voor diverse organisaties die zowel nationaal als internationaal opereren. De vestiging in Apeldoorn vormt onderdeel van een grotere organisatie met meerdere locaties in Nederland. De focus hier is om effectieve software te bouwen om data intensieve processen zo goed en overzichtelijk mogelijk te laten verlopen. Om dit soort processen goed te waarborgen en dat de juiste doelstellingen worden gehaald bieden zij velen oplossingen. Een voorbeeld hiervan is maatwerk mobile apps die gekoppeld worden aan zowel eigen software als die van diverse andere organisaties om de juiste data flows mogelijk

Bekijk vacature »

Junior Infrastructure Engineer - Space Unit

Junior Infrastructure Engineer - Space Unit Functiebeschrijving: Are you motivated by the opportunity to work in the exciting Space arena working on e.g. Earth Observation, Global Navigation Satellite Systems (like Galileo) and Satellite Communications? Galileo is Europe’s own global navigation satellite system and will consist of a constellation of 24 satellites and 6 spares. It is capable of providing a highly accurate, guaranteed global positioning service under civilian control. To strengthen our IT Support team responsible for the IT Support for the entire CGI-NL Space unit, we are looking for a Junior Infrastructure Engineer. You will join an international Space

Bekijk vacature »

PHP Developer

Bedrijfsomschrijving Het bedrijf waar je komt te werken is een familiebedrijf. Een van de grootste spelers in de internationale bloemenhandel. De cultuur binnen het bedrijf kan het beste worden omschreven als no-nonsense. We werken hard met elkaar om de klus te klaren en stoppen pas als het werk af is. Betrokkenheid, enthousiasme en collegialiteit staan hoog in het vaandel. Functieomschrijving Jij vult je dagen met enthousiasme voor het onderhouden, door ontwikkelen en testen van de webapplicatie. Je zult hierbij participeren in diverse projecten ten behoeve van uitbreiding en functionaliteit. Ook zul je API koppelingen opzetten met externe partijen en dit

Bekijk vacature »

Applicatiebeheerder

Stroom jij over van kwaliteit om wereldwijde waterproblemen aan te pakken? Kun jij wensen en eisen vertalen naar IT vereisten? En hou je van een dynamische omgeving, waarin jouw baan ertoe doet, jouw ideeën worden gehoord en waar je werkelijk het verschil kan maken voor jouw collega’s en het bedrijf? Zo ja, dan zijn wij op zoek naar jou. Als je daar bovenop niet bang bent voor Windows en Linux en je hebt kennis van Office 365, dan ben jij de perfecte kandidaat! Applicatiebeheerder technische affiniteit, gedreven, eigenaarschap Jij helpt ons door ervoor te zorgen, dat de applicaties soepel lopen.

Bekijk vacature »

Ervaren full-stack C# developer, .NET CORE, Typesc

Voor een ambitieuze en snelgroeiende organisatie de regio Rotterdam zijn we momenteel op zoek naar een .NET C# developer. De organisatie bestaat inmiddels ruim 15 jaar en heeft een systeem ontwikkeld waarmee bedrijven de informatie van grote en complexe projecten beter kunnen managen. Dit systeem is geheel webbased. Om hun globale ambities waar te maken zijn ze recentelijk begonnen het systeem geheel te herbouwen met de nieuwste technieken. Denk hierbij aan technieken als .NET CORE, Typescript, React, Kubernetes en Azure. Niet alleen betekent voldoende nieuwe technische uitdaging maar ook betekent dit dat je voor 80 tot 90% van je tijd

Bekijk vacature »

Medior/Senior Java Developer

Als Java Specialist zal je werken voor Accenture Liquid Studio. Samen met andere specialisten, vaak in muli-disciplinaire teams, zal je aan de slag gaan voor een groot aantal klanten verspreid door heel Nederland en in het buitenland. De opdrachten varieeren veel, maar hebben vaak als missie om een duurzame toekomst voor de volgende genaraties te creeeren. Accenture Liquid Studio bestaat uit een diverse, bekwame groep developers met verschillende achtergronden en overtuigingen. Accenture stimuleert het verrijken van de organisatie met talent die nieuwe inzichten en visies kan toevoegen. Accenture is vanuit Liquid Studio partner van de NLJUG en is actief op

Bekijk vacature »

Software Developer / PHP

Bedrijfsomschrijving Voor een organisatie in regio Eindhoven zijn wij op zoek naar een Software Developer met goede kennis van PHP. Het gaat om een software bedrijf dat te omschrijven is als informeel en open. De mensen die er werken zijn enthousiast, willen graag goede kwaliteit neerzetten, nieuwe technieken worden omarmt en alles is zo ingericht dat nieuwe tools/technieken gemakkelijk geïntegreerd kunnen worden. De organisatie is erg technisch georiënteerd, men gaat echt voor software development en heeft passie voor het vak. Er wordt geïnvesteerd in medewerkers door bijvoorbeeld opleidingen, cursussen en echt tijd voor onderzoek en innoveren. Je krijgt al snel

Bekijk vacature »

Developer - 12build

Wil jij jouw vindingrijke expertise inzetten voor revolutionaire innovaties in de cloud? Vind je de (internationale) bouwsector interessant en tenminste 5 jaar werkervaring? Ben je ambitieus en wil je je analyserende skills laten gelden in een professionele development-team? Dan is 12Build op zoek naar jou! Functie omschrijving In ons development team zijn we steeds bezig om ons eigen Saas platform uit te breiden en te verbeteren. Wij werken onder andere met: PHP Laravel Microservices TypeScript, JavaScript Vue.js (Nuxt.js) Docker API Gateway, OpenApi AWS Services (Fargate, SNS, SQS, S3) MySQL, ElasticSearch Bitbucket Pipelines Terrafrom Jira, Confluence, Slack Functievereisten In het kort

Bekijk vacature »

Senior C# Developer (NL) bij PostNL

Senior C# Developer (NL) Den Haag HBO/WO IT Professional "Als Senior C# Developer impact maken op de groeiende E-commerce markt met onze logistieke software. Je doet dit door complexe bedrijfskritische logistieke business processen te vertalen naar de ontwikkeling en uitbreiding van onze Cloud IT-platformen en software oplossingen in C# en AWS" Wat ga je doen? PostNL is becoming a postal tech company. Als Senior C# Developer ben je onderdeel van een multidisciplinair Business-IT-team bestaande uit onder andere een Lead Engineer, Developers en Solution Consultants. Samen zijn jullie verantwoordelijk voor het bouwen aan onderdelen uit onze logistieke software omgeving. Binnen het

Bekijk vacature »

Senior .NET Developer Datawarehouse

Senior .NET Developer Datawarehouse Bouw jij graag mee aan de nieuwe generatie van het datawarehouse-framework voor de zorg? En kent programmeren in C# geen geheimen voor jou? Dan pas jij perfect in ons team in Amsterdam. We bieden jou de kans om complexe uitdagingen op te lossen en te werken met de nieuwste technieken. Jouw baan Zorgprofessionals nemen belangrijke beslissingen op basis van data uit ons Datawarehouse. Als .NET Developer Datawarehouse ontwikkel jij een nieuwe generatie van het achterliggende framework. Je werkt dagelijks met zeer grote en complexe datasets en krijgt te maken met uitdagende issues, waarbij diepgaand onderzoek nodig

Bekijk vacature »

Junior BI Developer

Bedrijfsomschrijving De organisatie waar je komt te werken als BI Developer is een grote internationale financiële instelling. Met vele vestigingen in Nederland zijn ze een belangrijke speler op de financiële markt. Jij zal hoofdzakelijk op het kantoor in Amsterdam werkzaam zijn, maar het kan ook voorkomen dat je af en toe naar een andere vestiging gaat. Het bedrijf telt ongeveer 5000 medewerkers waarvan ruim 150 ICT'ers. Het team waar je in komt te werken als (Junior) BI Developer is een ambitieus BI team dat zich bezighoudt met lokale en internationale uitdagingen. Zo zit een andere Junior BI Developer, 2 Medior

Bekijk vacature »

Full stack Developer

Voor onze opdrachtgever zijn wij op zoek naar een Full Stack Developer. Je ontwikkelt en beheert software voor de aansturing en rapportage.. Om goed aan te sluiten bij de werkpraktijk vertaal je wensen van users naar prototypes, die je via een aantal iteraties tot werkende (web) software oplevert. Jij zal de nieuwe ontwikkelstraat verder uitbouwen en uitdragen. Typescript (Angular, node.js) en GraphQL is belangrijk in deze rol Het is nodig om goed aan te sluiten op de bestaande informatiesystemen en databases, die veelal gebaseerd zijn op een model-gedreven aanpak en in belangrijke mate worden uitgevoerd op het IBM i platform.

Bekijk vacature »

Pagina: « vorige 1 2 3 4 5 volgende »

Niels K

Niels K

21/06/2012 15:51:50
Quote Anchor link
Hartelijk dank voor de (positieve) reacties.

Allereerst even voorop gesteld dat de discussie op Twitter / Facebook ging over Zend en Symfony (Dus MVC en HTTP framework)

Daarom zei ik dat Wouter fan is van het HTTP framework Symfony en ik / kees en andere fan ben van het Zend MVC framework.

Quote:
Maar ik denk dat als je frameworks gaat presenteren, je twee betere keuzes had kunnen maken, namelijk micro-framework vs full-stack-framework


Ondanks bovenstaande verklaring, even nog een reactie op deze zin. Ik ben direct begonnen met het realiseren van projecten met Zend framework. Ik heb dus nooit een framework like Silex gebruikt. Ik kan dus niet beoordelen of het in het 'framework-leer-proces' beter is om te beginnen met een klein framework. Er zijn ook mensen die zeggen dat je beter kan beginnen met het bouwen van een eigen framework.

Mijn mening is, dat je pas een eigen framework moet bouwen als je geen framework kan vinden wat aan jouw eisen voldoet. Aangezien er behoorlijk wat frameworks zijn, is dat dus (haast) nooit het geval.

Wat de eisen van een framework zijn, laat ik in het midden.

Quote:
Because I really don't care whether Symfony2 is MVC or not. Probably because the MVC word is so overloaded and because nobody implements exactly the same MVC pattern anyway.


Ik twijfelde of ik die nog moest opnemen in mijn verhaal. Ik heb het niet gedaan aangezien Fabien het volgende zegt:

Quote:
I don't like MVC because that's not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework. That's the big deal. The fundamental principles of Symfony2 are centered around the HTTP specification.


Hij vind MVC niets aangezien het web zo niet werkt. Dat betekend dus dat hij een framework heeft gemaakt dat niet op het MVC pattern lijkt, aangezien hij daar niet van houd. Anders spreekt hij zichzelf tegen toch?

Quote:
Because I really don't care whether Symfony2 is MVC or not.


ORM:

Wat ik nog als discussie punt wil stellen. Is een ORM eigenlijk wel gewenst? Werkt dat nu echt zo lekker als het allemaal voorgeschoteld wordt. Is het niet veel mooier om gewoon query's te tikken zonder al die rompslomp?

Wat is nu precies het voordeel van een ORM?

Het voordeel van deze techniek is dat je code niets af hoeft te weten van het soort database dat gebruikt wordt. Hierdoor wordt het eenvoudig om van database te switchen. Daarnaast maakt dit de rest van je programma eenvoudiger. Je kan rechtstreeks met de tabellen werken zonder dat je ingewikkelde mappers of iets dergelijks hoeft te maken.

Maar, heb jij wel eens in een project van een type database moeten switchen? En als dat zo is, getuigd dat niet van een slecht voorbereiding?

En heb je met een ORM wel eens geprobeerd een zeer ingewikkelde query te schrijven? ééntje met flink wat joins, unions, subquery's (voor zover je subquery's mooi vind), group by's en nog wat lastige zaken?

Maar goed, zegt iemand, daar heb ik een oplossing voor. De meeste ORM's bieden ook de mogelijkheid om een normale query te tikken. Maar ben je dan niet je database onafhankelijkheid (Wat juist zo'n groot voordeel van een ORM is) kwijt? En op het moment dat je meerdere van zulk soort query's hebt, wordt je applicatie dan geen bende?

Het tweede 'voordeel' van een ORM is dat je tabellen naar objecten map waardoor de communicatie met de database een stuk eenvoudiger is. Echter, waarom moet je een ORM hebben om dit te bereiken? Waarom niet gewoon wat mooie data mappers? Zijn die nou zo moeilijk om te schrijven? Je bereikt dan toch precies hetzelfde? Het voordeel van wat mooie mappers is dat je gewoon lekker query's kan bakken zonder al die rompslomp eromheen.

Dat is naar mijn mening ook één van de grootste nadelen van een ORM. Doordat je een taal (SQL bijvoorbeeld) probeert te abstraheren / evenaren / nabouwen / geef het beest een naampje, wordt je code algauw enorm ingewikkeld. Waar is de tijd gebleven dat je nog netjes query's schreef?

Nog een nadeel van een ORM is, is dat ze nooit doen wat je exact wilt. De ene gebruikt backticks de andere doet het weer fout met haakjes, en noem maar op.

Ooit wel eens nagedacht over query optimalisatie? Weet jij exact hoe je dit doet in jouw ORM?

En als je nu iets database gerelateerd wilt schrijven? Hoe ga je dat doen? Schrijf je dan wel ineens een normale query? Is dat niet hypocriet dan?

Tot slot:

Hopelijk begrijp je dat bovenstaande verhaal een beetje overtrokken en sarcastisch geschreven is, maar ik hoop dat ik een (leuke) discussie oproep.

Mooi topic dit, daarvoor ben ik hier op PHPhulp!

Niels Kieviet
Gewijzigd op 21/06/2012 15:55:01 door Niels K
 
PHP hulp

PHP hulp

16/01/2021 09:28:48
 
Wouter J

Wouter J

21/06/2012 16:10:26
Quote Anchor link
@Niels, ah nu gaan we wel onze mening erin gooien! :) Het mooie van Symfony is dat hij het open laat of je een ORM gebruikt of niet. Je kan ook gewoon overstappen op Models of gebruik gaan maken van de gewone PDO/MySQLi objecten. Symfony laat in het midden wat je doet met die DB, dat is nou zo mooi. Beslis zelf niet wat jij het best vind, maar laat de uiteindelijke gebruiker beslissen welke 3th party hij gebruikt. Precies zoals met Twig, vind je Smarty mooier? Dat kan zo!

En van DB wisselen in een project slechte voorbereiding? Ik heb een tijdje met RoR gewerkt (die gebruikt Active Record) en daar is het de standaard dat je in develop mode een SQLite DB gebruikt en in productie mode een MySQL db (oid). Dus ik denk niet dat het iets te maken heeft met slechte voorbereiding...

Quote:
Mijn mening is, dat je pas een eigen framework moet bouwen als je geen framework kan vinden wat aan jouw eisen voldoet. Aangezien er behoorlijk wat frameworks zijn, is dat dus (haast) nooit het geval.

Natuurlijk, maar Silex is al een framework. Je hoeft niet zelf een framework te bouwen.

Even een voorbeeldje met een gastenboek systeem:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?php
require_once __DIR__.'/vendor/Silex/autoload.php';

$app = new Silex\Application();

// beetje Twig is altijd leuk
$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path' => __DIR__.'/views',
));


$guestBookMapper = new Guestbook\Mapper();

// als guestbook wordt opgeroepen in de url
$app->match('/guestbook', function() use ($app, $guestBookMapper) {
    // haal de 10 laatste berichten op
    $posts = $guetsBookMapper->getRecent(10);

    // render de show_all.twig page met de 10 recentste berichten
    return $app['twig']->render('show_all.twig', $posts);
});


// als guestbook/show/12 wordt opgeroepen (of elke andere id)
$app->get('/guestbook/show/:id', function(Silex\Application $app, $id) use ($guestBookMapper) {
    // kijk of bericht bestaat
    if ($post = $guestBookMapper->getById($id)) {
        // ja, hij bestaat, render show_single.twig met de gegevens van het bericht
        return $app['twig']->render('show_single.twig', $post);
    }
else {
        // nee, hij bestaat niet :( toon 404 pagina
        $app->abort(404, 'Dit bericht bestaat niet');
    }
});

?>
Gewijzigd op 21/06/2012 16:11:08 door Wouter J
 
Niels K

Niels K

21/06/2012 19:18:10
Quote Anchor link
Hoi Wouter,

Je draait om het punt heen ;-) Ik wil niet weten of het kan, ik wil weten wat jij er van vind. Ondanks mijn verhaal gebruik ik (af en toe) wel een ORM. Simpelweg omdat het makkelijk is.

Maar sinds ik een aantal artikelen gelezen heb, heb ik een andere mening gevormd. Ben jij het daar mee eens?

Quote:
Symfony laat in het midden wat je doet met die DB, dat is nou zo mooi. Beslis zelf niet wat jij het best vind, maar laat de uiteindelijke gebruiker beslissen welke 3th party hij gebruikt. Precies zoals met Twig, vind je Smarty mooier? Dat kan zo!


Zeker! Dat vind ik juist zo mooi aan Symfony, het laat je helemaal vrij, terwijl Zend dat juist niet doet. Alhoewel dat ook niet helemaal waar is. Met zend kan je ook bepalen wat je wel en niet doet. Dus wel of geen Doctrine, of wel of geen Smarty / Twig.

Alleen heb ik wel mijn bedenkingen omtrent een template parser. Waarom moet dat? Kan jij nu echte voordelen opnoemen?

Quote:
En van DB wisselen in een project slechte voorbereiding? Ik heb een tijdje met RoR gewerkt (die gebruikt Active Record) en daar is het de standaard dat je in develop mode een SQLite DB gebruikt en in productie mode een MySQL db (oid). Dus ik denk niet dat het iets te maken heeft met slechte voorbereiding...


Ik bedoelde te zeggen dat, dat juist één van de voordelen van een ORM is, maar dat je zulk soort situaties bijna niet tegenkomt.

Ik zeg altijd, een goede ontwikkelomgeving staat gelijk aan de live omgeving.

Quote:
Natuurlijk, maar Silex is al een framework. Je hoeft niet zelf een framework te bouwen.


Exact, maar dat bedoelde ik niet. Ik gaf alleen een reden waarom je evt een eigen framework / beheersysteem (Zie ook topic van Ozzie PHP van een aantal maanden geleden) kan schrijven.

Tot slot,

Code voorbeeld ziet er goed uit. Ik heb niets tegen Silex? Alleen ik probeer mensen na te laten denken i.p.v iets klakkeloos over te nemen. Je moet geen framework gaan gebruiken omdat andere mensen het aanraden of omdat andere mensen zeggen dat het een goed framework is.

Of ben je dat niet met mij eens?

Dankjewel voor je antwoord!

Niels Kieviet
Gewijzigd op 21/06/2012 19:18:59 door Niels K
 
Wouter J

Wouter J

21/06/2012 19:54:47
Quote Anchor link
Quote:
Je draait om het punt heen ;-) Ik wil niet weten of het kan, ik wil weten wat jij er van vind. Ondanks mijn verhaal gebruik ik (af en toe) wel een ORM. Simpelweg omdat het makkelijk is.

Maar sinds ik een aantal artikelen gelezen heb, heb ik een andere mening gevormd. Ben jij het daar mee eens?

Tja, zoals ik net al had gezegd heb ik nog geen groot project gemaakt en nog maar weinig met ORM's gewerkt, maar ik vind het wel fijn werken. En ja, er zitten nadelen aan, maar goed. Ik ben van mening dat aan elke libary/framework/app/pattern voordelen zitten en nadelen.

Quote:
Code voorbeeld ziet er goed uit. Ik heb niets tegen Silex? Alleen ik probeer mensen na te laten denken i.p.v iets klakkeloos over te nemen. Je moet geen framework gaan gebruiken omdat andere mensen het aanraden of omdat andere mensen zeggen dat het een goed framework is.

Nee, het was ook niet om jou van Silex te overtuigen. Het was om dit topic, en Jasper, een voorbeeld te geven van hoe het ook kan. Om een voorbeeld te geven van een micro-framework in gebruik. Juist omdat ik het volledig eens ben met het laatste dat je zegt. Je moet niet iets klakkeloos overnemen, je moet zelf opzoek gaan naar wat jij het best vind werken.
Daarom heb ik eerst aan alle 3 de frameworks gesnuffeld en vervolgens begonnen met Symfony. Waarom? Nou allereerst omdat de website en documentatie van Symfony er het best uitzag (ja, ben en blijf een webdesigner). En ten tweede toch zeker wel omdat de code veel moderner was met de nieuwste technieken (Silex maakt zelfs al gebruik van traits(!)).

En een template parser, goed of niet?
Zie daarvoor: http://www.phphulp.nl/php/forum/topic/template-engine-doen-of-niet-doen/83080/
Samengevat, ik hou van template parsers omdat:
1) het makkelijker is om te leren (voor designers), want (dit gaat over Twig) de syntax lijk redelijk op JavaScript. Iets wat designer met jQuery nu wel redelijk doorhebben.
2) het goede support heeft voor blocks en extenden van templates
3) autoescaping
4) designer beperken => zorg dat de designer niet alles kan doen zodat er geen grote fouten ontstaan
5)
 
Jasper DS

Jasper DS

21/06/2012 21:07:14
Quote Anchor link
Bedankt iedereen voor deze interessante bijdrage's, ik heb weer veel informatie kunnen verwerken. Ben momenteel dan toch begonnen met ZEND gewoonweg omdat ik merk dat het een veel gebruikt framework is en het sowieso handig is om het te kennen. Later als ik genoeg ervaring heb kan ik dan uitmaken wat nu het beste framework is op alle vlakken en mijn eigen mening vormen. Dat gaan nu nog niet, simpelweg omdat ik niet genoeg kennis heb!

Bedankt voor dit leuke topic en er zullen binnenkort waarschijnlijk wel wat ZEND vragen van mijn kant komen! ;-)

EDIT:

nog even over de gedachtengang, ik denk dat ik een beetje moeite heb met het opsplitsen van een echte pagina naar een view, controller, moddel.

Ik heb 2 pagina's : index.php (-> basis info + taal kiezen) , login.php (-> formpje om in te loggen) Zijn dat nu 2 aparte controllers of 1 controller met een action "login" als ik "Each page of the application is known as an action and actions are grouped into controllers" in mijn achterhoofd hou?
Gewijzigd op 21/06/2012 21:25:31 door Jasper DS
 
Wouter J

Wouter J

21/06/2012 21:42:50
Quote Anchor link
Nee, je moet de taken onderverdelen. Elke taak heeft zijn eigen controller. In een gastenboek heb je bijv. meerdere taken: Post taken (laten zien van een bericht, maken van bericht, bewerken v. bericht, verwijderen v. b.) en inlog taken (inloggen van gebruikers, dit wordt met Zend_Auth gedaan).

Deze 2 taken hebben ieder een eigen controller. Dan heb je nu al die dingen die er binnen zo'n taak gedaan worden, vaak de CRUD (create, read, update en delete). Dit zijn acties, ook heb je vaak een show actie.

Vervolgens heb je ook verschillende tabellen: users (voor inlog systeem) en posts (voor de berichten). Elke tabel krijg zijn eigen Model.

Ik vind die engelse quote een beetje vaagjes en niet echt geweldig...
 
Jasper DS

Jasper DS

21/06/2012 21:48:38
Quote Anchor link
Oke, dus een inlog-systeempje is nog iets te ingewikkeld?


Toevoeging op 21/06/2012 22:47:38:

Niels, ben ik op de goede weg?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?php

/**
 *  Deze classe doet ... ik heb geen idee
 *
*/


class Application_Model_DbTable_Guestbook extends Zend_Db_Table_Abstract
{

    protected $_name = 'guestbook';
    protected $_rowClass = 'Application_Model_Guestbook';

}


?>


Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<?php

/**
 * Dit is het Guestbook object waar ik al mijn info uit kan trekken via de controller, de info haal ik uit de Mapper
 */


class Application_Model_Guestbook extends Zend_Db_Table_Row_Abstract
{

    protected $id;
    protected $comment;
    protected $email;
    protected $date;

    public funtion __set($name, $value)
    {

        if(method_exists($this,$name='set_'.$name))
        {

        return $this->$name($value);
        }

        else
        {
            trigger_error($name.' is not avaliable .',E_USER_ERROR);
        }    
    }


    public function __get($name)
    {

        if(method_exists($this,$name='get_'.$name))
        {

            return $this->$name();
        }

        else
        {
            trigger_error($name.' is not avaliable .',E_USER_ERROR);
        }
    }


    // ik denk dat ik de setters en getter nog moet maken?
    
    public function getId()
    {

        return $this->id;
    }

    
    public function setId($id)
    {

        $this->id = $id;
    }

    
    // Wat moet er in deze classe nog worden toegevoegd?
}


?>


Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<?php

/**
 * Dit object haalt info uit de db en stopt dat in het Guestbook object
 */

class Application_Model_GuestbookMapper {

    protected $dbTable;

    public function setTable(Zend_Db_Table_Abstract $table)
    {

        $this->dbTable = $table;
    }


    public function getTable()
    {

        return $dbTable;
    }


    public function save(Application_Model_Guestbook $guestbook)
    {

        // Ik veronderstel dat ik hier mijn data uit het object Application_Model_Guestbook moet halen?
        $this->getTable()->insert($data);
    }


    public function fetchAll()
    {

        // Tabelobject? Wat is mijn tabelobject?
    }
}


?>
 
Niels K

Niels K

22/06/2012 19:01:23
Quote Anchor link
Wouter J:
Tja, zoals ik net al had gezegd heb ik nog geen groot project gemaakt


Ik had je uitgenodigd toch ? ;-)

Wouter J:
... en nog maar weinig met ORM's gewerkt, maar ik vind het wel fijn werken. En ja, er zitten nadelen aan, maar goed.....


Dat klopt, ze werken inderdaad fijn. Maar zodra je echt een moeilijke query wilt bakken wordt een ORM al gauw lastig. Zijn er mensen die deze ervaring delen?

Quote:
... Ik ben van mening dat aan elke libary/framework/app/pattern voordelen zitten en nadelen.


Daar heb je een goed punt! :-) Elke framework heeft wel zijn ditjes en zijn datjes. Maar een framework is iets anders dan een ORM ;-)

Wouter J:
Nee, het was ook niet om jou van Silex te overtuigen. Het was om dit topic, en Jasper, een voorbeeld te geven van hoe het ook kan. Om een voorbeeld te geven van een micro-framework in gebruik.


Ah, sorry dan heb ik dat verkeerd geïnterpreteerd. Zoals ik zei kan ik daar niet over oordelen omdat ik direct met Zend Framework begonnen ben. Dat heb je als je bij een bedrijf pas echt begint met programmeren.

Wouter J:
Juist omdat ik het volledig eens ben met het laatste dat je zegt. Je moet niet iets klakkeloos overnemen, je moet zelf opzoek gaan naar wat jij het best vind werken.


Kijk, we komen er wel uit ;p

Wouter J:
Daarom heb ik eerst aan alle 3 de frameworks gesnuffeld en vervolgens begonnen met Symfony. Waarom? Nou allereerst omdat de website en documentatie van Symfony er het best uitzag (ja, ben en blijf een webdesigner). En ten tweede toch zeker wel omdat de code veel moderner was met de nieuwste technieken (Silex maakt zelfs al gebruik van traits(!)).


Top, iedereen zijn eigen favorite framework toch? Ik vind zowel Zend als Symfony lekker werken. (Heb 1 project met Symfony gedaan)

Ik heb echter veel meer verstand van Zend Framework dan van het Symfony framework dus als ik wat dingen uitleg probeer ik het op basis van Zend Framework te doen.

Wouter J:
En een template parser, goed of niet?


Zie mijn reactie in het desbetreffende topic.

@Jasper PHP

Ik heb geen tijd meer om op jouw reactie te reageren. Its party time ;-) Ik zal morgen op jouw reactie reageren.
 
Reshad F

Reshad F

22/06/2012 19:27:07
Quote Anchor link
hmm ik vraag me af, ik ben met CI begonnen en dat is ook gebaseerd op MVC en ik begrijp dat wel grotendeels is het dan handig om op ZEND over te stappen of op Symfony aangezien de een MVC is en de ander niet?

of zou dit niet uit moeten maken.
 
Wouter J

Wouter J

22/06/2012 23:09:01
Quote Anchor link
Nee, heel groot is het verschil niet. Alleen net wat kleine stapjes. Je zou zelfs kunnen zeggen dat het HTTP pattern een implementatie is van het MVC pattern, want zoals Fabien al zei, niemand weet hoe het MVC goed moet worden geïmplementeerd: Het is een geweldig pattern, alleen zo onduidelijk als het maar kan zijn.

Quote:
Maar een framework is iets anders dan een ORM ;-)

Daarom zei ik ook framework/libary/app/pattern, ik denk dat een ORM daar wel ergens tussen valt :)
 
Reshad F

Reshad F

22/06/2012 23:14:18
Quote Anchor link
wat vond jij makkelijker uitgelegd/gedocumenteerd wouter? Zend of Symfony? en zeg alsjeblieft niet alleen maar Symfony omdat je er fan van bent :P
 
Wouter J

Wouter J

23/06/2012 00:08:23
Quote Anchor link
Symfony. Hun website leest makkelijker, straalt professionaliteit uit en is overzichtelijk. Na het lezen van een Symfony documentatie wil ik altijd meteen beginnen, ik kan me niet herinneren dat met Zend te hebben gehad...

Maar ben je al begonnen met symfony? Of begrijp je het niet? (vertel maar even in je eigen topic, houden we de zaken goed gescheiden)

Edit:
Even iets opgezocht waardoor je ziet dat ik niet de enige ben die dit vind:
Quote:
In addition to the content of the Quick Tour I also found the design of Symfony’s website to be quite appealing. Although it is said to not judge a book by its cover we humans tend to notice things that are pretty. The same is true of Symfony’s website. Its pleasing to look at, pleasing to use, and I felt a sense of professionalism and polish that made me feel safe to learn more about the code.

I spent a few nights reading in bed on my iPad the rest of Symfony’s tutorials and docs and finally felt confident enough to begin coding. I did begin doing some coding in Symfony and aside from the difficulty of learning a new project’s jargon I was actually having an enjoyable time using Symfony.
(bron)
Gewijzigd op 23/06/2012 10:16:49 door Wouter J
 
Roel -

Roel -

25/06/2012 22:00:26
Quote Anchor link
Ik snap het met die autoloader nog niet helemaal, het lijkt mij juist omslachtig.
De werking snap ik helemaal, alleen je gebruikt voor de eerste keer dat je een object aanmaakt een andere naam voor object, dat lijkt mij juist verwarrend.

Klopt dit?
 
Wouter J

Wouter J

25/06/2012 22:08:17
Quote Anchor link
Nee, je gebruikt altijd dezelfde naam.
 
Roel -

Roel -

25/06/2012 22:14:20
Quote Anchor link
Ook als je het in submappen plaatst?
Dan heb je /www/classes/User/User.php en als je dan new User doet, dan kom je daar uit?
 
Wouter J

Wouter J

25/06/2012 22:19:39
Quote Anchor link
Nee, daarom moet je die klasse een andere naam geven. Dus niet een klasse User maar een klasse User_User.

En, ja dat staat heel lelijk en ja dat kan veel mooier. Met namespaces:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
<?php
// lib/MyProject/User/User.php

namespace MyProject\User;

class User
{
   // ...
}
?>

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
// index.php

// registreer de autoloader


use MyProject\User\User;

$user = new User();
?>
 
Roel -

Roel -

25/06/2012 23:00:08
Quote Anchor link
Is dat dan niet hetzelfde idee als gewoon require typen? xD
 
Wouter J

Wouter J

26/06/2012 10:05:32
Quote Anchor link
Roel, het mooie van een autoloader is dat deze het automatisch doet. Hierdoor heb je nooit problemen met nog niet gedefinieerde klassen.
En het is lazy-loading: De klasse wordt pas ingevoegd als je hem nodig hebt, niet eerder.
 
John Cena

John Cena

26/06/2012 10:08:08
Quote Anchor link
En het staat ook fancyer, dat kun je niet ontkennen :)

Vind het toch mooier om er Application_Model_DbTable_Settings te typen als
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
<?php
require_once('/application/model/dbtable/settings.php'); ?>
 
Roel -

Roel -

26/06/2012 19:36:58
Quote Anchor link
Ik kan er met m'n verstand gewoon niet bij. Je gebruik bij je class definitie namespace en bij de instanciëring use?
 

Pagina: « vorige 1 2 3 4 5 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.