問題タブ [dci]

私が最初にデータ、コンテキスト、インタラクション(DCI)について学んだのは、このブログ投稿でした。この概念に魅了された私は、次の Rails アプリケーションに組み込むことにしました。DCI は MVC と連携して動作するため、API を同時に RESTful にすることはそれほど難しくないと考えました。そこで、RESTful リソースを作成し、Reportさまざまなコンテキストで拡張しました。/app/contexts/Rails でコンテキストを実装する方法は、コントローラー アクションを拡張するモジュール用のディレクトリ を作成することでした。だから私のようにreports_controller.rb見える：

そしてapplication_controller.rb、コンテキストを次のように設定しますbefore_filter。

コントローラー コンテキストに加えて、拡張current_userしていることに注意してください。Role

仕組みは次のとおりです。

1. ユーザーがログインします。
2. ユーザーの役割はRegisteredUserです。
3. RegisteredUserのデフォルトのコンテキストはSearch(で定義されている/app/roles/registered_user.rb) です。
4. コンテキスト内Searchでは、ユーザーは公開されたレポートのみを表示できます。
5. ユーザーが「新しいレポートの作成」ボタンを押すと、コンテキストが変更され、のセッションSubmissionに保存されます。current_user
6. 次に、ユーザーは複数ステップのフォームからレポートを送信します。
7. ユーザーがフォームをステップ実行してレポートを保存するたびに、/app/contexts/submission.rbコンテキストがアクションを処理します。

その他のいくつかのコンテキスト (レビュー、編集など) と役割 (共著者、編集者など) があります。

これまでのところ、このアプローチはほとんどの場合うまく機能しています。しかし、欠点があります。ユーザーが複数のブラウザー ウィンドウを開き、そのうちの 1 つのコンテキストを変更すると、他のすべてのウィンドウが間違ったコンテキストになります。これは、ユーザーがマルチステップ フォームの途中でSearchコンテキスト内のウィンドウを開く場合に問題になる可能性があります。彼がフォームに戻って「次へ」をクリックすると、コントローラーはSearchコンテキストではなくコンテキストによって定義されたアクションを実行しSubmissionます。

私が考えることができるこれを回避する2つの可能な方法があります：

1. Reportリソースをコンテキスト名で名前空間化します。したがって、ユーザーは/search/reportsやなどの URL にアクセスします/submission/reports/1。これは私には RESTful ではないように思われるので、URL をできるだけきれいに保ちたいと思います。
2. コンテキスト名を非表示フィールドに入れます。この方法では、開発者は隠しフィールドをサイトのすべてのフォームに配置することを覚えておく必要があり、GET 要求では機能しません。

この問題を回避する他の方法、またはより良い全体的な実装はありますか?

このプロジェクトのことは知っていますが、私たちのニーズにはあまりにも限定的です。

完全なオブジェクト グラフのコンテキスト関連サブグラフを簡潔に指定するために Scala の型システムを使用する方法はありますか?

DCI は、多くの場合、かなり複雑なオブジェクト グラフを使用しているが、どのユース ケースでも、サブグラフのみを操作したい場合が多いと主張しています。と を持つ がFooありBarますBatが、ユースケース 1 の場合は のみを気Barにし、ユースケース 2 の場合はのみを気にしBatます。

たとえば、この構造があり、Role1 ユースケース requiresFoo->Bar->Baz->Binと Role2 ユースケース requiresがあるとしFoo->Bat->Baz->Buzます。

特性を使用して、単一のクラスでアクセスを制限する方法を簡単に確認できます。

ただし、ユースケースに関連するすべてのオブジェクトに対してこのパターンを繰り返す必要があります。(たとえば、BazInRole1to accessbinとBazInRole2to access が必要ですbiz)

私の質問は、これらの間違いやすい、名前空間が密集している特性をすべて記述することを回避する方法があるかどうかです。たとえば、次のようなコード (コンパイルされない) を想像できます。

Scala の型システムはこのようなことを行うのに十分な表現力があるようですが、私にはわかりません。

Rails アプリケーションのモデルを設計およびコーディングするためのさまざまなアプローチについて同僚と最近議論したことで、Railsのコンテキストで DCI に出会いました。

ただし、このサンプルアプリケーションを調べた後でも、その概念全体に頭を悩ませているようには見えません。

現在、 Rails アプリを作成するときは、多かれ少なかれ「本に従って」いる傾向があります。

そこでいくつかお聞きしたいのですが…

• DCI とは何ですか? また、プレーンな古い MVC (および Rails のバニラ ActiveRecord) よりも MVC と一緒に実装した場合の利点は何ですか?
• どうすれば Rails で実装できるのでしょうか (つまり、すべてのモジュールはどうなっているのですか) ?

編集

RoR のコンテキストで私の質問をさらに拡張したいと思います。Rails のモデルとコントローラーの間の別のレベルの抽象化が推奨されていますか? さまざまな規模のアプリケーションでどの程度普及していますか?

私は最新のプロジェクトでAngularJSを使用しています。ドキュメントとチュートリアルでは、すべてのモデルデータがコントローラースコープに配置されます。私は、それがコントローラーで利用可能であり、したがって対応するビュー内にある必要があることを理解しています。

しかし、私はモデルが実際にそこに実装されるべきだとは思いません。たとえば、複雑でプライベート属性がある場合があります。さらに、別のコンテキスト/アプリで再利用したい場合があります。すべてをコントローラーに入れると、MVCパターンが完全に壊れます。

同じことがどのモデルの振る舞いにも当てはまります。DCIアーキテクチャを使用し、動作をデータモデルから分離する場合、動作を保持するために追加のオブジェクトを導入する必要があります。これは、役割とコンテキストを導入することによって行われます。

DCI == D ata C ollaboration Interaction

もちろん、モデルのデータと動作は、プレーンなjavascriptオブジェクトまたは任意の「クラス」パターンを使用して実装できます。しかし、それを行うためのAngularJSの方法は何でしょうか？サービスを使用していますか？

したがって、この質問に帰着します：

AngularJSのベストプラクティスに従って、コントローラーから切り離されたモデルをどのように実装しますか？

RubyでDCIをコーディングする正しい方法に従って、DCIをいじってみました。自分のロールでデータオブジェクトにプロパティを追加したいと思っています。

たとえば、ユーザーオブジェクトがある場合。

ユーザーは顧客の役割を果たすことができます。

これを機能させるには、カートメソッドを追加する必要があります。ショッピングカートは本当にユーザーオブジェクトに属していますか？役割は、必要に応じてカートをデータオブジェクトに追加する必要があるように感じます。

DCIとは何か、またDCIをどのように使用すべきかをよりよく理解するために、Javaでいくつかの例を探しています。

ここの C++ で素晴らしい DCI の例を見つけましたhttp://fullloo.info/Examples/C++Examples/Account1/

DCI アーキテクチャに精通していない場合は、http://www.artima.com/articles/dci_vision.html でそれについて読むか、 http: //www.tele-task.de/archive/video/flash/ でいくつかの紹介をご覧ください。 16130/最後のリンクは OO の弱点に関するものです。

おまけの質問: DCI は本当に次のパラダイム シフトですか?

最近、Trygve Reenskaugによる DCI に関する次のプレゼンテーションを見ました 。うーん、ソフトウェアのさまざまなコンポーネント間の相互作用をコードで見ることは魅力的なアイデアです。

JavaScript で DCI の例を見つけようとしましたが、うまくいきませんでした。それから私は疑問に思い始めました。DCI パターンは、イベント化されたプログラミング パターンとは対照的ではありませんか?

イベント化されたプログラミングは、javascript でトレンディになっています。これは、デカップリングが可能であり、従来の継承の概念が js にネイティブではないためだと思います。イベント プログラミングの利点は理解できたと思いますが、イベント メッセージに従う必要がある場合、デバッグが非常に難しいことにも気付きました。

両者の概念は相反するというのが正しいでしょうか。それとも私はそれを間違えましたか？私が見逃した js での DCI の実装例はありますか? コンセプトを掘り下げるには何を見ればいいですか？

新しい Rails アプリケーションの動作を構築するために DCI に従っていますが、バリデーションをどこに置くべきかについて疑問があります。

従来、ActiveRecord モデルを使用してデータを管理する場合、バリデーションは AR から継承する特定のクラスで定義され、データ レイヤーの一部として適切に適合するように見えます。

ただし、私の目には、特定のロールの下でのみ発生する特定の検証を行うことは理にかなっています。オブジェクトがそのコンテキストにある場合にのみチェックし、他のすべての場合は無視する必要があります。これは基本的に、これらの検証を特定の役割で定義する必要があり、オブジェクトが意味のあるコンテキストで使用されている場合は、それらの役割モジュールでオブジェクトを拡張する必要があることを意味します。

これらの検証をロールに保持することは良い考えだと思いますか? もしそうなら、オブジェクトと同じクラスの他のインスタンスを汚染することなく、それらをどのように宣言しますか? ActiveRecord バリデーションを使用したい場合、それらはクラス レベルで宣言されているため、それらをオブジェクトに個別にアタッチすることはできず、ロール モジュールで "validate" インスタンス メソッドの再宣言を使用する必要があります (エラーをオブジェクトのエラー配列に直接)、または同様の手法を使用します。

DCI コンテキストを Web アプリケーションでいつどのように使用できるかを考えています。私はこの高レベルのユースケースを検討しています:

1. ユーザーは都市、到着、出発、部屋タイプを入力し、「検索」をクリックします。
2. システムはホテルのリストを表示します
3. ユーザーがホテルのロゴをクリックして詳細を読む
4. システムがホテルの詳細を表示
5. ユーザーが「今すぐ予約」をクリック
6. システムは支払いフォームを表示します
7. ユーザーは、顧客の詳細、請求情報を入力し、[送信] をクリックします。
8. システムは請求情報を検証し、予約確認を表示します。

これは非常に高レベルであり、確実に分解する必要があります。最初のステップ (1-2、3-4、5-6) は、いくつかの検索および REST アーキテクチャで処理できる単純なリソース要求のように感じます。だから私の最初の質問は、そのような場合に DCI コンテキストが必要なのか、単純な MVC で十分ではないのかということです。もちろん、「ホテル」データ エンティティが役割を果たすことはできますが、特にそれが唯一のアクターである場合は、実現可能だと思いますか?

最後のステップは、DCI が非常に役立つ可能性があることを示しています。今のところ、手続き的な方法で行う作業があります。(顧客の作成、ホテルへの予約の追加、確認メールの送信...)

これについてどう思いますか？私は正しい軌道に乗っていますか？

ASP.NET MVC フレームワークを使用して Context をインスタンス化し、そこで何か問題が発生した場合、例外をスローして Controller に処理させても問題ありませんか?

そして、ネストされたコンテキストの場合、外側のコンテキストは内側のコンテキストによってスローされた例外をキャッチできますか? 文脈がお互いを認識できないから考えているのですが、逆にエラーはエラー…ですよね？