複数の .NET スターター キットを見て気付いたのは、ビジネス オブジェクトの構築はクライアント レベルで処理されることが多いということです。次に、ビジネス オブジェクトは、操作やデータベースへのシリアル化などのためにビジネス レイヤーに渡されます。クライアントが必要なデータのみを渡す必要があるように、このコードをビジネス レイヤーに抽象化する必要はありませんか? オブジェクトを引数としてのみ受け入れる CRUD 抽象化を備えたビジネス層を持つことには利点がありますか?
2 に答える
3
私はあなたに同意します。ビジネスレイヤーとの相互作用は、複雑なタイプやその他の複雑さを隠して、可能な限り単純に保つ必要があります。UIオブジェクトとビジネスオブジェクトが接続された時点で、複雑さは可能な限り0に近いはずです。
その時点で比較的複雑なタイプの構築が合法であるシーンリオを想像することができます。サイトが小さいほど、厳密な3層よりも3層未満の方が実際に優れている可能性が高くなります。ですから、あなたが見ているスターターキットについて心を開いてください。おそらく、範囲が非常に小さいため、関心の分離を厳密に行うのはやり過ぎであり、そのアプローチは状況に適している可能性があります。または、彼らがしていることはとても複雑ですこれがそれを処理するための最良の方法であること。より複雑な配線や統合、またはプラグインモデルなどがある場合は、一見過度に複雑なタイプが、一貫した柔軟なインターフェイスを保証するものになる可能性があります。ある場所で少し複雑にすると、別の場所でかなりの複雑さが軽減される場合があります。しかし、多くの場合、これは当てはまりません。私の推測では、あなたが悪いと思うのは本当にです。。。悪い。
- 多くのマイクロソフトのクイックスタートデモ とテンプレートは、本当に悪いアーキテクチャを持っています。Webフォームモデル自体は、関心の分離に適していません。スパゲッティコードの悪夢である公式の例がたくさんあります 。ビジネス、DB、およびユーザーインターフェイスが共存することは、ひどい調和です。
- サードパーティのSDKについて話している場合、これらの多くはC ++から移植されたため、ビジネスオブジェクトに渡される複合型を必要としますが、オブジェクト指向に実際に改訂されることはありません。いくつかのイメージングソフトウェアオブジェクトに渡すために、いくつかの非常識なタイプを作成する必要がありました。論理的には、2つの単純な値パラメーターのみが必要でした。
于 2009-12-17T18:48:45.987 に答える