Populære Rails- og Rails-way-problemer

Problemer nevnt i: artikkel på Shopify

• ruting,
• før-handlinger,
• store handlinger i controllere,
• private metoder i kontrollere,
• mixins brukt én gang,
• logikk i visninger,
• ActiveRecord-tilbakekall,
• Foreninger,
• "feite modeller."

Ytterligere problemer

• Validering av aktive poster,
• implisitt over eksplisitt,
• misbruk av DRY,
• delegasjoner til foreninger,
• serviceanrop i modeller.

Alternativer til Rails

Når det gjelder Rails i Ruby verden, har vi flere alternativer. Andre rammeverk basert på Rack er blant annet - Sinatra, - Roda, - Hanami.

Hva gjør dem unike?

Både Sinatra og Roda tilbyr oss en blokkrutingssyntaks, men ruting i Sinatra er en liste og i Roda - et tre. I begge rammeverkene må vi håndtere implementeringen av modellaget selv. Når det gjelder Roda, er det en god idé å bruke Sequel-perlen.

Roda er inspirert av Sinatra. Det er veldig lett i seg selv, men det har mange plugins.

Hanami er det nærmeste man kommer Rails når det gjelder områder som dekkes av rammeverket. De viktigste forskjellene når det gjelder bruk er:

• kontrollører i Rails vs. handlinger i Hanami,
• dedikerte klasser/objekter som håndterer en spesifikk HTTP-forespørsel, ikke én kontroller for handlinger knyttet til en spesifikk ressurs (modell),
• modellaget basert på repositories og entiteter, som skiller persistens fra resten av applikasjonen, ikke det aktive arkivmønsteret.

Hanami versjon 1 begrenser sterkt bruken av ROM den er basert på (versjon 3, og den er allerede 5), så det er ikke verdt å bruke modellaget som er foreslått der. Men siden det er et veldig åpent rammeverk, er det ganske enkelt å implementere modellen din egen.

Tillegg for Rails

Det lønner seg å bruke løsninger som ikke er avhengige av Rails og er nærmere "ren" Ruby. Verktøyene som nevnes i presentasjonen, er

• Sequel (ORM, alternativ til ActiveRecord),
• ROM (objektkartlegger),
• dry-rb-biblioteker: dry-validations, dry-system og dry-monads.

Oppfølgeren er lett å sette inn i en prosjekter basert på plugins og implementerer også det aktive postmønsteret. Den har bedre støtte for spørringer på lavt nivå enn Rails' ActiveRecord.

ROM bruker Sequel, men konseptet er å oversette mellom poster i databasen(e) og Ruby objekter. Målet er hastighet og data transformasjon. Skiller tydelig ut persistenslaget i applikasjonen.

Dry-rb-biblioteker er svært nyttige verktøy:

• tørrvalidering er veldig enkelt å bruke i API prosjekter og gir god kontroll over riktigheten av innkommende data,
• dry-system krever litt øvelse og tålmodighet for utviklerne for å forstå det, men det gir mulighet for svært fleksibel håndtering av avhengigheter i applikasjonen og innlasting av prosjektkomponenter isolert; hvis vi ønsker å bruke dette biblioteket i Railskan vi bruke tørrskinner,
• tørr-monader er et vanskelig konsept i teorien, men i praksis er det lettere å forstå, og resultatet monader kan være en fin måte å øke lesbarheten til kode ved å vurdere spesifikke tilfeller i stedet for å forgrene ifs.

Konklusjoner

Det er best å bruke Rails slik at du ikke trenger å bruke Rails en dag.

Kilder

Artikler

• Koden lukter i Rails-apper (av Shopify)
• Hanami: repozytoria
• Rails Guides

Rammeverk

• Sinatra
• Roda
• Hanami

Edelstener

• Oppfølger
• ROM
• Biblioteki dry-rb
• Ruby JSON Schema Validator (json-schema)
• Pagy
• Rodauth
• rodauth-skinner

Spesifikasjoner

• Stativ
• JSON-skjema

Les mer om dette:

Hva er Ruby on Jets, og hvordan bygger man en app ved hjelp av det?

Vuelkalender. Et nytt Codest-prosjekt basert på Vue.js

Codests ukentlige rapport med de beste teknologiartiklene. Bygge programvare for 50 millioner samtidige stikkontakter (10)