問題タブ [enforcement]

1 時間に X 回しか実行できない WCF サービスを作成したいと考えています。過去 60 分間にサービスが x 回以上呼び出された場合に、キューへのメッセージを一時停止するようにサービスを設定します。

サービスを制限するにはどうすればよいですか？カスタム コンポーネントを WCF スタックに作成したいと考えています。

私が持っているとしましょう

そのメソッド署名を強制するために次のクラスを作成できますか? （ただ思いついたアイデア）：

[編集]

目的: 私はすでに中間層のメソッドに属性を入れています。私はこのような方法を持っています:

次に、実行時に、すべての中間層のメソッドを反復してコレクションに配置し (ここでは属性が非常に役立ちます)、それらを winform のデリゲート関数 (インターフェイス、プラグインベースのシステムによって促進されます) にマップします。

コンパイラが矛盾をキャッチできるように、属性をより自己記述的にできるかどうかを考えています。

各クラスにメソッドを配置すると、常に Remoting オブジェクトをインスタンス化するのはやり過ぎになると思います。それらを別のクラスに置くと、コードの再利用を促進するのが難しくなる可能性があります。たとえば、Invoice_Save が Receipt_Open に関する情報を必要としているとします。実際、呼び出されたメソッド内でリモーティング中間層 DataSet からデータを取得したレポート (crystal) さえあります。他のメソッドに関する情報を取得し、独自の DataSet にマージします。それらはすべて中間層で発生しており、いくつかのラウンドトリップはありません。すべてがサーバー側（中間層）で行われます

JavaScript ステートメントの最後にセミコロンを付けるのが好きだと判断した開発者は、その期待を自分自身に技術的に強制するにはどうすればよいでしょうか?

私は Visual Studio (ASP.NET webapps) を使用していますが、あらゆる環境でのソリューションについて知りたいです。

こんにちは、Cocoa の Objective-C で実行時の型チェックなどを実施する方法を探しています。

これは私のコードサンプルです。変数 'b' への間違った割り当てに関する実行時エラーが発生することが予想されました。しかし、そうではありませんでした。エラーなしでコンパイルおよび実行されました。

ランタイム型チェックがないことに驚きました。VB、C#、Java、ActionScript などのすべての高水準言語を使用したため... C などの低水準言語を知らないので、これが正しい方法かどうかわかりません... 理解するのは本当に難しかったです。コンパイル エラーや実行時エラーが発生しない理由。しかし、これは実際の C の世界では当然のルールとして理解できるようになりました。しかし、より強力な型チェックは私を大いに助けてくれます。デバッグセッションだけでも。これを行う方法はありますか？

また、実行時の型チェックがない場合、間違った型の値についてどのようなコーディングおよびデバッグ戦略を使用する必要がありますか? また、実行時の型チェックを行うか行わないかのトレードオフは何ですか?

もう一度: -1 に投票する場合は、理由を説明するコメントを残してください。この投稿は、このアプローチを承認するかどうかではなく、どのように実行するかについてです。

多くのアーキテクトと同様に、私は長年の経験を通じて開発者が遵守することを期待するコーディング標準を開発してきました。

これは特に、3 ～ 4 年の経験があればシニア レベルの開発者になると信じている人々にとっては大きな問題です。これをトレーニングとコード レビューの問題としてアプローチしても、成果は限定的です。

そのため、ビルド プロセスにカスタムのコンパイル時エラーを追加して、社内のベスト プラクティスとコーディング標準をより厳密に適用できるようになれば素晴らしいと考えていました。

たとえば、すべてのデータベース アクセスにストアド プロシージャを使用します。これにより、プロシージャ レベルのセキュリティ、データベースのカプセル化 (テーブル構造はアプリから隠されます)、およびその他の利点が提供されます。(注:これについて議論を始めるつもりはありません。) 一部の開発者は、インライン SQL またはパラメーター化されたクエリを好みますが、それは問題ありません - 自分の時間と自分のプロジェクトで。

たとえば、次のように見えるものをすべて見つけるコンパイルチェックを追加する方法が欲しい

エラーを生成するか、特定の状況では警告を生成し、次のようなメッセージを表示します。

Inline SQL and parametrized queries are not permitted.

または、var キーワードを使用する場合

Variable definitions must be explicitly typed.

Visual Studio と MSBuild は、この機能を追加する方法を提供していますか? 正規表現を使用して受け入れられないコードを見つけて正しいエラーを生成できると考えていますが、パフォーマンスの観点から、これをビルド プロセスに統合する最善の方法が何であるかはわかりません。

ビルド前またはビルド後のステップを追加してカスタム EXE を実行することはできますが、行固有およびファイル固有のエラーを返すにはどうすればよいでしょうか? また、リンク後ではなく、各ファイルのコンパイル後にこれを実行したいと思います。

このタイプのパターン マッチングを実行するには、正規表現が最適な方法ですか?それとも、解析ツリーを介してノードレベルの検証を可能にする C# パーサーを介してコードを実行する必要がありますか?

提案や以前の経験談をいただければ幸いです。

コメント 何人かの回答者は、ユーザーがストアド プロシージャ以外を実行する能力を db パーミッションによって制限できることを指摘しています。ただし、35 万行以上のアプリケーションを ASP 3.0 から ASP.NET MVC に移植する過程にあり、既存のコード ベースは連結 SQL に大きく依存していますが、新しいものはすべて Enterprise Library を使用しています。.NET コード用に別の Web ユーザー アカウントを追加して、アクセス許可をより制限することもできると思います。

重複の可能性:
.NET で例外がチェックされないのはなぜですか?

私の記憶が正しければ、Java は、呼び出されたメソッドがスローする例外をキャッチして処理することを強制します。.NET が同じことをしないのはなぜですか?

テストを自動化して、Python 2.xコードの本体に文字列インスタンスが含まれていない（Unicodeインスタンスのみ）ことを強制するにはどうすればよいですか？

例えば。

コード内からそれを行うことはできますか？

この機能を備えた静的分析ツールはありますか？

編集：

Python 2.5のアプリケーションでこれが欲しかったのですが、次の理由でこれは実際には不可能であることがわかりました。

1. 2.5はサポートしていませんunicode_literals
2. kwargsディクショナリキーをUnicodeオブジェクトにすることはできず、文字列のみにすることができます

だから私はそれがさまざまな理由であるとしても、それは不可能であるという答えを受け入れています:)

アプリケーションでエンティティ間に 1:1 の多重度を持たせたいシナリオに遭遇しましたが、これを確実にするためにデータベースを変更する方法がわかりません。

Document テーブルと Index テーブルがあり、Document には常に 1 つの Index があり、Index は 1 つの Document にのみ含まれるとします。Document テーブルには IndexID フィールドがあったため、Document エンティティにはそのインデックスへのナビゲーション プロパティがありますが、Index エンティティには Documents というコレクション ナビゲーション プロパティがあります。

DB スキーマを何らかの方法で編集して、DB からモデルを生成するときに、Document エンティティに Index への単一のナビゲーションがあり、Index に Document に戻る単一のナビゲーション プロパティがあるようにするとよいでしょう。そのようなことは可能ですか？

これを実現するには、モデル デザイン サーフェイスでエンティティ モデルまたはその関連付けを編集できるのではないかと考えました。しかし、ある段階でモデルをリロードすると、これと他のものがリセットされるのではないかと心配しています。

1:1 の多重度があることを EF に自動的に認識させるエレガントなソリューションはありますか?

アドバイスをありがとう！

Dで条件を「強制」するか、条件を「アサート」するかを選択するのに苦労しています（ただし、これは言語に依存しません）。

理論的には、アサーションを使用してバグを見つけ、他の条件を適用して非定型の条件をチェックすることを知っています。たとえば、メソッドの引数について言うかもしれませんassert(count >= 0)。これは、呼び出し元にバグがあることを示しているためです。これはenforce(isNetworkConnected)バグではないため、これは、あなたのコントロールを超えた正当な状況。

さらに、アサーションは、副作用なしに最適化としてコードから削除できますが、強制は常に条件コードを実行する必要があるため、削除することはできません。したがって、メソッドへの最初のアクセスで自分自身を埋める怠惰なコンテナを実装している場合は、enforce(!empty())代わりに言います。これは、内部のコードを怠惰に実行するため、常にassert(!empty())チェックが行われる必要があるためです。empty()

だから私は彼らが意味することになっていることを知っていると思います。しかし、理論は実践よりも簡単で、実際に概念を適用するのに苦労しています。

次のことを考慮してください。

他の2つの範囲を反復処理する範囲（イテレーターと同様）を作成し、結果を追加します。（機能プログラマーの場合：map!("a + b")代わりに使用できることは承知していますが、質問を説明していないため、今のところ無視しています。）したがって、擬似コードで次のようなコードがあります。

それは主張か強制か？（範囲が同時に空にならないのは呼び出し元のせいですか？範囲がどこから来たのかを制御できない可能性があります-ユーザーから来た可能性があります-しかし、それでも、バグですね）

または、別の擬似コードの例を次に示します。

これはアサーションまたは強制のどちらである必要がありますか？パスはユーザーからのものである可能性があります（したがって、バグではない可能性があります）が、パスが有効であることがこのメソッドの前提条件です。主張または強制しますか？

ありがとう！

私は複数のコンポーネントを持つ製品に取り組んでいます。それらのほとんどは C++ で記述されていますが、1 つが C で記述されています。情報が IPC を介して各コンポーネントを通過するシナリオがよくあります。

これらのメッセージを構造体を使用して定義し、それらをメッセージにパックしてメッセージ キュー経由で送信できるようにします。これらの構造体は、「転送」のみを目的として設計されており、その目的のみを果たすように記述されています。私が直面している問題は次のとおりです。プログラマーは構造体を保持し、それを情報の長期的なコンテナーとして使用しています。

私の目には、これは問題です。

1) トランスポート構造を変更すると、すべてのコードが壊れます。このシナリオに遭遇しないように、ここでカプセル化する必要があります。

2) メッセージ構造体は非常に厄介で、情報を転送するためだけに設計されています...この構造体が、これらの他のコンポーネントのこのデータに (長期的に) アクセスする最も便利な形式になる可能性は非常に低いようです。

私の質問は、この誤用をプログラムで防ぐにはどうすればよいですか? これらの構造物は輸送にのみ使用できるように強制したいと思います。

編集:ここでできる限りの例を提供しようとします:

その結果、ユーザーは必要なデータを largeElement から抽出してニーズを満たすクラスに入れるのではなく、単に「largeElement」に固執することになります。