問題タブ [cross-cutting-concerns]

私たちの開発フレームワークでは、パラメーターの検証にアスペクトを使い始めました。それはうまく機能し、パブリック メソッドの前半に検証コードを散らかさないことを楽しんでいます。

私が疑問に思っているのは、名前空間構造のどこにパラメーターの検証を配置するかについて、誰かが推奨事項を持っているかどうかです。これはトップ レベルの機能であるため、.NET Framework で System が使用される方法と同じように、トップ レベルの製品名前空間に配置する必要があると考えています。このような機能が追加されるとコア アセンブリが肥大化するのではないかと心配しています。

現状では、次のようなものがあります。

[会社].[製品].ParameterValidators

この例では、ParameterValidators は機能を含むクラス (アスペクト) の名前です。

これとは別に、構造的な配置に関連して既存のコードベースに側面を組み込むためのさらなる推奨事項があれば、私は感謝します.

ベースアプリケーションフレームワークに関して、他のショップが何をしているのか気になりましたか? 私は、アプリケーション フレームワークを、そこから構築されたアプリケーションの品質を向上させる追加機能または拡張機能を提供できるものと考えています。

Spring (または Spring.NET) など、すぐに使用できるさまざまなフレームワークがあります。これらの最大の問題は、それらがアラカルトではないことです。基本的に、それらには多すぎる機能があり、その機能のすべての部分が利用可能な最良の実装でない限り、これらのタスクを達成するために複数のフレームワークのパッチワークを使用することになり、肥大化と混乱を引き起こす可能性があります. 私の意見では、これは無料の商用システムにも当てはまります。

もちろん、書くことは大部分が車輪の再発明です。ただし、最もカスタマイズ可能なオプションを提供するため、メリットがないわけではないと思います。ただし、いくつかのものは開発するには大きすぎます。この場合、開発の初期費用を負担することを躊躇しているため、実装が不十分であるか、まったく実装されていないように見えます。

アプリケーション フレームワークの個々の部分に対処するさまざまなオープン ソース プロジェクトも存在します。これらは、さまざまなソースからの包括的なフレームワークを構成するのに役立つように、採用または同化することができます (明らかにライセンス契約に依存します)。

私たちは、企業全体のアプリケーションにおけるより大きな懸念事項のいくつかを調べることで状況に取り組み、有効な分野横断的な懸念事項と繰り返し発生する実装の問題のリストを作成しました。最終的に、部分的にオープン ソースであり、部分的に既存のオープン ソース オプションに基づいており、部分的にカスタム開発されたハイブリッド ソリューションを思いつきました。

私たちのフレームワークにあるもののいくつかの例:

• 例外およびイベント ログ プロバイダー。すべてのアプリケーションが最小限のコーディング作業で同じ方法で例外とイベントをログに記録できる、シンプルで統一された手段。そのまま使用して、SQL Server、テキスト ファイル、イベント ビューアーなどにログを記録できます。他のソースにログを記録するための拡張ポイントも含まれています。
• 変数割り当ての強制。JUnit に着想を得た構文を使用して、オブジェクト タイプに基づいて拡張メソッドを公開するジェネリック クラス。たとえば、myObject が null でないかどうかを判断するには、単純な Enforce.That(myObject).IsNotNull(); を実行できます。または、単純な Enforce.That(myObject).IsOfType(typeof(Hashtable)); を実行して、特定のタイプであるかどうかを判断します。適用が失敗すると、適切な例外が発生し、コードの量が削減され、実装の一貫性が確保されます。
• 単体テスト ヘルパー。クラスとそのプロパティを自動的にテストできるリフレクションに基づく一連のクラス。(CodePlex のAutomatic Class Testerに触発された) しかし、ゼロから書かれています。従来はテストが困難または時間がかかっていたものの単体テストの作成を簡素化するのに役立ちます。

他の機能もそのまま採用しています。たとえば、AOP にはPostSharp、モッキングにはmoq 、DI にはautofaqを使用しています。

他の人が何をしたのか、満足のいくツールが見つからなかったフレームワークがどのような問題に対処しているのか、疑問に思っていますか? 私たちの経験としては、新しいフレームワークのメリットを確実に享受しており、採用したアプローチに満足しています。

私たちは、groovy スクリプトが分野横断的な懸念のためのスペースを確保するためのインクルード メカニズムを探しています。

私の例では、Groovy スクリプトとしての Web サービス エンドポイントがあり、Web サービス プロトコルにログを記録したいと考えています。そのために、暗黙的なオブジェクト (フレームワークから取得) を使用してログ ステートメントを作成します。

しかし、これをすべての Web サービス エンドポイントでコーディングする場合、これはボイラープレート コードです。

他の Groovy スクリプトを含む php の include() のようなものを探していますが、これを行う方法はありますか?

すべて。たぶん私は十分にグーグルしていませんが、私はこの質問の例を見つけることができません。

C＃では、クラスに適用され、そのすべてのメソッドを変更するカスタム属性を作成することができますか？たとえばConsole.WriteLine("Hello, i'm modified method");、最初の行として追加します（または、実行時に実行する場合はILと同等です）。

側面やポイントカットなどに入らずに横断的な懸念を実装するための回避策はありますか?

私たちはSpring MVCを使用しており、さまざまな理由によりAspectJまたはSpringのアスペクト処理に入ることが現実的ではないビジネスアプリに取り組んでいます。

また、一部のコントローラーは非常に肥大化しており (重すぎて)、焦点の合っていない大量のコードがいたるところに忍び寄っています。

リファクタリングに腰を下ろすたびに、同じことが何度も繰り返されているのを目にします。説明させてください：

ビューを準備する必要があるたびに、UI 用に国のリストをビューに追加します。(ModelAndView に追加されたオブジェクト)。そのリストは DB から ehCache に引き出されます。

さて、最初はリスト INLINE を mav のどこにでも追加しようとしたときはひどいものでした。代わりに、すべての ModelAndView を処理する関数を用意しました。どのように？まあ、関数へのより多くのガベージ呼び出しがあります!

そして、私は別の問題のために1つの問題を買いました。

私を少し助けることができるデザインパターン/トリックは何ですか? 関数を呼び出して ModelAndView に何かを追加するのにうんざりしていて、コントローラー コードだけで 3500 行以上あるので、不足しているすべての接着点を見つけるのに夢中です!

提案は大歓迎です。横断は、AspectJ または Spring ネイティブのないフレーバーに関するものです。

私は非常に単純な問題を抱えていますが、次の「最良の」解決策を探しています。

私は次のような複数のコントローラーアクションを持っています：

この横断的関心事を分離するための最良の方法は何ですか？

• 機能が作れる
• PostSharpのようなAOPツールを使用できます
• ActionFilter
• 他の？

プログラミングでは、分野横断的な懸念は一般的な懸念です (より適切な用語がないため)。

たとえば、航空機とそのすべての複合部品をクラスでモデリングしている場合、さまざまなデバイスが同じタイプの部品に依存します。例：燃料タンク、水タンクなど

私は自分のデザインで対処すべき同じ問題を抱えています。AOP 以外に、これに対処するための戦略はありますか?

ありがとう

nservicebus でイベントを記述したい場合は、サービスから発行され、1 つ以上のサブスクライバーによって消費されるインターフェイスを作成します。

イベントを「systemerror」と呼びましょう。このイベントは、コード内でそれ以上何かを実行できないポイントに到達するたびに発行されます。

そのため、このイベントは最終的に複数の異なる論理サービスによって発行される可能性があります。この「systemerror」を発行するサービスが 1 つしかない場合に、サブスクライバーからの構成ファイルを見てみましょう。

今のところ問題ありません。しかし、このイベントを発行するサービスが 2 つある場合はどうなるでしょうか。

「SystemErrorMessages」という名前のメッセージ エントリが 2 つあるため、これは有効な構成ではありません。

「systemerror」イベントから継承して、各論理サービスが独自の「systemerror」（たとえば「appservice_systemerror」や「transportservice_systemerror」）を発行できるようにすることができます。

サブスクライバーの構成は次のようになります。

しかし、論理サービス「transportservice」を 2 つ以上の異なるマシンにインストールする場合、どのようなアプローチになるのでしょうか? そのため、2 つの論理サービスがあり、これらのサービスの 1 つが 2 つの物理的な場所にインストールされています。

そのような問題の可能な解決策は何でしょうか? そのような場合を処理する nservicebus コンポーネントはありますか? これらのメッセージがコマンドではなくイベントを示しているという事実に関係なく、メッセージを発行する代わりにメッセージを送信する必要がありますか?

JAX-RS（JSR-311）内で、アプリに固有の横断的関心事のいくつかを抽出できるメカニズムを探しています。たとえば、私のアプリには、リクエストごとに検索または構築される特定のコンテキストがあります。このタイプのロジックを一元化された場所で実行し、その後、リクエストの残りの部分でさまざまなリソースによって利用されるコンテキストに何らかの形でアタッチできるようにしたいと思います。URLの一部のサブセットに対してのみ、これらのタイプのアクションを実行できればさらに良いでしょう。

JAX-RSがパスセグメント、Cookie、ヘッダーなどに提供するデフォルトのインジェクションは素晴らしいですが、これらの部分のカスタム解釈はどうですか？必要になるたびにそれを構築する必要は本当にありません。むしろ、ビルド方法を指定して、リソースメソッドの一部としてコンテキストコンポーネントを挿入する方法が必要です。

そのようなフックはありますか？これを行うためにプロバイダーモデルを操作できますか？ところで、私は可能な限り実装に依存しないようにしたい（Jersey、RESTEasyなど）。

洞察を事前に感謝します。

反復的なタスクにアスペクト指向プログラミングを利用しようとしています。懸念事項を分離する方法がわかりません。私は C# を使用しており、AOP には Castle.DynamicProxy (Autofac の InterceptedBy 機能を使用) を使用していますが、この質問への回答が、他の AOP ソリューションにも適用するのに十分な一般的なアドバイスになることを願っています (おそらくあなたは納得できるでしょう)。別の AOP ソリューションに切り替える必要があります)。

たとえば、クラスへのすべてのメソッド呼び出しをインターセプトする次のインターセプターのようなものがあります。メソッドが呼び出されたとき、(1) 呼び出しにかかった時間を測定し、(2) 呼び出される前後のメソッドの名前をログに記録します。

ここでのタイミングの問題 (メソッド呼び出しにかかった時間の測定) は、ロギングの問題 (ログ ファイルへの書き込み) とは別のものにすべきだと思います。私はこのようなことを考えていますが、順序付けにどのようにアプローチするか、またはcallTime変数をどこに置くべきかわかりません:

ここで基本的に私が考えているのは、何らかの方法でTimingInterceptorがメソッドを直接インターセプトする必要があり、次にLoggingInterceptorがそれをラップする必要があるということです。

これらの懸念が正しい順序で発生することを確認するために、人々はどのようなアプローチを使用しますか? LoggingInterceptor が TimingInterceptor の Intercept メソッドをインターセプトするようにして、インターセプターをチェーンしますか? [InterceptOrder(1|2|3|...)]それとも、インターセプター クラスに何らかの属性を設定する必要がありますか? または[InterceptAfter(typeof(TimingInterceptor))]、LoggingInterceptor のようなものを配置できますか?

また、スレッドローカル変数を使用して呼び出し時間を追跡するより良い方法はありますか? はい、これをスレッドセーフにしたいと思います。この変数をスタックに保持することが望ましいと考えていますが、LoggingInterceptor がカップリングをあまり導入せずに TimingInterceptor へのハンドルを取得する方法がわかりません (LoggingInterceptor を再コンパイルせずに TimingInterceptor の実装を切り替えられるとよいでしょう)。 .