周りを見回すと、ルール、検証、ビジネス オブジェクト (エンティティ) などを定義するための優れたコード スニペットがいくつかありますが、優れた適切に作成されたビジネス レイヤー全体を見たことがなかったことを認めなければなりません。
嫌いなものはわかっていても、何が素晴らしいのかはわかりません。
優れた OO ビジネス レイヤー (または優れたビジネス オブジェクト) を指摘したり、ビジネス レイヤーをどのように判断したり、優れているかを教えてもらえますか?
ありがとう
1306 次
9 に答える
14
よく書かれたビジネス層に出会ったことはありません。
以下は、これに関する Alex Papadimoulis の見解です。
[...] 考えてみれば、ソフトウェア アプリケーションのほぼすべてのコード行がビジネス ロジックです。
- CustomerNumber (CHAR-13)、ApprovedDate (DATETIME)、および SalesRepName (VARCHAR-35) 列を含む Customers データベース テーブル: ビジネス ロジック。そうでない場合は、Column01、Column02、および Column03 を含む Table032 になります。
- 初めての顧客に 10% の割引を適用するサブルーチン: 間違いなくビジネス ロジックです。そしてうまくいけば、ソフトコード化されていません。
- 期限を過ぎた請求書を赤で強調表示するコードもビジネス ロジックです。Internet Explorer は確かに「unpaid」や「30+ days」という文字列を探しません。
では、このビジネス ロジックをすべて 1 つのコード レイヤーにカプセル化するにはどうすればよいのでしょうか。もちろん、ひどいアーキテクチャと悪いコードで！
[...] システムのアーキテクチャにビジネス ロジック専用のレイヤーを含める必要があることを示唆することで、多くの開発者は、その目標を達成するためにあらゆる種類の恐ろしく巧妙な手法を採用しています。そして、それは常に災害に終わります。
于 2008-10-14T03:19:11.403 に答える
6
これは、一般的に、ビジネス ロジックが恣意的で厄介だからだと思います。ガベージイン、ガベージアウト。
また、本当に優れたビジネス層のほとんどは、おそらく独自のものです。;-)
于 2008-10-14T03:13:43.007 に答える
5
優れたビジネス層は、徹底的なドメイン分析の後に設計されています。ビジネスのセマンティクスを把握し、それがデータ ストレージであろうと特定のアプリケーション (プレゼンテーションを含む) であろうと、あらゆる種類の実装から分離できれば、ロジックは適切に構成され、さまざまなコンテキストで再利用できるはずです。
優れたデータベース スキーマ設計がビジネス セマンティクスを捉え、それ自体をあらゆるアプリケーションから分離する必要があるのと同様に、ビジネス レイヤーも同じことを行う必要があり、データベース スキーマとビジネス レイヤーが同じエンティティと概念を記述している場合でも、2 つを別々のコンテキストで使用できる必要があります。 -- スキーマが現在のビジネスを反映していない限り、ビジネス ロジックが変更されても、データベース スキーマを変更する必要はありません。ビジネス層は、中間層を介して抽象化されている限り、任意のストレージ スキーマで動作する必要があります。たとえば、ADO.NET エンティティ フレームワークを使用すると、ビジネス レイヤーにマップされ、ビジネス オブジェクト レイヤーまたは概念レイヤーを再コンパイルせずに変更できるストレージ スキーマへの個別のマッピングを持つ概念スキーマを設計できます。
ビジネス側の人がビジネス層で書かれたコードを見て、何が起こっているのかを大まかに把握できれば、オブジェクトが正しく設計されていることを示す良い兆候かもしれません。ソリューション ドメインからのアーティファクトで問題ドメインを難読化することなく。
于 2008-10-14T06:51:59.647 に答える
4
私はいつも岩と固い場所の間で立ち往生してきました。理想的には、ビジネス ロジックがデータベースや UI 関連の問題にまったく関与しないことです。
キー が問題を引き起こす それでも、主キーや外部キーのようなものが問題を引き起こしていることがわかります。Entity Framework のようなツールでさえ、このクリープを完全に排除することはできません。POST データとして渡された ID をそれぞれのオブジェクトに変換するのは非常に非効率的です。これをビジネス層に渡すだけで、データ層に渡されて再び取り除かれます。
NoSQL データベースにも問題があります。それらは完全なオブジェクト モデルを返す傾向がありますが、オブジェクト モデルは変更されないと想定しているため、通常は必要以上のものが返され、問題が発生する可能性があります。また、キーはまだ NoSQL データベースにあります。
再利用とオーバーヘッド コードの再利用の問題もあります。特定のテーブルまたはテーブルのすべての列を含む、データ レイヤーが完全に入力されたオブジェクトを返すことはかなり一般的です。ただし、多くの場合、ビジネス ロジックはこの情報の限られたサブセットのみを考慮します。関連データのみを運ぶ特殊なデータ転送オブジェクトに適しています。もちろん、表現間の変換が必要なので、マッパー クラスを作成します。次に、保存するときに、何らかの形でこれらの下位オブジェクトを完全なデータベース表現に変換するか、部分的な UPDATE (別の SQL コマンドを意味する) を実行する必要があります。
そのため、データベース テーブル (データ転送オブジェクト) に直接マッピングされるオブジェクトを受け入れる多くのビジネス レイヤー クラスを目にします。また、未加工の UI 値 (プレゼンテーション オブジェクト) を受け入れるビジネス レイヤーも多数見られます。必要なデータを取得するために、ビジネス レイヤーが計算中にデータベースを呼び出すことも珍しくありません。事前に取得しようとするのはおそらく非効率的であり (if ステートメントが取得されるデータにどのように影響するかを考えてください)、遅延ロードされた値は多くのマジックまたは意図しないデータベースへの呼び出しをもたらします。
最初にロジックを書く 最近、私は「コア」コードを最初に書くようにしています。これは、実際のビジネス ロジックを実行するコードです。あなたのことはわかりませんが、他の人のコードを調べているときに、「でも、[ビジネス ルール] はどこで行われているのですか?」という質問をよくします。多くの場合、ビジネス ロジックは、データの取得、変換などに関する懸念で混雑しているため、データを確認することさえできません (干し草の山の中の針)。そのため、最初にロジックを実装し、必要なデータを把握したら、それをパラメーターとして追加するか、パラメーター オブジェクトに追加します。この新しいインターフェイスに合わせて残りのコードを取得することは、通常、何らかのメディエーター クラスに当てはまります。
ただし、前述したように、パフォーマンスを含むビジネス レイヤーを作成するときは、多くのことを念頭に置く必要があります。私はまだバージョン管理やデータベース スキーマに対する権利を持っていないので、上記のアプローチは最近役に立ちました。ここまでの要件を理解しただけで、暗い部屋で作業しています。
テストを念頭に置いて書く 依存性注入を利用することは、優れたアーキテクチャを事前に設計するのに役立ちます。データベースや他のサービスにアクセスせずにコードをテストする方法を考えてみてください。これは、複数のコンテキストで実行できる、小さくて再利用可能なクラスにも役立ちます。
結論 私の結論は、完璧なビジネス層などというものは実際には存在しないということです。同じアプリケーションでも、1 つのアプローチが 90% の確率でしか機能しない場合があります。私たちにできる最善のことは、機能する最も単純なものを書くことです。長い間、私は DTO を避け、ADO.NET DataRows をオブジェクトでラップして、基になる DataTable に更新がすぐに記録されるようにしました。オブジェクトをコピーできず、制約によって異常なタイミングで例外がスローされたため、これは大きな間違いでした。パラメータ値を明示的に設定しないようにするためだけに行いました。
于 2013-01-04T17:31:52.290 に答える
2
Martin Fowler は、DSL について広範なブログを書いています。そこから始めることをお勧めします。
于 2008-10-14T03:11:09.593 に答える
2
私が見つけた 1 つの問題は、適切に設計されたビジネス レイヤーがあっても、ビジネス ロジックの漏洩を止めるのは難しく、開発ツールはこれを助長する傾向があるということです。たとえば、バリデータ コントロールを ASP.NET WebForm に追加するとすぐに、ビジネス ロジックがビューに漏れ出します。検証はビジネス レイヤーで実行され、その結果のみがビューに表示されます。データベースに制約を追加するとすぐに、データベースにもビジネス ロジックが作成されます。ただし、DBA タイプは、この最後の点に強く反対する傾向があります。
于 2008-10-15T03:25:47.113 に答える
2
CSLA.Netを学んで遊んでみることは、私にとって役に立ちました(あなたが MS の人なら)。「純粋な」CSLA アプリケーションを実装したことはありませんが、アーキテクチャで提示された多くのアイデアを使用しました。
あなたの最善の策は、とらえどころのない魔法の弾丸を探し続け、解決しようとしている問題に最も適したアイデアを使用することです。複雑にしないでおく。
于 2008-10-14T06:29:11.503 に答える
0
私もそうではありません。私たちはアプリケーションにビジネス層を作成しません。代わりにMVC-ARSを使用します。ビジネス ロジックは、(S) ステート マシンと (A) アクションに組み込まれています。
于 2008-10-14T03:15:21.863 に答える
-1
おそらく、実際には、ビジネス ロジックを「プロセス」、入力、出力、インターフェイスから完全に分離することはできず、最終的に人々は抽象的なものを処理することはもちろん、それを現実に関連付けることさえ難しいと感じるからです。
于 2008-10-14T03:39:33.513 に答える