問題タブ [specification-pattern]

私はフォーム管理システムを構築しています。つまり、システムには多くのフォームが含まれ、それらを保存し、それらに対してロジックを実行します。DDD アプローチを使用してそれを実行したいと考えています。

後で ASP.NET MVC を使用して簡単なフォーム レイアウトをサポートしたいのですが、これまでのところ、次のようなドメインが表示されます。

(今のところ) 名前、フィールド (およびそれらの値)、および検証ロジックを持つ必要があるベース フォーム エンティティがあります。

私の質問は次のとおりです。

1. ジェネリックを使用してフィールド値オブジェクトをどのように記述すればよいですか? 私はそれを理解できないようです..
2. 検証ロジックをフォーム内にカプセル化するか、仕様パターンを使用してカプセル化する必要がありますか?

他のデザイン パターンと同様に、仕様パターンは優れたコンセプトですが、熱心なアーキテクト/開発者が使いすぎてしまいがちです。

私は新しいアプリケーション (.NET & C#) の開発を開始しようとしていますが、仕様パターンの概念が非常に気に入っており、それを最大限に活用したいと思っています。しかし、全力を尽くす前に、アプリケーションの開発で仕様パターンを使用するときに経験した問題点を誰かが共有できるかどうかを知りたいと思います。

理想的には、他の人が問題を抱えているかどうかを確認しています

• 仕様パターンに対する単体テストの記述
• 仕様が存在するレイヤーの決定 (リポジトリ、サービス、ドメインなど)
• if単純なステートメントで仕事ができたときに、どこでもそれを使用する
• 等？

前もって感謝します

仕様パターンを実装しています。NotSpecification は、最初は単純に見えます。

ただし、すべての仕様で機能するわけではありません。

これは、true ではなく false を返す必要があります。これまでのところ、NotSpecification の isSpecialCaseOf を達成する唯一の方法は、remainingUnsatisfiedBy (仕様パターンに関する論文の部分的包含) を実装することだと思います。しかし、おそらく、これを不要にするもっと単純なものや論理的な洞察が欠けているのかもしれません。

質問：remainingUnsatisfiedBy を使用せずにこれを実装する別の方法はありますか?

私たちのプロジェクトでは、次のようにブール演算子を使用して仕様パターンを実装しました (DDD p 274 を参照)。

これにより、メソッドチェーンを使用してルールの優れた表現力が得られますが、微妙なエラーにつながる可能性のある標準の演算子の優先順位ルールはサポートされていません。

次の規則は同等ではありません。

車がコンバーチブルでない場合、規則isNiceCar2は満たされません。

isNiceCar2 を isFerrari.or(isRed.and(isConvertible)) に書き直せば同等になることはわかっていますが、どちらも構文的には正しいです。

私たちが思いつく最善の解決策は、メソッドチェーンを禁止し、代わりにコンストラクターを使用することです。

誰かがより良い提案をしていますか?

集約ルートを作成および検証するためのファクトリと一連の仕様を作成しました。現在、工場の製品の仕様と呼ばれる工場のテストがいくつかありますが、それで十分かどうか疑問に思います。設計の観点からは、工場は製品の仕様に密接に関連しているため、それらを結合する方がよい場合があります。

集約ルート製品の仕様が作成ではなく検証に使用されている場合、それを工場内から呼び出すことは理にかなっていますか？

それとも、単体テストで十分ですか？

Func を次のように定義しています。

次のように IEnumerables をクエリできます。

しかし、IQueryable の Where メソッドに同じ Func を指定しようとすると、次のようになります。

「ソース タイプ System.Collections.Generic.IEnumerable を System.Linq.IQueryable に変換できません。」

どうしたの？IEnumerable と IQueryable の両方の仕様として機能する Func を定義するにはどうすればよいですか?

以下のように式として定義された仕様がある場合：

そして、別の仕様「IsSuperheroine」を「超人的で女性」という論理で定義したいのですが、既存の仕様を新しい仕様内で再利用するにはどうすればよいですか？

私はいくつかの研究開発作業を行っているので、デザインパターンを模索しています。私は最近、仕様パターンを読んでいて、この素晴らしい記事を参照されました。

私はコードの単純さと清潔さに興味をそそられましたが、他の手法を使用して同じ清潔さを実装することといくつかの比較を描き始めました。

サービス層の次のインターフェイスコントラクトを検討してください。

だから、いくつかの最初のポイント：

• 3つすべてがFooオブジェクトのコレクションを返します
• 3つすべてが1つの引数を取る
• 仕様方法は、特定の要件へのアクセスを制限します
• 述語法には基本的に制限はありません
• Search argsメソッドは、特定の要件へのアクセスを制限します

さて、実装に移りましょう。

実装のポイント：

• 3つすべての実装は非常に簡単です（1行の連鎖コード）
• フィルタリングされた仕様と検索引数は外部に実装されています。
• Search argsメソッドは、単にIEnumerable拡張メソッドを使用してargsを検査します

そうは言っても、上記の3つのテクニックのいずれかをどのような条件下で使用しますか？

仕様パターンについての私の考え：

• ビジネス/ドメイン要件を再利用可能なコンポーネントに分離するという点で優れています
• 非常に読みやすく、コードが英語を話せるようにします
• かなりの量のコードが含まれています（インターフェース、抽象クラス）。これを使用する場合は、抽象化を共通のアセンブリに配置します（したがって、ソリューションに静的ファイルがたくさんありません）。
• サービス層ではなく、仕様を変更するだけで要件を簡単に変更できます。
• ドメインロジックの最高のテスト容易性（仕様）

拡張メソッド（パイプとフィルター）に関する私の考え：

• 論理的には「重量があります」が、それでも同じ単純さをもたらします。
• クエリロジックをサービスレイヤーから静的メソッドに分離する
• それでも、ある種の「反映」が必要です（提供された検索引数を検査し、クエリを構築します）
• 特定のビジネス要件（特定のシナリオで便利）を考慮せずに、最初にアーキテクチャ（リポジトリ、サービスレイヤー）をコーディングできます

述語メソッドに関する私の考え：

• クエリをきめ細かく制御する必要がある場合に使用できます。
• 仕様がそれをやり過ぎているかもしれない小さなプロジェクトに適しています

私の最後の考えの論理は、ビジネス要件が事前にわかっているが、時間の経過とともに変化する可能性がある複雑なビジネスアプリケーションで作業している場合は、仕様パターンを使用するというものです。

しかし、「スタートアップ」であるアプリケーションの場合、つまり要件は時間の経過とともに進化し、複雑な検証なしでデータを取得する方法が多数ある場合は、パイプとフィルターのメソッドを使用します。

あなたの考えは何ですか？上記の方法のいずれかで問題が発生したことがありますか？何かお勧めはありますか？

新しいプロジェクトを開始しようとしているので、これらのタイプの考慮事項は重要です。

助けてくれてありがとう。

仕様パターンを明確にするための編集

これが仕様パターンの同じ使用法です。

私は仕様パターンを使用しており、NLinq、汎用リポジトリ、およびそのすべての利点を介してデータを取得するための実用的な実装 (WhoCanHelpMe Codeplex プロジェクトから取得) を持っています。

ルート メソッドは次のとおりです。

FindAll() メソッドは次のことを行います。

そして、SatisfyingElementsFrom() はこれを行います:

したがって、Case の CaseNb プロパティによるケースのクエリは、非常に簡単です。以下のような仕様は私にとっては機能し、必要なケースを取得します。

ただし、複数のエンティティをまたぐときにこれを行う方法を理解するのに途方に暮れています。私が欲しいのは、UserName でケースを取得できる仕様です。基本的に、データベースには 3 つのテーブルがあり、これらはエンティティに持ち込まれています。エンティティは次のとおりです。

ケースクラスは次のとおりです。

CaseUser は次のとおりです。

そして、ユーザー：

関連テーブル全体でデータを取得する式をどのように記述しますか?

このコードは機能したので破棄しましたが、受け入れられるものにリファクタリングする必要があります。一連のクエリ オブジェクト (productid = 3 のような文字列) を受け取り、それらをクエリに追加します。これは論理 AND に対してのみ機能しますが、最終的にはいくつかの異なる論理演算子 (OR、NOT) が必要になります。

注文用にこれもあります：

では、どのようにして各繰り返しを仕様オブジェクトにカプセル化し、この仕様のコレクションを元のクエリ (注文式を含む) に添付できるのでしょうか? これは、Linq to Entities、Entity Framework 4、および C# の傘下にあります。

このようなことをするのは本当にいいことです。これは本質的に上記のことです。

ウェブサイトへのリンク、サンプルコードは、きっとありがたいです。