レールおよびその他の輸送手段

よくあるRailsとRails-wayの問題

で言及されている問題： Shopifyに関する記事

• ルーティング
• ビフォア・アクション、
• コントローラーの大きなアクション、
• コントローラのプライベートメソッド、
• ミキシンは一度だけ使用される、
• ビューのロジック、
• ActiveRecordのコールバック、
• アソシエーション
• "太ったモデル"

その他の問題

• アクティブレコードの検証、
• 明示的より暗黙的
• DRYの乱用、
• 協会への委任
• モデルのサービスコール。

Railsの代替品

に関しては レールズ での ルビー の世界では、いくつかの選択肢がある。Rackをベースにした他のフレームワークには以下のようなものがある：- シナトラ, – ロダ, – 花見.

何が彼らをユニークにしているのか？

SinatraもRodaもブロックルーティング構文を提供してくれますが、Sinatraのルーティングはリストで、Rodaのルーティングはツリーです。どちらのフレームワークでも、モデルレイヤーの実装は自分で行う必要があります。Rodaの場合、Sequel gemを使うのがよいでしょう。

RodaはSinatraにインスパイアされている。それ自体はとても軽いが、プラグインがたくさんある。

お花見が最も近い レールズ フレームワークでカバーされる分野に関しては。使用上の最も重要な違いは以下の通りである：

• のコントローラ レールズ 対花見での行動、
• 特定のリソース（モデル）に関連するアクションのための1つのコントローラではなく、特定のHTTPリクエストを処理する専用のクラス/オブジェクトです、
• リポジトリとエンティティに基づくモデルレイヤーは、アクティブレコードパターンではなく、アプリケーションの残りの部分から永続性を分離する。

Hanamiのバージョン1では、ベースになっているROMの使用が強く制限されている（バージョン3、すでに5）ので、そこで提案されているモデルレイヤーを使う価値はない。しかし、非常にオープンなフレームワークなので、そこに独自のモデルを実装するのは非常に簡単だ。

Rails用サプリメント

に依存しないソリューションを使う価値はある。 レールズ より "純粋 "に近い ルビー.プレゼンテーションで言及されたツールは以下の通り：

• Sequel（ORM、ActiveRecordの代替）、
• ROM（オブジェクトマッパー）、
• dry-rbライブラリ：dry-validations、dry-system、dry-monads。

続編は プロジェクトプラグインをベースにしており、アクティブレコードパターンも実装している。これは レールズ' ActiveRecord.

ROMはSequelを使用しているが、そのコンセプトはデータベース内のレコードと ルビー オブジェクト。スピードとデータ変換を目指す。アプリケーション内の永続化レイヤーを明確に分離する。

Dry-Rbライブラリは非常に便利なツールだ：

• dry-validationはAPIプロジェクトで非常に使いやすく、入力されるデータの正しさを非常にコントロールしやすい、
• dry-systemは、開発者が理解するのに少し練習と忍耐が必要だが、アプリケーションの依存関係を非常に柔軟に管理し、プロジェクトのコンポーネントを分離してロードすることができる。 レールズドライレールを使えばいい、
• ドライ・モナドは理論的には難しい概念だが、実際には理解しやすい。 コード を分岐させる代わりに、特定のケースを考慮する。

結論

を使うのがベストだ。 レールズ を使う必要がない。 レールズ ある日のことだ。

情報源

記事

• Railsアプリのコード臭（Shopifyによる）
• 花見：レポツィトリア
• レールガイド

フレームワーク

• シナトラ
• ロダ
• 花見

宝石

• 続編
• ROM
• ビブリオテキ・ドライRB
• Ruby JSON スキーマ検証ツール (json-schema)
• ページ
• ロダウト
• ロドートレール

仕様

• ラック
• JSONスキーマ

続きを読む

Ruby on Jetsとは何か、それを使ってどのようにアプリを作るのか？

Vuelendar。Vue.jsをベースにしたCodestの新しいプロジェクト。

コーデストの技術記事週間ベストレポート。50M同時ソケットのソフトウェアを構築する (10)