問題タブ [bll]

80% が複雑なビジネス ロジックで 20% が CRUD である、またはその逆のアプリケーションがあるとします。

過去に、私はある種のコマンドパターンを使用し、ComplexFooCMDorのようなクラスを持っていましEvenMoreComplexBarCMDたが、常にInsertFoo、UpdateFoo、DeleteFooおよびSelectFoosCMDいくつかのUpdateSomeValuesOfFooorで終わりましたSelectSomeFoos。これらはすべてBLLに住んでいました。

最近、あまり複雑でないビジネス ロジック アプリケーションで、次のようなクラスを持つサービス パターンを使用しましたFooServiceが、これらには期待されるinsertFoo、 、updateFooも含まれていselectSomeFooます。すべてのサービスでこれらのメソッドを使用したり、これらのメソッドをプレゼンテーション層に公開するためだけに存在するサービスを使用したりすることは、大量のボイラー プレート コードのように感じられます。

CRUD 部分とアプリケーションの残りの部分の両方に適合するパターンはありますか?それとも、アプリケーションのさまざまな部分に異なるパターンを使用する必要がありますか?

BLL と DAL の間の非常に厳密な境界を持つ小さなアプリを作成しようとしていますが、レイヤー間でデータ (ドメイン転送オブジェクト) を渡す最善の方法は何だろうと思っています。

BLL と DAL の両方からアクセスされるドメイン レベル (クラス ライブラリ) にいくつかのクラスを実装しました。これらのクラスは、基本的にプロパティ/データ メンバーのみを含み、現在 DAL データを反映しています。元：

次に、BLL にいくつかのクラスを次のように実装しました。

私の DAL では、Linq-to-Sql を介してデータベースから顧客レコードを取得します。次に、次の方法で linq オブジェクトを Domain オブジェクトにマップします。

したがって、私の考えでは、要求されたときに DAL から BLL への CustomerData インスタンスになりました (そして、Customer インスタンスを UI に渡す必要があります)。

私の BLL では、このように CustomerData インスタンスを受け取りますが、今はそれから Customer を作成したいと考えています。

質問:

1. BLL で Customer インスタンスを作成し、もう一度すべてのフィールド メンバーをコピーする必要がありますか?
   顧客 c = 新規顧客。c.field = CustomerData.field;
2. フィールド コピーの手順を実行せずに、CustomerData から Customer を作成するにはどうすればよいですか?
3. ではなく、合成を使用する必要がありますか?
   class Customer { CustomerData データ; }
4. 現在のレイアウトでこれを行うためのより効果的な方法 (コーディングを減らすなど) はありますか?
5. これを行うためのより良い方法はありますか?
6. 一般的なコメントはありますか?

ありがとう ！

以下は、DALメソッドを呼び出すコンソールアプリケーションのメソッドです。これをBLLメソッドでラップして、プレゼンテーションから直接呼び出すことができるようにするための最良の方法は何ですか？私は過去に、以下のようにDALからすべてを呼び出すプロジェクトに取り組んできましたが、BLLからすべてを取得するのが最善ではないでしょうか。

私は今、ASP.NET について非常に混乱しています。Web ページを取得するたびに、そのページによって参照されるビジネス モデルが作成され、表示がユーザーに送信された後、すべてが再び解体されると私は信じていました。

職場の同僚が、セッション、キャッシュ、アプリケーション、ビューステート、クエリ文字列、または投稿を使用せずに (私が知る限り)、ページ フェッチ間でビジネス レイヤー コードを格納しているように見えるこの単純な Web アプリを見せてくれました。

コードは次のとおりです。

ページの読み込み:

そしてシングルトンクラス：

ページを読み込むと、ボタンを押すたびにカウンターが増加します。しかし、Singleton インスタンスがフレームワークのどこに永続化されているのかわかりません。ページの読み込みの間に存在しないと確信していました。誰かがこれに光を当てることができますか? それは私を夢中にさせています。

ASP.NET Web フォームから MVC 2.0 に移行しています。ほとんどのプロジェクトでは、データベースと通信するための典型的なセットアップがあります。

共通(「SiteMenu」や「Users」などのオブジェクト/エンティティ)

ビジネス ロジック層(データ アクセス層への呼び出しを含む)

データ アクセス層

DAL には、共通のデータベース操作を行う DatabaseHelper、データベース固有の操作 (MySQL など) を行う OdbcHelper、およびすべてのストアド プロシージャを含む StoredProcedure クラスがあります。

この設計はリポジトリ設計にどのように変換されますか? NHibernate などの代わりに、独自のデータベース ヘルパーを使用したいと考えています。

何を提案しますか？

特定のロジックがデータ アクセス層とビジネス ロジック層のどちらに属するかについて、同僚と議論しました。

シナリオは、BLL が動作するデータを必要とすることです。そのデータは主にデータベースに存在します。そのデータを (System.Runtime.Caching を使用して) キャッシュして、後続の要求ですぐに利用できるようにします。アーキテクチャは、DAL と BLL が同じボックスと異なるアセンブリ (同じソリューション内のプロジェクト) に存在するようなものです。そのため、ワイヤーを介して DAL をヒットするなどの懸念はありません。

私の主張は、キャッシュをヒットするかデータベースをヒットするかの決定は、DAL の問題であるということです。ビジネス ロジック層は、データがどこから来るかを気にする必要はなく、必要なデータを取得することだけを考えるべきです。

彼の主張は、データアクセスレイヤーは「純粋」で「愚か」であるべきであり、キャッシュとデータベースのどちらをヒットするかを決定するロジックは、ビジネスロジックレイヤーにある必要があるというものです。

私の意見では、彼が言っていることは、関心の分離を弱体化させ、目標が物事を疎結合に保つことである場合に、レイヤーをより緊密に結合させることです。データの移動先を決定する特定のプログラム/UI 関数である場合、BLL がこれを制御したい場所がわかりますが、ここではそうではありません。これは、データベースがプライマリ データ ストアである非常に単純なキャッシュ シナリオです。

考え？

他のいくつかのアプリケーションで使用しているビジネスオブジェクトレイヤーがあり、MVCアプリケーションで使用したいと考えています。私の懸念は、より設計上の懸念です。次のようなものがあるのは正しいですか。

したがって、問題は、これを実行できるかどうか、代わりにモデルでこれを実行してこの文字列をモデルから直接返すか、BLLをモデルに書き換えるかということです。私は同様の質問でいくつかの答えを読みましたが、私ができるかできないか（むしろすべきかどうか）はまだはっきりしていません。このプロジェクトを学校の仲間に見せるので、パターンを壊したくありません。

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

ハンレット

私はコンテントネゴシエーションを使用しているので、リクエストのヘッダーに応じてJSON/XML出力を提供します。今、私はこの機能を提供するのに最適な場所はどこか疑問に思いました。

情報：BLL=ビジネスロジック層
DTO=データ転送オブジェクト
DAL=データアクセス層

DTOの擬似コードの例

BLLの擬似コードの例

1）BLLオブジェクトを使用するGUIの場合：BLLからのDTO結果をJSON / XMLに変換します
2）BLLの場合：次のようなもの... getObjectJSON（）-> DTO入力をJSON形式に変換して返します
3） DTOの場合：toJSON（）toXML（）toString（）のような動作
4）または1つのプロパティ（json / xml）のみを持つ追加のDTO
5）他に何かありますか？..。

*個人的には、（1）ロジックをGUIから除外する理由で間違っていると思います。（4）WebJsonExampleDTOやWebXmlExampleDTOのよ​​うな追加のDTOを1つのプロパティだけで使用するのはやり過ぎのようです。

私はすでにうまく機能する階層化されたデータアクセス設計を持っています。しかし、それが最も適切な実装であるかどうかはわかりません。
BLL クラスまたはメソッドが静的であるべきか、インスタンスが 1 つしかない concreate クラスであるべきかを知りたいだけですか?
その間、BLL クラスをシリアル化して、そのような SOA 設計で使用する必要はありません。しかし、この機能が何をもたらすかはわかりません。
次のオプションを見てください。

1. BLL クラスとメソッドは静的です
2. BLL クラスは静的ではありませんが、そのメソッドは静的です
3. BLL クラスは静的でもメソッドでもありません。アプリケーションは、メソッドにアクセスするために毎回 BLL クラスを作成する必要があります。
4. BLL クラスは静的でもメソッドでもありません。ただし、各 BLL クラスのインスタンスは 1 つだけです。アプリケーションは、これらの静的インスタンスを使用して、BLL メソッドを使用します。

主にパフォーマンスとデザインで最も効率的なのはどれですか?

編集：

オプション1

オプション2

オプション3

オプション4