Rails er en Rack-kompatibel ramme med fokus på hurtig applikationsudvikling. Desværre får "alt ud af boksen"-tilgangen og den blinde Rails-adfærd ofte applikationskoden til at miste kvalitet, både med hensyn til modtagelse (læsbarhed) og drift.
Populære Rails- og Rails-way-problemer
- routing,
- før-handlinger,
- store aktioner i controllere,
- private metoder i controllere,
- mixins brugt én gang,
- logik i visninger,
- ActiveRecord-tilbagekald,
- Foreninger,
- "Fede modeller."
Yderligere problemer
- Validering af aktive poster,
- implicit over eksplicit,
- misbrug af DRY,
- delegationer til foreninger,
- serviceopkald i modeller.
Alternativer til Rails
Når det kommer til Skinner i Ruby verden, har vi flere alternativer. Andre frameworks baseret på Rack omfatter: - Sinatra, – Roda, – Hanami.
Hvad gør dem unikke?
Både Sinatra og Roda tilbyder os en syntaks for blokrouting, men routing i Sinatra er en liste og i Roda - et træ. I begge frameworks skal vi selv håndtere implementeringen af modellaget. I Rodas tilfælde er det en god idé at bruge Sequel-perlen.
Roda er inspireret af Sinatra. Det er meget let i sig selv, men det har en masse plugins.
Hanami er tættest på Skinner når det drejer sig om områder, der er omfattet af rammerne. De vigtigste forskelle med hensyn til brug er:
- controllere i Skinner vs. handlinger i Hanami,
- dedikerede klasser/objekter, der håndterer en specifik HTTP-anmodning, ikke en controller til handlinger relateret til en specifik ressource (model),
- modellag baseret på repositories og entiteter, der adskiller persistens fra resten af applikationen, ikke det aktive record-mønster.
Hanami version 1 begrænser kraftigt brugen af ROM, som den er baseret på (version 3, og den er allerede 5), så det er ikke værd at bruge det modellag, der foreslås der. Men da det er en meget åben ramme, er det ret nemt at implementere sin egen model.
Supplementer til Rails
Det er værd at bruge løsninger, der ikke er afhængige af Skinner og er tættere på "ren" Ruby. De værktøjer, der nævnes i præsentationen, er:
- Sequel (ORM, alternativ til ActiveRecord),
- ROM (objektmapper),
- dry-rb-biblioteker: dry-validations, dry-system og dry-monads.
Efterfølgeren er nem at sætte i en projektDet er baseret på plugins og implementerer også det aktive record-mønster. Den har bedre understøttelse af forespørgsler på lavt niveau end Skinner' ActiveRecord.
ROM bruger Sequel, men dens koncept er at oversætte mellem poster i databasen(erne) og Ruby objekter. Det sigter mod hastighed og datatransformation. Adskiller klart persistenslaget i applikationen.
Dry-rb-biblioteker er meget nyttige værktøjer:
- dry-validation er meget let at bruge i API-projekter og giver god kontrol over korrektheden af indgående data,
- dry-system kræver lidt øvelse og tålmodighed for udviklerne at forstå, men det giver mulighed for meget fleksibel styring af afhængigheder i applikationen og indlæsning af projektkomponenter i isolation; hvis vi ønsker at bruge dette bibliotek i Skinnerkan vi bruge tørre skinner,
- tør-monader er et vanskeligt koncept i teorien, men i praksis er det lettere at forstå, resultatet monader kan være en god måde at øge læsbarheden af Kode ved at overveje specifikke tilfælde i stedet for forgrenede if'er.
Konklusioner
Det er bedst at bruge Skinner så du ikke behøver at bruge Skinner en dag.
Kilder
Artikler
Rammeværk
Ædelstene
Specifikationer
Læs mere om det:
Hvad er Ruby on Jets, og hvordan bygger man en app med det?
Vuelendar. Et nyt Codest-projekt baseret på Vue.js
Codests ugentlige rapport med de bedste tech-artikler. Bygning af software til 50 millioner samtidige sockets (10)