タグ付けされた質問 「event-programming」

今日のUnityに関する講義の1つで、ユーザーがボタンを押した場合にすべてのフレームをチェックしてプレーヤーの位置を更新することについて説明しました。誰かがこれは非効率的だと言ったので、代わりにイベントリスナーを使うべきです。 私の質問は、プログラミング言語、またはそれが適用される状況に関係なく、イベントリスナーはどのように機能するのですか？ 私の直感では、イベントリスナーはイベントが発生したかどうかを常にチェックすると想定します。つまり、私のシナリオでは、イベントが発生した場合はすべてのフレームをチェックすることと同じです。 クラスでの議論に基づいて、イベントリスナーは異なる方法で動作するようです。 イベントリスナーはどのように機能しますか？

125 event-programming 

私は、コールバックを渡すか、プログラムの他の関数から関数をトリガーして、タスクが完了したら物事が起こるようにしました。何かが終了したら、関数を直接トリガーします。 var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; shovelSnow(); } しかし、私はプログラミングの多くの異なる戦略について読んでおり、私は強力であると理解しているが、まだ練習していないものはイベントベースです（私が読んだ方法は「pub-sub」と呼ばれていました）： var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; $(document).trigger('snow'); } $(document).bind('snow', shovelSnow); イベントベースのプログラミングの客観的な長所と短所を理解したいのですが、他の関数内からすべての関数を呼び出すだけです。イベントベースのプログラミングは、どのプログラミング状況で使用する意味がありますか？

65 event-programming 

ディレクティブ間で通信する方法はかなりあるようです。ネストされたディレクティブがあるとします。ここでは、内側のディレクティブが外側に何かを伝える必要があります（たとえば、ユーザーによって選択されます）。 <outer> <inner></inner> <inner></inner> </outer> これまでにこれを行うには5つの方法があります require: 親ディレクティブ innerディレクティブが必要になることがありouter、そのコントローラ上のいくつかのメソッドを公開することができディレクティブを、。だからinner定義では require: '^outer', link: function(scope, iElement, iAttrs, outerController) { // This can be passed to ng-click in the template $scope.chosen = function() { outerController.chosen(something); } } そして、outerディレクティブのコントローラーで： controller: function($scope) { this.chosen = function(something) { } } $emit 出来事 innerディレクティブができる$emitイベント、outerディレクティブは経由して、に応答することができます$on。そのため、innerディレクティブのコントローラーで： controller: function($scope) { …

61 design-patterns  event-programming  angularjs 

イベントはGUIプログラミングにのみ使用されますか？ 他の何かに何かが起こった場合、通常のバックエンドプログラミングではどのように処理しますか？

57 programming-languages  theory  event-programming  asynchronous-programming 

イベントループとは何かを理解しようとしています。多くの場合、イベントループでは、イベントが発生したことが通知されるまで何かをするという説明があります。その後、イベントを処理し、以前の操作を続行します。 上記の定義を例にマッピングします。イベントループで「リッスン」するサーバーがあり、ソケット接続が検出されると、そこからのデータが読み取られて表示され、その後サーバーは以前と同じようにリッスンを再開/開始します。 ただし、このイベントが発生し、「そのような」通知を受け取ることは、私にとって非常に重要です。あなたは言うことができる：「それはあなたがイベントリスナーを登録しなければならない「ちょうどそのような」ではない」しかし、イベントリスナーとは何か、何らかの理由で返されない関数です。イベントが発生したときに通知されるのを待っている独自のループですか？イベントリスナーもイベントリスナーを登録する必要がありますか？どこで終わりますか？ イベントは作業するのに最適な抽象概念ですが、単なる抽象概念です。結局、ポーリングは避けられないと思います。おそらく私たちはコードでそれをしていませんが、下位レベル（プログラミング言語の実装またはOS）が私たちのためにそれをしています。 基本的には、次の擬似コードになります。このコードは、十分に低い場所で実行されているため、ビジー待機を発生させません。 while(True): do stuff check if event has happened (poll) do other stuff これはアイデア全体に対する私の理解であり、これが正しいかどうか聞きたいと思います。私は全体の考えが根本的に間違っていることを受け入れることに心を開いています。その場合、正しい説明が欲しいです。

55 design  programming-languages  design-patterns  event-programming 

でイベント駆動型アーキテクチャイベントがシステムを介して送信されたときに各コンポーネントにのみ作用します。 ブレーキペダルとブレーキライトを備えた架空の車を想像してください。 ブレーキライトターンにそれが受信したときbrake_onのイベントを、そしてオフそれが受信したときbrake_offのイベント。 ブレーキペダルは、送信brake_onのそれが押下されたイベント、およびbrake_offの、それが解放されるイベントを。 これは、ブレーキペダルが既に踏み込まれた状態で車の電源が入る状況になるまで、すべてうまくいきます。ブレーキライトはbrake_onイベントを受け取ったことがないため、消灯したままになります。これは明らかに望ましくない状況です。デフォルトでブレーキライトをオンにすると、状況が逆転するだけです。 この「初期状態の問題」を解決するために何ができますか？ 編集：すべての応答をありがとう。私の質問は実際の車に関するものではありませんでした。車では、状態を継続的に送信することでこの問題を解決しました。したがって、そのドメインにスタートアップの問題はありません。私のソフトウェアドメインでは、そのソリューションは多くの不必要なCPUサイクルを使用します。 編集2：@gbjbaanbの答えに加えて、私は次のようなシステムに行きます： 架空のブレーキペダルは、初期化後、その状態でイベントを送信し、 仮想ブレーキライトは、初期化後、ブレーキペダルからの状態イベントを要求するイベントを送信します。 このソリューションでは、コンポーネント間の依存関係、競合状態、失効するメッセージキュー、および「マスター」コンポーネントはありません。

33 architecture  event-programming 

私の質問は、いくぶん教育されていない視点から来ています。 「メッセージパッシング」システムと「イベントベース」システムの相対的なメリットは何ですか。 なぜ一方が他方を選択するのですか？彼らの長所と短所は何ですか？ 「理論的に」だけでなく、「実際に」も知りたいです。 編集： 特定の問題： 小規模なサービスとして動作するプラグ可能なコンポーネントのシステムを構築したい（それぞれが小さなタスクを実行したり、情報を提供したりする）。 サービスは次のことができます。 1つのサービスの出力が別のサービスへの入力の1つとして機能できるように階層化される 前の文で述べたように、特定の入出力関係がなくても1つのサービスを別のサービスに含めることができるように、包含階層があります。 システムの目標は、別のシステムの低レベルイベントの単一のフローを高レベルの情報と機能に変換し、さらに単一のイベントを提供する他のシステムへのチャネルを提供することです。 これで十分でない場合、詳細を提供できます。 もう少し見て回った後。これとこれはおそらく、より良い私の状況を説明しています。 これは私の状況に適しているようです：http : //akka.io/

27 event-programming  message-passing 

プラグインがプログラムフローに反応できるようにするアプリを検討してください。 これを達成する2つの方法を知っています：フックとイベント 1.フック メインプログラムフロー内の空の関数の呼び出しを使用します。これらの機能はプラグインによってオーバーライドできます。 たとえば、Drupal CMSはモジュールとテーマで利用可能なフックを実装しています。file_copy関数でフックを実装する方法の例を次に示します。 function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } モジュールはmodulename_file_copy($file, $source)、module_invoke_allin によって呼び出される関数を実装できますfile_copy。この関数が終了すると、file_copy実行が再開されます。 2.イベント プラグインがリッスンできるイベントをアプリにディスパッチさせます。サブスクライブされているイベントを受信した後、プラグインはプログラムフローをインターセプトし、必要な操作を実行します。 たとえば、jQueryギャラリープラグインFotorama はいくつかのイベントを実装します。例として、イベントshowを発生させるメソッドの一部を次に示しfotorama:showます。 that.show = function (options) { …

24 readability  maintainability  event-programming  plugins  hooks 

わかりました、この質問のタイトルは、イベントベースのプログラミングをいつ使用する必要があるかとほぼ同じです。しかし、上記の質問の答えは、私が直面している特定のケースでイベントを使用すべきかどうかを決定するのに役立ちませんでした。 私は小さなアプリケーションを開発しています。それはシンプルなアプリであり、その機能の大部分は基本的なCRUDです。 特定のイベント（特定のデータを変更する場合）で、アプリケーションはそのデータのローカルコピーをファイルに書き込む必要があります。これを実装する最善の方法についてはわかりません。できます： データが変更されたときにイベントを起動し、そのようなイベントに応答をバインド（ファイルを生成）します。または、オブザーバーパターンを実装します。それは不必要な複雑さのようです。 データを変更するコードからファイル生成コードを直接呼び出します。はるかに単純ですが、依存関係をこのように設定するのは間違っているようです。つまり、アプリのコア機能（データを変更するコード）をその追加の特典（バックアップファイルを生成するコード）に結合するのは間違っているようです。ただし、このアプリは、そのカップリングが問題を引き起こすポイントまで進化しないことを知っています。 この場合の最善のアプローチは何ですか？

19 event-programming  coupling 

イベントベースのコンポーネントを使用するとき、メンテナンス段階で苦痛を感じることがよくあります。 実行されたコードはすべて分割されているため、実行時に関与するすべてのコード部分を把握するのは非常に困難です。 これにより、誰かがいくつかの新しいイベントハンドラを追加したときに、微妙で困難なデバッグの問題が発生する可能性があります。 コメントから編集する：アプリケーション全体のイベントバスやハンドラーがアプリの他の部分にビジネスを委任するなど、オンボードのいくつかの優れたプラクティスを使用しても、多くのコードがあるためにコードが読みにくくなり始める瞬間があります多くの異なる場所から登録されたハンドラー（特にバスがある場合に当てはまります）。 その後、シーケンス図が複雑になり始め、何が起こっているのかを把握するのに時間がかかり、デバッグセッションが煩雑になります（ハンドラーの反復中のハンドラーマネージャーのブレークポイント、特に非同期ハンドラーとその上でのいくつかのフィルター処理で楽しい）。 /////////////// 例 サーバー上のデータを取得するサービスがあります。クライアントには、コールバックを使用してこのサービスを呼び出す基本コンポーネントがあります。コンポーネントのユーザーに拡張ポイントを提供し、異なるコンポーネント間のカップリングを回避するために、いくつかのイベントを発生させています。1つはクエリが送信される前、1つは回答が返されるとき、もう1つは失敗の場合です。コンポーネントのデフォルトの動作を提供する事前登録された基本的なハンドラーセットがあります。 コンポーネントのユーザー（および私たちもコンポーネントのユーザー）は、いくつかのハンドラーを追加して、動作に何らかの変更を加えることができます（クエリ、ログ、データ分析、データフィルタリング、データマッサージ、UIファンシーアニメーション、チェーン複数の順次クエリの変更） 、 なんでも）。そのため、一部のハンドラーは他のハンドラーの前後に実行する必要があり、それらはアプリケーションのさまざまなエントリポイントから登録されます。 しばらくすると、十数人以上のハンドラーが登録されることがあり、それを操作するのは退屈で危険です。 この設計は、継承の使用が完全に混乱し始めたために生まれました。イベントシステムは、コンポジットの種類がまだわからないような構成で使用されます。 例の終わり /////////////// だから私は他の人々がこの種のコードにどのように取り組んでいるのだろうと思っています。書き込み時と読み取り時の両方。 そのようなコードを苦労せずに記述および保守できる方法やツールはありますか？

16 maintenance  event-programming 

protobufの構文3は、すべてのフィールドをオプションにし、キーワードrequiredを削除し、optional以前のproto2構文から削除しました。開発者からのコメントを読むと、前方/後方バイナリ互換性を強化するために行われたようです。 しかし、私にとっては、パッケージ名をバージョン管理するだけで強制できます。たとえばcom.example.messages.v1、クライアントが理解できるデシリアライザーを実装できるようにします。同時に、ソフトウェアエンジニアリングの観点から有用なタイプとして指定されている一部の契約を削除します。たとえば、私が持っている場合 message Location { double latitude = 1; double longitude = 2; } proto3ではLocation、必須フィールドの1つを提供しないことにより、完全に有効な半バックアップを作成できます。 クライアント間でデータを交換するためのスキーマベースのシリアル化形式を作成する場合、これは大きな欠点ではありませんか？すべての必須フィールドに有効な値があることを確認するために、各クライアントに追加の検証コードを移動するのは悪くありませんか？

15 event-programming  event-sourcing  protobuf 

ときどき、イベントをトリガーする前にいくつかの複雑な条件を満たしている必要があるシナリオに遭遇しました。さらに、ほとんどのリスナーは、追加のチェックを実行してアクションのコースを決定します。これにより、小さなイベントの観点から考えて、それらを相互にトリガーさせることがより良い解決策になるかどうかを考えさせられました。 イベントを連鎖させることで、後から追加のリスナーをかなり少ない労力で織り込むことができます（YAGNI違反の可能性があります）。私のコードは簡単に理解できる単純な要素で構成されますが、他の人が理解するのは難しくありません。 ただし、このソリューションの潜在的な欠点は、チェーン内で何か問題が発生した場合（たとえば、ヒューマンエラーによる誤ったイベントトリガー）、バグをキャッチすることが非常に困難になるという事実です。 イベントは、良いアイデアの連鎖をさTMを？そうでない場合、イベント関連のコードが乱雑になるのを防ぐための代替方法は何ですか？

15 event-programming 

これは一般的なトピックです。イベントハンドラはどのように機能しますか？ これは、舞台裏を意味します-作成されたときに何が起こるか。 大まかなアイデアはありますが、確認してもらいたいと思います。

14 event-programming  implementations 

奇妙なパターンが検出された場合に電子メールでユーザーに警告する金融アプリケーション用の小さなセキュリティサブシステムを実装すると仮定します。この例では、パターンは図のように3つのトランザクションで構成されます。セキュリティサブシステムは、メインシステムからキューからイベントを読み取ることができます。 私が取得したいのは、パターンの現在の状態をモデル化する中間表現なしで、システムで発生するイベントの直接的な結果であるアラートです。 監視が有効になりました 処理されたトランザクション 処理されたトランザクション 処理されたトランザクション アラートがトリガーされました（id：123） 送信されたアラートの電子メール（ID：123） 処理されたトランザクション これを念頭に置いて、明確な答えのない質問がありますが、イベントソーシングはここで非常にうまく適用できると思いました。この例でトリガーされたアラートには、明らかな副作用があり、電子メールを送信する必要があります。これは、一度しか発生しない状況です。したがって、集合体のすべてのイベントを再生するときに発生することはありません。 ある程度、CQRS /イベントソーシングの文献で何度も見たクエリ側で生成された実体化と同様に送信する必要がある電子メールが表示されますが、それほど微妙な違いはありません。 この文献では、クエリ側は、すべてのイベントを再度読み取る特定の時点で状態の具体化を生成できるイベントハンドラから構築されています。ただし、この場合、前に説明した理由により、そのように正確に実行することはできません。すべての状態が一時的であるという考えはここでそれほど適切ではありません。アラートがどこかに送信されたという事実を記録する必要があります。 私にとって簡単な解決策は、以前にトリガーされたアラートの記録を保持する別のテーブルまたは構造を持つことです。IDがあるため、同じIDのアラートが以前に発行されたかどうかを確認できます。この情報があると、SendAlertCommandはべき等になります。複数のコマンドを発行できますが、副作用は一度しか発生しません。 その解決策を念頭に置いても、これがこの問題のこのアーキテクチャに何か問題があるというヒントかどうかはわかりません。 私のアプローチは正しいですか？ これに関する詳細情報を見つけることができる場所はありますか？ これについての詳細情報を見つけることができなかったことは奇妙です。たぶん私は間違った表現を使っていたのかもしれません。 どうもありがとうございます！

14 event-programming  cqrs  event-sourcing 

バス通信におけるコマンドとイベントの違いは、私には少し曖昧に思えます。コマンドは1回だけ実行する必要があることを知っていますが、イベントは複数回処理できますが、コマンドまたはイベントをいつ使用するかはわかりません。 例を見てみましょう： 新しいユーザーがWebアプリケーションに登録するときに、彼にアカウントを作成し、確認メールを送信する必要があります。 アカウントを作成する -これはCreateUserCommand、バスにを送信して、専用のコンポーネントに処理させるための適切な場所のようです。 または、これは非同期バス通信で実装するべきではありませんか？ユーザーがすぐにアプリケーションにログインできるようにしたいと考えています。バスでは、コマンドがいつ実行されるかは保証されません。 メールの送信 -コンポーネントがアカウントを作成した後、2つの可能性を確認できます バスに別のコマンドを送信します SendConfirmationEmailCommand イベントを公開する UserAccountCreatedEvent そして、電子メール送信コンポーネントがそれを取得し、それを仕事にします。 一方では、確認メールを1回だけ送信したい（コマンドを使用する）一方で、新しく登録したユーザーに関係するコンポーネントが複数存在する可能性があると考えています。ロガーまたはSMS送信者。 どのように実装しますか？

14 event-programming  cqrs  service-bus