Räls och andra transportmedel

Populära Rails- och Rails-way-problem

Problem som nämns i: artikel om Shopify

• routing,
• före åtgärder,
• stora åtgärder i controllers,
• privata metoder i styrenheter,
• mixins används en gång,
• logik i vyerna,
• ActiveRecord-anrop,
• Föreningar,
• "feta modeller."

Ytterligare problem

• Valideringar av aktiva poster,
• implicit över explicit,
• missbruk av DRY,
• Delegationer till föreningar,
• servicebesök i modeller.

Alternativ till Rails

När det gäller Räls i Ruby världen har vi flera alternativ. Andra ramverk baserade på Rack är t.ex: - Sinatra, – Roda, – Hanami.

Vad gör dem unika?

Både Sinatra och Roda erbjuder oss en syntax för blockrouting, men routing i Sinatra är en lista och i Roda - ett träd. I båda ramverken måste vi själva ta itu med implementeringen av modellagret. När det gäller Roda är det en bra idé att använda Sequel-pärlan.

Roda är inspirerat av Sinatra. Det är mycket lätt i sig, men det har en hel del plugins.

Hanami är den dag som ligger närmast Räls när det gäller områden som omfattas av ramverket. De viktigaste skillnaderna när det gäller användningen är följande:

• styrenheter i Räls vs. handlingar i Hanami,
• dedikerade klasser/objekt som hanterar en specifik HTTP-förfrågan, inte en controller för åtgärder relaterade till en specifik resurs (modell),
• modellskikt baserat på repositories och entities, som separerar persistens från resten av applikationen, inte Active Record-mönstret.

Hanami version 1 begränsar starkt användningen av ROM som den är baserad på (version 3, och det är redan 5), så det är inte värt att använda det modellager som föreslås där. Men eftersom det är ett mycket öppet ramverk är det ganska enkelt att implementera din egen modell där.

Kompletteringar för Rails

Det är värt att använda lösningar som inte är beroende av Räls och är närmare "rena" Ruby. De verktyg som nämns i presentationen är:

• Sequel (ORM, alternativ till ActiveRecord),
• ROM (objektmappare),
• dry-rb-bibliotek: dry-validations, dry-system och dry-monads.

Uppföljaren är lätt att sätta in i en projektDet är baserat på plugins och implementerar även det aktiva registermönstret. Det har bättre stöd för lågnivåfrågor än Räls' ActiveRecord.

ROM använder Sequel, men dess koncept är att översätta mellan poster i databasen (erna) och Ruby objekt. Det syftar till snabbhet och datatransformation. Separerar tydligt persistensskiktet i applikationen.

Dry-rb-bibliotek är mycket användbara verktyg:

• dry-validation är mycket enkelt att använda i API-projekt och ger stor kontroll över att inkommande data är korrekt,
• dry-system kräver lite övning och tålamod för att utvecklarna ska förstå det, men det möjliggör en mycket flexibel hantering av beroenden i applikationen och laddning av projektkomponenter i isolering; om vi vill använda detta bibliotek i Rälskan vi använda torra skenor,
• dry-monader är ett svårt koncept i teorin, men i praktiken är det lättare att förstå, resultatet monader kan vara ett bra sätt att öka läsbarheten av kod genom att överväga specifika fall istället för att förgrena om.

Slutsatser

Det är bäst att använda Räls så att du inte behöver använda Räls en dag.

Källor

Artiklar

• Kodlukt i Rails-appar (av Shopify)
• Hanami: repozytoria
• Rails-guider

Ramverk

• Sinatra
• Roda
• Hanami

Ädelstenar

• Fortsättning
• ROM
• Biblioteki torr-rb
• Ruby JSON Schema Validator (json-schema)
• Pagy
• Rodauth
• rodauth-räcken

Specifikationer

• Rack
• JSON Schema

Läs mer om detta:

Vad är Ruby on Jets och hur bygger man en app med hjälp av det?

Vuelkalender. Ett nytt Codest-projekt baserat på Vue.js

Codests veckovisa rapport över de bästa tekniska artiklarna. Bygga programvara för 50 miljoner samtidiga socklar (10)