Rails on Rackiga ühilduv raamistik, mis on keskendunud kiirele rakenduste arendamisele. Kahjuks põhjustavad "kõik karbist välja" lähenemine ja pime Rails-käitumine sageli rakenduskoodi kvaliteedi langust nii vastuvõtu (loetavuse) kui ka toimimise osas.
Populaarsed Rails ja Rails-tee probleemid
- marsruutimine,
- before-actions,
- suured tegevused kontrollerites,
- privaatsed meetodid kontrollerites,
- üks kord kasutatud mixins,
- loogika seisukohtades,
- ActiveRecordi tagasikutsud,
- Assotsiatsioonid,
- "rasvased mudelid".
Täiendavad probleemid
- Aktiivse kirje valideerimine,
- kaudne üle selgesõnalise,
- DRY kuritarvitamine,
- delegatsioonid ühendustele,
- teenusekutsed mudelites.
Alternatiivid Rails'ile
Kui tegemist on Rööpad aastal Ruby maailmas on meil mitu alternatiivi. Teised Rackil põhinevad raamistikud on järgmised: - Sinatra, – Roda, – Hanami.
Mis teeb nad ainulaadseks?
Nii Sinatra kui ka Roda pakuvad meile plokkide marsruutimise süntaksit, kuid marsruutimine Sinatras on nimekiri ja Rodas - puu. Mõlemas raamistikus peame me ise tegelema mudelikihi rakendamisega. Roda puhul on hea mõte kasutada Sequel gemi.
Roda on inspireeritud Sinatrast. See on iseenesest väga kerge, kuid sellel on palju pluginaid.
Hanami on kõige lähemal Rööpad kui tegemist on raamistikuga hõlmatud valdkondadega. Kõige olulisemad erinevused kasutuse osas on järgmised:
- kontrollerid sisse Rööpad vs. tegevused Hanamis,
- spetsiaalsed klassid/objektid, mis tegelevad konkreetse HTTP päringuga, mitte üks kontroller konkreetse ressursiga (mudeliga) seotud tegevuste jaoks,
- mudelikiht, mis põhineb repositooriumidel ja entiteetidel, eraldades püsivuse ülejäänud rakendusest, mitte aktiivse kirje muster.
Hanami versioon 1 piirab tugevalt ROMi kasutamist, millel ta põhineb (versioon 3, ja see on juba 5), nii et seal pakutud mudelikihti ei tasu kasutada. Kuna tegemist on aga väga avatud raamistikuga, siis on üsna lihtne rakendada seal mudelit oma.
Rails'i lisad
Tasub kasutada lahendusi, mis ei sõltu Rööpad ja on lähemal "puhtale" Ruby. Esitluses mainitud vahendid on järgmised:
- Sequel (ORM, alternatiiv ActiveRecordile),
- ROM (objekti kaardistaja),
- dry-rb raamatukogud: dry-validations, dry-system ja dry-monads.
Sequel on lihtne panna projekt, see põhineb pistikprogrammidel ja rakendab ka aktiivse kirje mustrit. Sellel on parem madala taseme päringute tugi kui Rööpad' ActiveRecord.
ROM kasutab Sequel'i, kuid selle kontseptsioon on tõlkida andmebaasi(de) kirjete ja Ruby esemed. Selle eesmärk on kiirus ja andmete ümberkujundamine. Eraldab selgelt püsivusekihi rakenduses.
Dry-rb raamatukogud on väga kasulikud tööriistad:
- Kuivvalideerimist on API-projektides väga lihtne kasutada ja see võimaldab suurt kontrolli sissetulevate andmete õigsuse üle,
- dry-system vajab arendajatel veidi pratcice'i ja kannatust, et sellest aru saada, kuid see võimaldab väga paindlikult hallata sõltuvusi rakenduses ja laadida projekti komponente eraldi; kui me tahame seda raamatukogu kasutada Rööpad, saame kasutada kuiva rööpaid,
- kuiv-monaadid on teoorias keeruline mõiste, kuid praktikas on see lihtsamini mõistetav, tulemuseks monaadid võivad olla suurepärane võimalus suurendada loetavust kood võttes arvesse konkreetseid juhtumeid, mitte hargnevaid if'e.
Järeldused
Kõige parem on kasutada Rööpad et te ei peaks kasutama Rööpad ühel päeval.
Allikad
Artiklid
Raamistik
Kalliskivid
Spetsifikatsioonid
Loe edasi:
Mis on Ruby on Jets ja kuidas seda kasutades rakendust luua?
Vuelendar. Uus Codesti projekt, mis põhineb Vue.js-l.
Codesti iganädalane aruanne parimatest tehnikaartiklitest. Tarkvara ehitamine 50 miljoni samaaegse pistikupesa jaoks (10)