問題タブ [cross-cutting-concerns]

外部コンサルタントの助けを借りて、C# で .NET アプリケーションを開発しています。このプロジェクトをより良い開発プロセスのテスト ケースとして使用し、ベスト プラクティスに特に注意を払うことが私たちの目標です (単なるプログラムではなく、適切なソフトウェア製品を作成するため)。

現在、例外処理とロギングのインフラストラクチャの開発にもっと注意を払う (そしてより多くの時間を浪費する) か、アプリケーションの適切なアーキテクチャと機能 (既に分析およびモデル化されている) を開発するかについて、私たちは迷っています。

問題は、アプリケーション開発と並行して例外処理を構築する必要があるのか​​、それともプログラムを作成して、準備が整ったときにエラー処理と例外管理コードをプログラムに "適用" できるのかということです。

これは非常に小さく、十分に理解されたアーキテクチャを備えた、よく理解されたアプリケーションですが、インフラストラクチャと分野横断的な懸念事項に関して適切な選択を行わないと、あまりにも多くの作業がやり直されるのではないかと心配しています。始めます (つまり、ほとんどのコードがまだ書かれていません)。

もう 1 つのポイントは、そのために何らかのフレームワークを使用するかどうか、また使用する場合はどのフレームワークを使用するかはわかりません。したがって、これが基本的でない場合は、アプリケーションの残りの部分を開発して、後でそれを行うことができます。

ember で懸念事項をどのように実装しますか。たとえば、招待機能を送信します。

• ユーザーには 5 つの招待状があります (データの取得に関与するストア)
• どのアプリケーション状態からでも招待可能
• モーダルで表示されます
• それは複数になる可能性があります-したがって、 {{outlet modal}} も機能しません
• ユーザーは電子メールを入力して招待状を送信できます (利用可能な招待状の数が減少しました)

現在のモーダル実装 - したがって、コントローラーをビューに割り当てることはできません...

コンポーネントのアプローチは私にとってはうまくいきません: コンテンツ (モデル) はルーティングによってセットアップする必要があります。データのフェッチに役立つコンポーネントのイベントがわかりません。

ネストされたルートも同様に機能しません - 変更が多すぎます。

これに対する実用的なアプローチが見つかりません。助けてください。

前もって感謝します。

Unity (3.0) インターセプトを使用して、横断的な懸念をアプリケーションに追加しています。どういうわけか、構成で MethodSignatureMatchingRuleを使用できず、次のエラー メッセージが表示されます。

私の構成：

NamespaceMatchingRuleを使用した同じ構成は正常に機能します。

私のアセンブリにはへの参照が含まれています

• Microsoft.Practices.EnterpriseLibrary.Common
• Microsoft.Practices.Unity
• Microsoft.Practices.Unity.Configuration

助言がありますか？

ほとんどの開発者は、ロギング、監査、セキュリティ、トランザクション性などの分野横断的な問題を実装すると、ビジネス ロジックの実装に悪影響を与える可能性があることを認識しています。このような関心事は、既存のビジネス ロジックの複雑さを増すように「思われる」ため、ビジネス ロジックと分野横断的な関心事の実装を明確に区別することが不可能ではないにしても困難になる場合があります。

Dart はこれにどのように対処しますか? 現在、この問題に対処するメカニズムがない場合、分野横断的な懸念事項を実装する方法を導入する計画はありますか?

ありがとう。

PHP コードに例外処理を追加しています。例外処理を行う疎なブロックが大量に発生し、それらの膨大な量によって、実行されている実際の製品コードが隠されているようです。例えば：

上記の関数の実際のペイロードは、$data を返すことです。例外処理がなければ、2 行の関数になる可能性があります。

これを隠す 1 つの方法はFactory Method、次のように を使用することです。

ここでは、まったく新しい (ファクトリ) クラスと別のコード行を関数に追加して、例外処理を非表示にしています。適切な注意を払えば、これは機能し、見栄えも良いと思います (つまり、コンストラクター内でファクトリを初期化できるため、関数レベルのコードの外に移動できるため、良いオプションになる可能性があります)。しかし、それは最高ですか？

つまり、私の質問は、実際のペイロードをまばらな try/catch ブロックに埋めずに、コードで例外処理を使用するにはどうすればよいかということです。

Play/Scala/ReactiveMongo を使用して開発された Web アプリケーションで DB の変更をログに記録するための優れたソリューションを探しています。誰が何を変更したかを知る必要があります。

すべてのデータアクセスとビジネスロジックが発生するサービスという別のレイヤーがあります。すべての保存/更新/削除は特定の方法で行われるため、3 つまたは 4 つの方法で安全にログを記録できますが、ユーザー ID が必要です。

サービスの現在のユーザーにアクセスできません! ユーザーIDを取得できるグローバルなHttpContextやRequestなどはありません（もちろん、ユーザーIDを取得するこの方法は間違っていたと思います）。

私は解決策を持っています：

副作用 (DB の変更) を持つサービスのすべてのメソッドに暗黙的なパラメーターを追加し、それらにユーザー ID を渡します。

デフォルトのリクエストをラップしたので、暗黙のリクエストが暗黙のパラメーターと一致するように UserIdentity トレイトを拡張できます。

最後に、アクションは次のようなサービスを使用できます。

悪い点は、これらのサービス メソッドに暗黙的なパラメーターを追加する必要があることです。メソッドのシグネチャを汚染することなく現在のユーザーを取得する別の解決策はありませんか。

の良い例は何cross-cutting concernですか? ウィキペディアのページにある医療記録の例は、私には不完全に思えます。

具体的には、この例から、ロギングによってコードの重複 (散乱) が発生するのはなぜですか? log("....")（大したことではないように見えるどこでもなどの単純な呼び出しに加えて）。

core concernaと aはどう違いcross-cutting concernますか？

私の最終目標は、AOP をよりよく理解することです。

IOC コンテナに分野横断的な懸念事項を追加するように構成しましたが、これらの懸念事項が AbstractFactories によって構築されたクラスに追加されていません。

インターセプターは、構成ファイルで次のように定義されています。

LoggingInterceptor は、IApplication と IUserStore の両方に対して定義されています。しかし、コードを実行すると、IUserStore が傍受されていないことがわかります (Unity によって解決されていないため)。

上記のプログラムの出力は次のとおりです。

ファクトリによって構築されたオブジェクトにもインターセプターが適用されるように、このコードを変更するにはどうすればよいですか?

ユーザーが自分のプロファイルに関するさまざまな設定を保存できるようにする、私が取り組んでいる Swift アプリケーションがあります。私のコード全体を通して、アプリケーションのビジネス ロジックにとって、これらの設定/設定を知ることが重要な場合があります。それらの 1 つは、ユーザーが作業する場所です (ジョブ (主キーとして ID を持つ sqllite データベースの行))。ユーザーは、アプリ内でいつでも 1 つ (そして 1 つだけ) を選択できます。プロファイルのようなものだと考えてください - 彼らは多くの仕事をすることができますが、選択できるのは 1 つだけです。

以下は、workplaceid プロファイルを知ることが重要なシナリオです。

1. 私のsqlliteデータベースでは、現在選択されている作業IDに基づいて作業/シフト情報を取得しています(データベースからのIDではなく、現在選択されているID)。これをクエリに渡します。
2. NSDate 拡張関数では、開始日について何かを判断するときに、現在選択されているプロファイルを取得し、それを計算に使用する必要があります。
3. 特定のフィールドを表示/非表示にしたいときに、特定のビューモデル内で。
4. アラート ビューで、現在の職場に関連するものを表示します。

これを行う手っ取り早い方法は、ユーティリティ クラスで nsuserdefaults のラッパー クラスを作成することだと思います。確かに、すべての情報は sqllite に保存されていますが、現在選択されているアプリの設定は nsuserdefaults に保存されています。これは、ロギング/エラー処理などの他の分野横断的な懸念と並行しており、すべての作業に同様のユーティリティ クラスを使用できます。

アプリケーションのすべての単一レイヤーからこのヘルパー/ユーティリティ クラスを呼び出す可能性があるという事実は、実行しない典型的な危険信号のように思えます。ロギングであるか、情報を取得するためのユーザー サービスであるか。

このようなシナリオで他の人が何をしているのか知りたいです。アプリ全体から nsuserdefaults が必要な場合、「ユーティリティ クラスを作成して、必要な場所で呼び出すだけです」という答えはありますか? それとも、適切に設計された iOS アプリで他の人が従ったベスト プラクティスはありますか? AOP は人々が推奨する傾向があるものであることは知っています。それはiOSに場所がありますか？

どうもありがとうスタックオーバーフロー:)