問題タブ [business-logic-layer]

アプリケーション用の BLL を構築しようとしています。私が見たり読んだりしたことから、BLL はステートレスであるべきだと思われます。これは、すべての BLL メソッドが静的である可能性があるということではありませんか? または、少なくとも各 BLL クラスのインスタンスが 1 つだけ必要ですか? なんらかの理由でこれは私には奇妙に思えるので、実験を深く掘り下げる前に、棒の端が間違っていないかどうかを確認したほうがよいと思いました.

また、データは状態を表すため、BLL オブジェクトにデータが含まれてはならないことも意味すると考えています。そのため、呼び出された BLL 操作ごとに、必要なデータを再クエリ (またはキャッシュからフェッチ) してから破棄する必要があります。それは正しいと思いますか？

ありがとう。

まず、誰かがだまされて悲鳴を上げる前に、私はそれを簡単なタイトルに要約するのに苦労しました。別のタイトルは、「ドメインモデルとMVCモデルの違いは何ですか？」だったかもしれません。または「モデルとは何ですか？」

概念的には、モデルはビューとコントローラーによって使用されるデータであると理解しています。それを超えて、モデルを構成するものについては多くの異なる意見があるようです。ドメインモデル、アプリモデル、ビューモデル、サービスモデルなどとは何ですか。

たとえば、リポジトリのパターンについて最近尋ねた質問で、リポジトリはモデルの一部であると空白で言われました。ただし、モデルは永続性モデルおよびビジネスロジック層から分離する必要があるという他の意見を読みました。結局のところ、リポジトリパターンは、具体的な永続化メソッドをモデルから切り離すことになっているのではないでしょうか。他の人々は、ドメインモデルとMVCモデルの間に違いがあると言います。

簡単な例を見てみましょう。MVCデフォルトプロジェクトに含まれているAccountController。含まれているアカウントコードの設計が不十分である、SRPに違反しているなど、いくつかの意見を読みました。MVCアプリケーションの「適切な」メンバーシップモデルを設計する場合、それは何でしょうか。

ASP.NETサービス（メンバーシッププロバイダー、ロールプロバイダーなど）をモデルからどのように分離しますか？それともあなたはまったく？

私の見方では、モデルは「純粋」であり、おそらく検証ロジックを備えている必要がありますが、ビジネスルール（検証以外）から分離されている必要があります。たとえば、新しいアカウントが作成されたときに誰かにメールを送信する必要があるというビジネスルールがあるとします。私の見解では、それは実際にはモデルに属していません。それで、それはどこに属しますか？

誰かがこの問題に光を当てることを気にしていますか？

私がクラスを持っているとしましょう

現在、データレイヤーで、IDataCommandのインスタンスを1つ作成し、FooIdをコマンドパラメーターの次のように設定するコードを記述しようとしています。

コード行に気付いた場合--param.value=（f.FooId> 0）？f.id：（object）DbNull.Value; 。私の質問はまさにこの分野にあります。パラメータが多すぎて提供できない場合。すべてのパラメータでこのような値をチェックすると、ちょっと悪いように見えます。ここでの質問は、この種のことを行うための最良の方法は何ですか？誰がそのDLまたはBLを行う必要がありますか？BLの場合、そこにDBNull値を割り当てる必要がありますか？これを行う他の標準的な方法はありますか？

コレクションとDataGridViewの間に双方向のデータバインディングを提供するには、UIにBindingListが必要です。ただし、ビジネスレイヤー（またはドメインレイヤー、サービスレイヤー、データレイヤーなど）からBindingListを返すのは正しくないようです。つまり、UI要件のためにBindingListのみを使用していましたが、このUIの必要性はドメインレイヤーと結合されます。

これを行うための「適切な」分離された方法は何ですか？IListを返し、プレゼンテーションのためにBindingListにコピーする必要がありますか？現実の世界の観点から、このオーバーヘッドは何か価値がありますか？

データソースとしてビジネスレイヤーメソッドを使用するグリッドビューがユーザーレイヤーにあり、グリッドビューでページングと並べ替えをサポートしたいと考えています。メソッドからIenumerableを返すと、すべてのデータが返されます。Take / Skipを使用してページの価値だけを戻すと、gridviewはデータのページが多いことを認識しません。

IenumerableをIQueryableに変更すると、データが既に破棄されているため、DataBind（）が失敗します。この問題は、クエリが実際に実行されるときに関係していると思います。また、クエリに適用しているフィルターに関係している可能性があります（以下を参照）。

ユーザーレイヤーコード：

ビジネスレイヤーコード：

複数の異なるアプリケーションで使用されている既存のデータアクセスおよびビジネスロジックレイヤーについて考えてみます。これまでは、データを使用した特定のアプリケーションの存続期間中、単一のデータ接続のみが必要でした。そのため、接続情報はデータによって簡単に取得できました。アプリケーションの構成ファイルからのレイヤー。ただし、今後は、データクラスとロジッククラスが、アプリケーションが呼び出しごとにデータ接続を決定するための柔軟性を提供する必要があります。さらに、クラスは、サービスを介して同時に複数のアプリケーションによって呼び出されるようになりました。

呼び出し元は、接続文字列を具体的に管理するのではなく、データ層内およびデータ層によって接続文字列に解決できる列挙型の接続名を管理する必要があります。

現在、すべてのデータとロジッククラスは静的であり、データのスコープは内部で、ロジックのスコープはパブリックです。

APIの使いやすさ、パフォーマンス、スレッドセーフ/呼び出し元の分離などを考慮して、呼び出し元からデータクラスのメソッドに至るまでキーを取得するためのいくつかの優れた戦略は何ですか。

2つの明らかなオプションは次のとおりです。

1. すべてのメソッドにパラメータとして接続キーを追加します。うん-起こることはないが、完全性のために含まれている。

2. ロジッククラスとデータクラスをインスタンスクラスに変更し、使用するメンバーメソッドのコンストラクターにキーを渡します。メソッドシグネチャの変更はありませんが、APIの呼び出し方法に大幅な変更が加えられます。

他にどのようなオプションがありますか？

3層アーキテクチャを実装しています。3 層アーキテクチャにおけるビジネス層の役割を知りたかっただけです。

エンティティ フレームワークを使用してアプリケーションを開発しています。PL、BL、DLでアクセスできるエンティティオブジェクトがあります。私の質問は、エンティティ オブジェクトへの入力割り当てを PL または BL にする必要があるかどうかです (save メソッドがあると考えてください)。

新しいクラスを作成したくないので、プレゼンテーション レイヤーからビジネス レイヤーにデータを送信するために匿名型を使用することにしました。

しかし、私の問題は、ビジネスレイヤーに匿名型を導入するにはどうすればよいですか? Vb.Net 2008 と VS 2008 を使用しています。

編集

実際には、その性質が本当に一時的なクラスであり、自分のプロジェクトでそれらを再び使用しないというデータを処理する必要があります。

データ アクセス層の作成には Entity Framework 4.0 を使用しました。次に、私のビジネス ロジック層には DAL と同じオブジェクトがありますが、いくつかの拡張機能 (つまり、より多くのプロパティ、いくつかの関数、セッターでのデータ検証など) があることがわかりました。

DAL と BLL を別々のプロジェクトに含めることを計画し、BLL でエンティティ クラスを使用してコードの冗長性を防ぐためのベスト プラクティスを探していました。

私が検索したところ、2つの主要なアイデアがあります。

1. 部分クラスによる同じプロジェクト内のエンティティ クラスの拡張
2. インターフェイスの使用 (エンティティ クラスおよび関連する BLL クラスによって実装されます)。前者はプログラマーの間でより人気があります。

上記のソリューションの欠点:

1. 部分クラスの一部として同じプロジェクトにコードを追加する必要があります。これは、プロパティとメソッドを追加するのには適していますが、何かをオーバーライドするのには適していません (つまり、ビジネス ロジック レイヤーでプロパティを設定する前に検証を追加するなど)。
2. エンティティ モデルが変更された場合は、エンティティ クラスからインターフェイスを手動で再度抽出する必要があり、BLL 関連のクラスにも別の変更が必要です (2 つの手動の回避策)。

私の質問は、関連するエンティティ クラスから BLL クラスを継承せず、メソッドとプロパティを拡張/オーバーライドしないのはなぜですか?