問題タブ [bll]

私はこのようなクラスを持っています.Webページが初期化されると、ロードされたページごとにこのクラスを開始し、この値をパラメーターとして他のクラスに送信します。

例えば ​​;

Student クラスは ActiveSeason プロパティを使用し、他のクラスもこれらの値をパラメーターとして使用します。

私の最初の質問、それを行うための最良の方法は何ですか.このクラスをどのように説明するか、たとえば、定数クラスまたは何. 2番目の質問は、それを行う簡単な方法はありますか.クエリごとにこれらのパラメーターを渡すと、コードが乱雑になり、読みにくくなります.

私の質問は、bll、dal、インターフェースに関連しています。

私のプロジェクトの構造は多かれ少なかれこのようになっています。 BLL、DAL、OBJ、および 3 層アーキテクチャ (質問とコードを繰り返さないため、ここにリンクを示します)

私の質問は、なぜインターフェイスを使用する必要があるのか​​、利点は何なのか、そして上記のプロジェクト構造に基づいてインターフェイスをどのように適用できるのかということです。リンクまたは回答を提供できますか。ありがとうございました

私はEntity Frameworkが初めてです（問題がある場合はコードを最初に）。私はそれを使ってきたので、最終的なドメインモデルと考えて、POCO クラスを構築してきました。遅延読み込みのようなものでは、これらのエンティティをプレゼンテーション レイヤーで直接使用して、実際に必要なものを遅延読み込みできるというアイデアが気に入っています。

しかし、私は最近、以前は聞いたことのなかったデータ転送オブジェクトについても知りました。それは絶対に理にかなっています。最終的なドメイン モデルの動作には、DAL に属さないビジネス ルールが含まれている可能性があります。たとえば、SalesOrderEntity Framework に与える POCO に のような最終メソッドが含まれているAddItem(Product)必要ProductがDiscontinuedDateありSalesOrder.OrderDateます。それは間違いなくBLLに属するもののように聞こえます.

つまり、これは、私が Entity Framework に与える POCO クラスは、DTO に似たものにする必要があることを意味していると思います。たとえば、プロパティのみを持ち、メソッドを持たない単純な小さなデータ ホルダーが、BLL のドメイン オブジェクトに (おそらく AutoMapper を使用して) マップされますSalesOrderDto。EmployeeDto、プレゼンテーション層に渡されますか?

私はここで正しい軌道に乗っていますか、それとも何かが欠けていますか. DTO の考え方は完全に理にかなっているので混乱していますが、Entity Framework のコンテキストで DTO が使用されているのを見たことがありません。

DAL をクラス ライブラリに何度も入れると聞いたことがあります。それは理にかなっており、アプリケーション間でのコードの重複を減らすことができるようにしたいと考えています。Entity Framework を使用してその DAL を構築することにしました。

ただし、N層アプリケーションについて私が理解していることから、DALは実際にはPOCOクラスを公開するだけであり、これをDTOのよ​​うに扱います。これを簡単にするために、私の DAL.dll は のようなクラスと のようなEmployeeDtoメソッドを公開GetEmployeeDtoByID(int ID)して、このレイヤーが最終的なドメイン モデルを生成しないことを明確にします。

しかし、完成したドメイン モデルを生成する再利用可能な DLL が必要な場合はどうすればよいでしょうか? 新しいプロジェクトを作成し、CompanyBLL.dll 参照を追加して、GetAllEmployeesここで公開されているクラスがそのオブジェクトのドメイン モデルの真の表現であることを認識して呼び出しを開始できると便利です。基本的に、私が作成する各プロジェクトは、必要なさまざまなツールの新しいプレゼンテーション レイヤーになります。

これらは、N 層アプリケーションのデプロイを開始するときに行うべき個人的な選択であることはわかっていますが、それは合理的な目標でしょうか? もしそうなら、DAL.dll を作成し、BLL クラス ライブラリを構築するときに実際に参照するだけですか? それらを 1 つのクラス ライブラリに結合する方が理にかなっているでしょうか。

作成するアプリケーションごとにビジネス ロジックを再構築したくないことに夢中になっているかどうか、またこれが正しい方法であるかどうかはわかりません。

私は、特にデータ アクセス層 (DAL) とビジネス ロジック層 (BLL) を含む n 層アプリケーションを持っています。オブジェクトを埋めるために使用する DAL で、SQL クエリとストアド プロシージャを使用します。

だからここに私の質問があります：

SQL クエリのORDER BY句は、関心の分離に違反していますか?

一方では、特定の順序でデータを表示する理由を決定するのはビジネス ルールであるため、並べ替えロジックはビジネス レイヤーに属しているように見えます。また、同じデータを複数の方法で表示したい場合もあります。さらに、データ アクセス コードは、表示方法などの懸念事項を認識していないはずがありません。

一方、データベースは一般に、アプリケーション コードよりもデータの並べ替えの効率が高いため、パフォーマンス上の理由から、BLL での並べ替えよりも ORDER BY 句を使用するインセンティブがあります。さらに、DAL で既定の並べ替え順序を指定することが、関心の分離に本当に違反するかどうかはわかりません。レコードは、何らかの方法でデータベースから取得する必要があります。最も一般的なシナリオに従ってそれらを並べ替えてみませんか? 既定とは異なる並べ替え順序が必要な場合は、BLL の何らかの方法で並べ替えることができます。

私は多層 MVC アプリケーションを開発しており、これまでに行ったことを確認しています。特に、私が戻って、多層/レイヤー (そこにはたくさんの情報がありますが、実際の一貫性や標準はありません) についてかなりの量を読み直したので、今は自分のデータレイヤーに疑問を抱いています.

私はそれを (良い設計に沿って) 間違って実装したのではないかと強く疑っています。これが私がやったことです：

WebUI

• コントローラー、ビュー モデル、ビューが含まれます

BLL

• 以下を含むサービス クラスが含まれます。

  1. コレクションなどのメモリ内操作コード
  2. エンティティへの EF linq などのデータ アクセス コード。

データ

• ドメイン クラスを含む /Models フォルダー
• DbContext クラスを含む /DAL フォルダー

...

一歩下がって再検討すると、これが私が見ているものであり、私が疑問に思っていることです：

1. BLL では、ここで EF コードが正しくないように見えます。データ層にある必要があります。誰か確認してくれませんか？

2. 私のデータ レイヤー (つまり、データ プロジェクト) には、コンテキスト クラスとドメイン モデルが含まれています。人々がデータ層を a) DAL と b) モデルに分けているのを読んだことがあります。したがって、DAL レイヤーにはコンテキスト クラスとデータ (EF) コードが含まれ、モデル レイヤーにはドメイン モデルのみが含まれると思います。これにより、合計 4 つのレイヤーが作成されます。過剰すぎるか、良いデザインですか？

3. EF から ViewModel へのマッピングに AutoMapper を使用する場所はありますか? 私は現在、Web レイヤーでマッピングしていますが、BLL の方が適切であると思われます。ドロップダウン リストの SelectListItem など、一部のマッピングは Web レイヤーでのみ実行できます。