問題タブ [business-logic]

私が取り組んでいる Web アプリケーションがあり、これまでのところデータ アクセス レイヤーは完成しています。各テーブルには、そのテーブルの行のオブジェクトを作成する独自のクラスがあるため、各オブジェクトはテーブルの行を表します。各オブジェクトが持つ機能は、基本的に CRUD 操作です。

私が持っている質問は、アプリケーションのビジネス ロジックを実装する最良の方法は何ですか? 私はPHPでこれを行っているので、たくさんの関数を含むファイルを含めることができますが、これをよりよく整理したいと考えています。データアクセス層はすでにオブジェクト指向のアプローチをとっているので、これを続けていきたいと思います。

一見したところ、多数のネストされた if ステートメントを必要とする複雑なビジネス ロジックを処理するための適切な方法は何ですか?

例：

割引クーポン。になり得る：

1a) バリューディスカウント
1b) パーセンテージディスカウント

2a) 通常割引
2b) プログレッシブ割引

3a) アクセス クーポンが必要
3b) アクセス クーポンが不要

4a) 以前に購入した顧客のみに
適用 4b) すべての顧客に適用

5a) 国 (X、Y、…) のお客様のみに適用

これには、次のコードよりもさらに複雑なコードが必要です。

IF を switch/case に置き換えても、まだ複雑すぎます。読みやすく、保守しやすく、テストしやすく、理解しやすいものにする方法は何ですか?

わかった。これが私の単純化されたシナリオです。多数のお客様のご注文に対応できる体制を整えております。スタッフ ユーザーはすべての注文を表示できるようにし、クライアント ユーザーは関連する注文のみを表示できるようにします。

特定のレコードを表示しようとするとき、OrderSecurity クラスで次の関数を使用します。

注文のリストをユーザーに表示したい時点で、 OrderService クラスで定義された次の関数を使用できます

これは上記の場合は問題ありませんが、ルールが複雑になるにつれてうまく機能しません。たとえば、クライアントのサブセットからの注文のみを表示できる、信頼性の低いスタッフ メンバーを表す別のユーザー タイプを追加するとします。次に、CanViewOrder および GetOrders 関数 (および場合によってはデータ アクセス クラス) にロジックを追加する必要がありますが、これは私の考えでは DRY 原則に違反しています。

ですから、私の質問は次のとおりです。ここでトリックがありませんか?ビジネスロジックを組み合わせて、これらの機能の両方が使用できる 1 つの場所で注文を表示する許可を得る方法はありますか?

それとも、心配しすぎて、2 か所でロジックを実行する必要がありますか?

(この特定のアプリケーションでは、私は ASP Classic を使用しています - プレイヤーが嫌いではなく、ゲームが嫌いです - しかし、どの言語でもこの問題をどのように解決するかに興味があります)

例:

SQL Server を使用してレンタル サービスを構築しています。レンタルできるアイテムに関する情報は、テーブルに格納されます。各アイテムには、「利用可能」、「レンタル」、「壊れた」のいずれかの状態があります。さまざまな状態がルックアップ テーブルに存在します。

ItemState テーブル:

id name
1 「利用可能」
2 「レンタル」
3 「壊れた」

これに加えて、アイテムが返却されるたびに、その状態が「レンタル」から「利用可能」に変更されるというビジネス ルールがあります。
これは、「update Items set state=1 where id=@itemid」のような更新ステートメントで実行できます。アプリケーション コードでは、ItemState id:s にマップされる列挙型がある場合があります。ただし、これらにはハード コードされた値が含まれているため、後でメンテナンスの問題が発生する可能性があります。開発者が一連の状態を変更する必要があったが、関連するビジネス ロジック レイヤーを修正するのを忘れたとします...

この種の設計上の問題に対処するために、どのような良い方法または代替設計がありますか?
直接の回答に加えて、関連記事へのリンクも歓迎します。

現在、ビジネス ルールの実装にチェック制約を使用していますが、ビジネス ルールを SQL で実装するか、ビジネス ロジック層 (C#) で実装するかを知りたいです。ネットで検索したところ、チェック制約が使いやすいことがわかりました。

詳しい情報を知っている人がいたら教えてください。もう 1 つは、モバイル アプリケーションと Web アプリケーションを使用して、データをデータベースに送り込むことができることです。

さて、これが「一言で言えば」私が達成しようとしていることです...

私のアプリケーションのユーザーは、新しいグループを作成できます。グループへの参加を許可するユーザーを決定するために許可/拒否する他のユーザーに関する基準を指定できます。

例: 年齢: 12 - 16 歳 身長: 5 - 6 フィート

ルールを格納するデータ テーブルは次のようになります。許可または拒否フラグ (Y/N) AgeStart: 12 AgeEnd: 16 HeightStart: 5 HeightEnd: 6

次に、ユーザーがグループへの参加を許可されているかどうかを判断する基準を満たしているかどうかを確認する必要があります。

これは理にかなっていますか？それに反する EXCEPTION ルールも存在する可能性があります...たとえば、最初の「許可: Y」は 12 歳から 30 歳である可能性がありますが、2 番目のレコードは 25 歳から 28 歳の拒否に追加される可能性があるため、ユーザーは両方の基準を満たす必要があります。入力。

これに乗る人はいますか？

転送オブジェクトで DataAnnotations を使用したいと考えています。ただし、ビジネス層でそれらを呼び出して入力を検証するにはどうすればよいですか?

これは何らかのメソッド呼び出しまたはリフレクションによるものですか?

私は ASP.NET を使用していませんが、標準の ASP.NET を使用しており、ビジネス レイヤーでデータ アノテーションを呼び出したいと考えています。

この問題はテクノロジに依存しませんが、私は C# と ASP.NET を使用しており、これを疑似コードに使用します。どちらがより良いアプローチで、その理由は?

1. ロギング、トランザクション、および例外処理をカプセル化します。

   /li>

2. ロギング、トランザクション、および例外処理を呼び出し元に委譲します。

   /li>

ビジネス ロジック コードにロギングやトランザクションなどへの依存関係を導入することで、一般的でなくなるのではないかと懸念しています。一方、UI コードは非常にきれいに見えます。電話に出られません。他に考慮すべき要素を教えてください。

いくつかのビジネスオブジェクト/POCO/エンティティ/何でもあるビジネスレイヤーがあります。データアクセス用のリポジトリもいくつかあります。これまで、UIレイヤーから直接リポジトリにアクセスしてきました。ストレートCRUDではないクラスが実際に必要になる段階にあるので、ロジックとCRUDを実行するビジネスロジッククラスをいくつか作成します。リポジトリには、 UIはもう（おそらく最初から行われているはずです）。

これらのクラスを何と呼ぶべきですか？私が考えることができるのはサービスクラスだけですが、このアプリケーションには実際のWCFサービスがあるため、混乱を招きます。WCFサービスもこれらのクラスを使用するため、サービスにサービスクラスを使用させることは、奇妙で混乱を招くように思われます。