Rails アプリケーションのモデルを設計およびコーディングするためのさまざまなアプローチについて同僚と最近議論したことで、Railsのコンテキストで DCI に出会いました。
ただし、このサンプルアプリケーションを調べた後でも、その概念全体に頭を悩ませているようには見えません。
現在、 Rails アプリを作成するときは、多かれ少なかれ「本に従って」いる傾向があります。
そこでいくつかお聞きしたいのですが…
編集
RoR のコンテキストで私の質問をさらに拡張したいと思います。Rails のモデルとコントローラーの間の別のレベルの抽象化が推奨されていますか? さまざまな規模のアプリケーションでどの程度普及していますか?
DCI はパラダイムであるため、アプリケーションを設計する方法以上のものです。これは、モデル化とコードの構造化について考える方法です。DCI の重要な部分の 1 つは、システムの内容 (ドメイン モデル) とシステムの機能 (機能) を区別することです。DCI は、MVC と同じ問題を解決する別のアプローチではないため、最初の質問には実際には答えられません。Trygve Renskaug は MVC と DCI の両方の父であるため、MVC と DCI を同時に使用できますが、これは偶然ではありません。彼は最近、Google グループ 'object-composition' でこれと同様の質問に答えました。
あなたがリンクした例は、ロールをコンテキストに対して非公開にするなどの基本的なアイデアのいくつかに違反しており、実際には単一のコンテキストも見つけることができませんでしたが、それはコードの閲覧に短時間しか費やさなかったことが原因である可能性があります.
私は自分自身の RoR を知らないので、RoR の例を示すことはできませんが、fullOO にアクセスすると、Ruby と DCI 用に設計された最初の言語である Marvin の両方を含むさまざまな言語で書かれた例を見つけることができます。
編集「DCIとは何か」という質問に対する単純な答えはありません。OOPがパラダイムであるように、DCIはパラダイムです。どちらも同じルーツを持ち、上記の質問に答えるのは、「オブジェクト指向プログラミングとは」と答えるのと同じくらい複雑です。DCI はオブジェクト指向であり、すべての主要な OO 言語の OOP は実際にはオブジェクト指向ではなくクラス指向であるという事実によって、事態はさらに複雑になります。DCI は、実行時のオブジェクト間の相互作用がコンパイル時にコードに表示されるコードを生成することを目的としており、より一般的には、コードを読み取ることで実行時の動作を簡単に判断できるようにします。サイト_上記にリンクしたのは、DCI とは何かを説明することに専念しており、多くの言語での例もリストしています。ルビーもその一つ
EDIT Ruby と DCI に関する本が出版されています。著者は、オブジェクト構成とインサイトフルにかなり積極的です
DCIの中心にあるのは、 DCIが開発者に提供するコグニティブ ツールです。James Coplien/Trygve Reenskaugの素晴らしい講義をすべて見たかどうかはわかりませんが、概念に慣れていない人のために要点を抽出しようとします. それは、システムの相互作用するドメイン オブジェクト (データ エンティティ、またはシステムとは何か) から、オブジェクトに機能を注入することによってオブジェクト間のコラボレーションを仲介するファースト クラスの市民として、システムの動作を動作オブジェクト (システムが行うこと) に移動することです。ジャストインタイムのユースケースのコンテキストで。
BDD を考えてみてください。パーシスタンス レイヤーに高度に結合されたデータ オブジェクト全体に広がる機能の微粒子のように、多くのオブジェクトにまたがって動作をコーディングするのではなく、ユース ケース (ストーリー) のためだけに存在し、機能を注入して調整するまとまりのあるオブジェクト内で動作をコーディングします。これらのダムデータオブジェクトの相互作用。物理アーキテクチャの純粋な層のように、ゆっくりと変化するデータ オブジェクトには、常に持ち歩いている急速に変化する機能の実装が積み込まれているわけではありません。むしろ、Ruby は、ユースケースのコンテキストでのみ必要な場合に、実行時に動作をオブジェクトに簡単に挿入する機能を提供します。
ROR の例として、ほとんどのエントリがわずかな割合のリクエストでのみトリガーされる可能性があるイベント確率マトリックスがあるユース ケースにコントローラー アクションが関与している場合、肥大化した動作の重いオブジェクトのネットワークをインスタンス化します。データの考えられるすべてのユースケースに対してすべてのイベントを実行する知識は不要です。また、テキスト エディターで 18 個のファイルを掘り下げてインタラクションがどのように機能するかを理解する必要がないことと、すべてのロジックがコンテキスト オブジェクトによって提供されるインターフェイスのパターンに明確に抽象化されていることも明確な利点です。
レールのコントローラーとモデルの間の「別の」抽象化レイヤーに関する質問については、他のどれを参照しているのかわかりません。とにかく、はい。ぜひ。問題ない。設計パターンと Uncle Bobs のSOLID原則は、OO 設計において一般的に受け入れられているベスト プラクティスです。これらはどちらも、ポリシーと実装の間の疎結合の抽象化を強く促進します。どちらも、誰もが理解できる共通のフレームワークを提供するため、ローマ帝国の壊滅的な規模の壊滅的なブレインダンプを回避するのに役立ちます. 私にとって DCI は、同じタイプのコグニティブ フレームワークを提供しますが、システムをより簡単に理解し、効果的に処理できるようにするためのものです。これは、あらゆるオブジェクト指向デザイナーにとっての聖杯です。
Ruby / Rails： Clean RubyでのDCIの使用に関する本（現在進行中）があります。私は自分自身を通知リストに載せることを強くお勧めします-私はこの本の一部を読みました、そしてそれは本当によさそうです。
DCIはRailsの世界で受け入れられつつあり、過去3か月ほどでDCIに関する興味深いブログ投稿が多数あります。