Hoe om `n dinamiese webwerf te bou

Die aspekte van hierdie onderwerp is so breed en hul moontlike benaderings is so gevarieerd dat enige realistiese reaksie op die onvermydelike vrae slegs op algemene vrae kan dui.

conținut

Stappe
Wenke
Waarskuwings

Baie mense, vandag wil en verwag om dinamiese webwerwe (aangedryf deur data) te bou, wie se argitektuur vinnig nuwe materiaal, hersienings en interaksies met besoekers kan akkommodeer. wikiHow, byvoorbeeld, is `n dinamiese webwerf. Alhoewel die doel van kwaliteitsprojekte binne die bereik van enige ywerige persoon is, sou dit `n fout wees om te onderskat wat uiteindelik `n wesenlike uitdagende taak is, veral ten opsigte van die tegniese voorwerpe van enige moontlike projek. Selfs die eenvoudigste dinamiese webvoorwaardes vereis vaardighede in verskillende dissiplines.

Om die noodsaaklike doelwitte te bereik, kan niemand afwyk van `n goeie ontwerp vir die databasis nie. Die voorbereiding van hierdie dissipline is reeds `n wesenlike (maar nie eksklusiewe) deel van die werk nie. Sodra ons `n opsomming van die doelwitte van die projek het, moet ons goeie middele sien om dit te bereik. Dan moet ons die programmeertaal of gereedskap kies, gebaseer op `n visie van die ideale argitektuur vir die projek.

Om die algemene prentjie van die begin af te sien is die mees fundamentele vaardigheid van almal.

stappe

Prent getiteld Bou `n dinamiese webwerf Stap 1

Bepaal watter tipes gereedskap en prosesse jou doelwitte sal bereik. Aangesien die kern van enige dinamiese web teenwoordigheid sy databasis en dataverwerking is, is ons eerste belangrike doel om langtermynbesluite oor die databasis-enjin te maak. Dit is nie `n goeie idee om te hoop dat die besluit liggies gebaseer word slegs op `n skynbaar redelike aanvanklike vorm nie.

Die belangrikste doel van hierdie eerste besluit is om ons projek op `n manier te beplan (met gereedskap en databasis enjins) wat aan u behoeftes voldoen onder die manier waarop u die regte aanvanklike besluite geneem het. doeltreffend en sonder enige obstruksies op die aanvanklike basisse. Dit beteken dat ideaal, byvoorbeeld, die enjin van die databasis wat jy kies nie net die maklikste, of wat blyk te wees eenvoudiger wees om vandag te sit, van die begin af, moet `n enjin wat al eise ondersteun word verdere verwerking.
Soms raak kommersiële oorwegings die keuses verder. Watter enjins benodig meer onderhoud (en koste)? Watter enjins is feitlik onderhoudsvry om die verwerkingsdoelwitte vir `n uiteindelike projek te behou? Oor die algemeen is die patroon wat volg om die motor te kies wat gebaseer is op een van die twee moontlike reëlings.
Om dit te doen, moet jy eers `n tabel maak van die basiese behoeftes van die tabelle. `N Professionele sal nie eers hierdie kaart moet saamstel nie (ongeag of dit honderde of duisende tafels betref), want hulle sien gewoonlik dadelik of die toekomstige argitektoniese behoeftes wat u moet ondersteun, gefokus is op lees of skryf. Dan sal u `n toepaslike databasis kies, gegrond op hierdie algemene ingesteldheid, en dalk ook op u smaak en persoonlike ervaring, aangesien dit sekere ontwikkelingsinstrumente behels. MySQL is gewoonlik die opsie vir implementerings wat gefokus is op lees. Baie ontwikkelaars soek na databasisse soos PostgreSQL vir betroubare implementerings wat op skryfwerk gefokus is. Ons sal ons bepalings ontwikkel ten opsigte van hierdie belangrike instrumente deur noukeurige navorsing en op die bronne van algemene ondervinding van die sagteware-ontwikkelingsbedryf. Oor die algemeen kan jy koste vermy, want daar is baie goeie gratis gereedskap. Wat ons op soek is, is prestasie in omgewings gefokus op lees of skryf, betroubaarheid, eenvoud, administrasie verminder, en vinnige integrasie met potensiële sagteware-ontwikkelingshulpmiddels.

Prent getiteld Bou `n dinamiese webwerf Stap 2

Kies die gereedskap vir sagteware-ontwikkeling. Daar is twee patrone om te oorweeg wanneer instrumente vir sagteware-ontwikkeling gekies word. Die gereedskap vermoedelik maklikes is selde maklik om waar te wees wanneer `n projek onvermydelik die dop breek van die ontwikkeling en funksionaliteit waaraan die gereedskap behoort maklikes is gewoonlik beperk. As jy iets buite die kapasiteit van die gereedskap wil doen Maklik, hoe om vertaalparameters of taal in dinamies gegenereerde URI`s in te sluit, kan dit so moeilik wees dat uiteindelik uiters gesofistikeerde programmeringsvaardighede benodig word om die gereedskap te kan dwing maklik om meer komplekse take uit te voer. Ons moet ons gereedskap bemeester om goeie projekte op te bou. Dit maak nie maklike gereedskap die beste opsie, of gesofistikeerde gereedskap nie, `n moeilike voorstel. Die ontwikkelingsval maklik beteken gewoonlik beperkings waarvan die oorwinning te duur sal wees in die onvermydelike ontwikkeling van die projekte. In die algemeen, vind ons dat meer gesofistikeerd en kragtige instrumente is aanvaarbaar patrone (of het `n verskeidenheid van voorwerpe en biblioteke beskikbaar) nie net verlig die onvermydelike versperrings wat vir gereedskap sou ontstaan makliker, maar ook om die Om daar te kom is `n baie meer direkte proses. Wanneer ons die omvang van beskikbare gereedskap ondersoek, word minder uitputtende modelle gewoonlik in die konsepte van aanvanklike ontwikkeling aangebied, en beter konsepte word aangebied as gereedskap later opduik (of hulle sal nie die kans hê om te oorleef in markte wat reeds gewen is nie). As ons `n sogenaamde maklike instrument kies, is dit regtig `n ontwikkelingspatroon wat bestuurbaar en vry van moontlike obstruksies is. Die paradoks vir die neofiet is die moeilikheid om te visualiseer na die toekoms om die programmeringsobstruksies in `n sekere stel gereedskap te sien. My persoonlike neiging, en volgens my waarnemings, is dat die beste gereedskap die sterkste is en dié wat die minste beperkings bied ten opsigte van projekfokus. Dan, die vryheid om te ontwikkel wat jy wil hê en nodig het dikwels beteken die oortreding van die algemene model van die oënskynlik eenvoudige gereedskap, wie se uitdagings kan kom om die gemoedere van ingenieurs veterane en gesofistikeerde sagteware breek, want om te slaag in so `n taak beteken die bereiking dat die model eenvoudig doen iets waarvoor jy nie `n aangebore vermoë het nie. Is Ruby byvoorbeeld `n eenvoudiger instrument as die basiese C + + of die C #? Nee. Nie regtig nie, veral as jy die eenvoudige Ruby-model moet breek om belangrike funksionaliteit te kry. Soos Ruby, GCC is gratis vir Linux en OSX. Ruby kom ook vir OSX, jy moet dit net in jou stelsel ontdek. Van die gereedskap veronderstel Maklik, my persoonlike keuse is Ruby. Van die baie gesofistikeerde gereedskap sal C ++ en C # steeds op die lang termyn oorheers - en die waarheid is dat hulle slegs voertuie is om te ontwikkel as obstruksies. So moet jy jouself voorberei om ernstig te studeer, want ongeag die pad wat jy kies, moet jy nie net jou gereedskap bemeester nie, maar ook die potensieel beperkende modelle waarmee daardie gereedskap uiteindelik in die pad sal kom. Ruby is waarskynlik baie skoner as byna al haar "maklike" eweknieë. C + + is die ongeëwenaarde hulpmiddel by uitstek - en trouens, ervaar veterane sal na ongeëwenaarde projekte waarskynlik met veel minder probleme verkeer as as hulle dieselfde doelwitte probeer bereik met `n sogenaamde maklike hulpmiddel. Op die ou end sal ontwikkelaars wat hierdie waarneming vergeet, duur betaal: óf die instrument meer kies Maklik, of bekommerd minder oor struikelblokke met die mees gesofistikeerde gereedskap. In laasgenoemde geval kan jy die FastCGI-voorwerpe bemeester, die bal neem en hardloop. Groter konsepte word dikwels met klein kode geïmplementeer. Ja, eenvoudige gereedskap beweer dieselfde te doen, maar op te los van probleme op `n manier wat uiteindelik veroorsaak dat hulle van hulle afwyk, wat lei tot baie moeilike uitdagings om te oorkom, sowel as prestasie beperkings wat C ++ kan oplos.

Prent getiteld Bou `n dinamiese webwerf Stap 3

Terwyl ons hierdie vrae oplos, sal ons noodwendig die basiese modelle moet ondersoek om projekte te ontwikkel van die aard wat ons wil hê. Dit beteken dat ons die beste literatuur moet gebruik vir die gereedskap wat ons wil vergelyk, en gee ons konsep ten minste `n vorm waarin dit deur een of ander stel gereedskap aangespreek kan word. Voordat jy Ruby kies, kan jy byvoorbeeld belangrike boeke soos "The Ruby Programming Language" (Ruby programming language) en "Agile Web Development with Rails" (Agile Web Development with Rails) lees. U aanvanklike studie behoort nie net die gereedskap te bemeester nie, maar dit moet u ook wys hoe om daar te kom, hoe u die gewenste funksionaliteit kan voorsien met die gereedskap wat u kies. Dit is `n uitdagende taak vir beginners. As jy gaan om `n ontwikkeling omgewing vermoedelik maklik met die beste van die beste te vergelyk, sal jy moet ook evalueer die beste gereedskap C. As jy regtig wil `n veteraan-ingenieur te word, sal jy kies C vir sy gebrek aan beperkings. Is C regtig harder? Nee. Die sintaksis is dit, sintaksis. Uiteindelik moet u die uitdrukking van dieselfde funksionaliteit bemeester - en in werklikheid is die taalfamilie C uitstekend. Die moeilikheid om met C ++ uit te presteer, is om modelle te kry waarop jy dalk moet voortbou. `N uitstekende begin, vir byna 15 jaar was die oorspronklike komponente van FastCGI, wat beskikbaar is in Borland se CPPBuilder, waarskynlik die beste C + + vir Windows. Selfs beginners van C kan verby hierdie objek-georiënteerde benaderings gaan, want die algemene model van volhoubare funksionaliteit is gebou op dieselfde dinge waaraan jy gaan werk. Jou werk sal `n baie vryer vloei hê as wat jy met Ruby kan hê, byvoorbeeld, wanneer jy die Ruby-model in jou benadering moet breek of oorkom. Aan die ander kant versnel Rails steiger tegnieke baie van die beginner se werk, indien en slegs as die projek inpas by die algemene vorm van Ruby and Rails. Byvoorbeeld, jy kan rudimentêre sekuriteitsbepalings instel, wat in alle Ruby-koppelvlakke erken word, maar jy sal uiteindelik duisende lyne Ruby se outomatiese kode vir elke tabel wat jou aansoek onderhandel, herschryf. Is dit so eenvoudig? Wel, ek doen `n Windows redakteur genoem NoteTab Pro, werk op Ruby voorwerpe wat in `n gesofistikeerde OSX- stelsel daar makros wat my resensies maak miskien in `n tweede, die verpersoonliking duisende lyne van kode in byna dubbel. Net so is dit in relatief eenvoudige basiese funksionaliteite, waaraan `n projek beperk word. Die feit is dat ons in C ++ ons eie voorwerpe kan skryf om hierdie take op `n werklike universele manier te hanteer. Jy moet dit nooit eers herhaal nie. Dit is die vergoedings. Op die ou end is die objekgeoriënteerde C die mees kragtige en doeltreffende instrument. Dit beteken ook dat dit die een is wat minder werk kos.

Maak nie saak wat jou keuse van gereedskap is nie, daar is geen manier om te verhoed dat jy op `n redelike domein van HTML en CSS staatmaak nie. Oor die algemeen verander veteraan-ontwikkelaars na W3C.org vir belangrike materiaal.

wenke

Daar is niks wat `n omvattende studie en evaluering kan vervang nie.
`N belangrike deel van ons uitdaging sal wees om die beste hulpbronne te gebruik. Ek sal Ruby begin - en as jy wil presteer, moet jy die C-georiënteerde objekgeoriënteerde tale evalueer en die omgewings waarin goedgeskrewe projekte al jou eweknieë beter presteer.

waarskuwings

Moenie dink dat `n skynbare kortpad jou werk eintlik sal versnel nie. BAIE dikwels is die teenoorgestelde waar.
`N Bykomende belemmering om eenvoudige gereedskap regtig te bemeester, is onprofessioneel in baie forums. Daar is `n groot verskil tussen `n professionele se kennis en die gevorderde vaardighede wat jou so dikwels uit die regte pad kan lei. Die beste inligtingsbronne is gewoonlik die mees erkende eweknieë, nie die vermeende meesters van sogenaamde eenvoudige gereedskap wat net aanbeveel om te bly met die enigste patroon wat hulle ken. Die hoofrede waarom `n mens vrae na die forums stuur, is wanneer dit nodig is om die model wat in die sogenaamde eenvoudige benadering bestaan, te oorskry (en dus te breek). Wanneer u hierdie behoeftes onvermydelik teëkom, sal u die beste advies nodig hê.

Deel op sosiale netwerke:

Verwante