「ビジネスロジックを他のコードと混合してはならない」またはそのようなステートメントを何度も聞いたことがあります。私が書くすべてのコード（つまり、処理ステップ）は、ビジネス要件に関連するロジックで構成されていると思います。
誰かがビジネスロジックで正確に何で構成されているか教えてもらえますか？他のコードとどのように区別できますか？ビジネスロジックとは何か、そうでないものを判断するための簡単なテストはありますか？
5588 次
8 に答える
48
何をしているのかを平易な英語で定義するだけです。「それらを苦しめる」、「そのお金を盗む」、「地球のこの部分を破壊する」など、ビジネス的に物事を言うとき、あなたはビジネス層について話している。明確にするために、あなたを興奮させるものはここに行きます。
「これをここに表示する」、「表示しない」、「もっと美しくする」と言うときは、プレゼンテーション層について話します。これらはあなたのデザイナーを興奮させるものです。
「これを保存する」、「データベースからこれを取得する」、「更新する」、「削除する」などと言うときは、データレイヤーについて話します。これらは、どんな犠牲を払っても永遠に保つべきものを教えてくれるものです。
于 2008-09-02T11:43:39.403 に答える
11
ビジネス ロジックではないことから始める方がおそらく簡単です。データベースまたはディスクへのアクセスはビジネス ロジックではありません。UI はビジネス ロジックではありません。ネットワーク通信はビジネス ロジックではありません。
私にとって、ビジネス ロジックとは、ソフトウェア アーキテクチャがどのように動作するかではなく、ビジネスがどのように動作するかを記述するルールです。ビジネスロジックも変化する傾向があります。たとえば、すべての顧客が自分のアカウントに関連付けられた 1 つのクレジット カードを持っていることがビジネス要件である場合があります。この要件は、顧客が複数のクレジット カードを持つことができるように変更される可能性があります。理論的には、これはビジネス ロジックの変更に過ぎず、ソフトウェアの他の部分には影響しません。
それが理論です。現実の世界では (ご存じのとおり)、ビジネス ロジックはソフトウェア全体に広がる傾向があります。上記の例では、追加のクレジット カード データを保持するために、おそらく別のテーブルをデータベースに追加する必要があります。確かにUIを変更する必要があります。
純粋主義者は、ビジネス ロジックは常に完全に分離されるべきであり、データベースに "Customers" や "Accounts" という名前のテーブルを作成することに反対することさえあると言っています。極端にすると、信じられないほど一般的で保守が不可能なシステムになってしまいます。
システム全体にビジネス ロジックを塗り付けるよりも、ほとんどのビジネス ロジックをまとめておくことを支持する強力な議論があることは間違いありませんが、(ほとんどの理論と同様に) 現実の世界では実用的である必要があります。
于 2008-09-02T11:59:53.623 に答える
5
ビジネスロジックとアプリケーション要件を混同していると思います。それは同じことではありません。誰かが自分のビジネスのロジックを説明すると、次のようになります。
「ユーザーがアイテムを購入するとき、配達情報を提供する必要があります。情報は xyz ルールで検証されます。その後、彼は請求書を受け取り、ポイントを獲得します。これにより、y オファーに対して x% の割引が適用されます」(悪い例で申し訳ありません) )
このビジネス ルールを実装するときは、情報の提示方法、永続的な方法での保存方法、アプリケーション サーバーとの通信、ユーザーが請求書を受け取る方法など、二次的な要件を考慮する必要があります。このすべての要件はビジネス ロジックの一部ではなく、ビジネス ロジックから分離する必要があります。これにより、ビジネス ルールが変更されたときに、少ない労力でコードを適応させることができます。あれは事実です。
プレゼンテーションは、主にユーザー入力の検証において、ビジネス ロジックの一部を複製することがあります。ただし、ビジネス ロジック層にも存在する必要があります。その他の状況では、パフォーマンスの問題のために、一部のビジネス ロジックをデータベースに移動する必要があります。これについては、Martin Fowlerがここで議論しています。
于 2008-09-02T14:36:58.690 に答える
5
物事を1行に単純化するには...
ビジネスロジックは、特定のUI/実装の詳細に依存しない/変更されないコードになります..それは、ルール、プロセスなどのコード表現です.モデル化されているビジネスによって定義され、反映されます。
于 2008-09-02T12:01:53.760 に答える
2
レイヤーのBLL+DAL名は好きではありません。明確にするよりも、混乱を招きます。
それをDataServicesおよびDataPersistenceと呼びます。これにより、簡単になります。
サービス操作、永続化層CRUD（作成、読み取り、更新、削除）
于 2008-09-02T11:51:37.717 に答える
0
私にとって、「ビジネスロジック」は、問題のドメインに適用可能なデータを表すすべてのエンティティと、「データをどのように処理するか」を決定するロジックを構成します。
したがって、実際には「データ転送」（アクセスではない）と「データ操作」で構成されている必要があります。実際には、データアクセス（DBにアクセスするもの）は、プレゼンテーションコードと同様に、別のレイヤーにある必要があります。
于 2008-09-02T11:43:43.413 に答える
0
フォームやボタンなどに関するものが含まれている場合、それはビジネスロジックではなく、プレゼンテーション層です。ファイルまたはデータベースへの永続性が含まれている場合は、DALです。その間にあるものはすべてビジネスロジックです。実際には、UI以外のものはすべて「ビジネスロジック」と呼ばれることがありますが、ハウスキーピングではなく、問題のドメインに関係するものである必要があります。
于 2008-09-02T11:46:41.627 に答える
0
ビジネスロジックは純粋な抽象化であり、ユーザーの前にあるデータの具体化/視覚化から独立して存在し、基盤となるデータの永続性からも独立しています。
たとえば、Tax Preparationソフトウェアでは、ビジネスロジッククラスの1つの責任は、未払いの税金の計算です。レポートの表示や納税申告書の保存と取得については責任を負いません。
@Lars、「サービス」は特定のアーキテクチャを意味します。
于 2008-09-02T11:53:52.170 に答える