問題タブ [business-logic-layer]

メンバーの複雑な計算を行うアプリケーションがあります。各メンバーは、プロファイルにリンクされた米国の複数の州を持つことができます。州ごとに、メンバーが完了するコースごとに異なる計算が行われます。

今のところ、DB (SQL Server 2008) で計算を実行してから、アプリ層にデータを送り返し、そこで履歴を確認し、各コースの証明書をダウンロードしています。

私はビジネス ロジック層を持っていますが、そこではあまり起こりません。これはよく聞かれることだと思いますが、これらの計算をどこで実行する必要があると思いますか: ビジネス レイヤーまたはデータベース? 行ったり来たりです！！

GoでWebアプリケーションを書いています。これまでのところ、必要になるすべての基本ライブラリを作成しましたが、それは完璧に機能しました。パッケージ構造は、その点で非常に便利です。

ここで、アプリケーション自体、つまりビジネス ロジックを書き始める必要があります。このコードをどこにどのように配置すればよいか、少し迷っています。

私は、公式ドキュメント ページでほぼすべてのアプリケーション開発チュートリアル/ウォークスルーを見て読みましたが、それらは常にmainパッケージ/名前空間にドメイン ロジック全体を記述しています。

これは行くべき道ですか（申し訳ありませんが、しなければなりませんでした）、それとも単純にするためだけですか？

私の意見では、ビジネス層をパッケージに入れることは、不快なほど間違っているように感じます。

単一のビジネス ロジック クラスを使用して、さまざまなエンティティ フレームワーク クラスに対して同様の操作を実行したい状況があります。これらのクラスが部分クラス ファイルで実装するインターフェイスを定義しました。

ただし、これらのインターフェイス メソッドに対して LINQ to entities クエリを作成しようとすると、クエリがクラスのプロパティを直接使用するのではなく、インターフェイスを介して使用されるため、NotSupportedException が発生します。

データベース層への負担を軽減したいので、オブジェクトへの LINQ に頼らずにこれを達成する方法はありますか?

これは私の問題を示すコードです (ファクトリによって作成された汎用リポジトリ クラスを使用しています)。

私は、インターネット ユーザーにいくつかのサービスを提供するインターネット Web サイトに取り組んでいます。そこで、ビジネス チームの協力者が必要な情報を取得できる管理システムを用意しました。たとえば、過去 3 日間に登録された新規ユーザーは何人ですか? このように、管理システムには、いくつかのテーブルを条件で検索するためのページがいくつかあります。これらのページはよく似ています:

ユーザーID:[--------------] ニックネーム:[------------] 登録時間:[BEGIN]~[END] [検索]

検索結果はこちら

このクラスUserには、UserID/Nick/RegisterTime (およびユーザー テーブル) 以外にも多くのプロパティがありますが、条件として扱われるのは 3 つのプロパティだけです。だから私は次のUserSearchCriteriaようなクラスを持っています:

次に、データ アクセス レイヤーで、 search メソッドが type の引数を受け取り、UserSearchCriteria対応Expression<Func<User, bool>>するクエリを作成します。DAL の外にいる間、他の開発者は、基準によって提供される 3 つの条件でのみユーザー テーブルを検索できます。たとえば、Cityプロパティが "New York" であるユーザーを検索することはできません (これは通常、このプロパティにインデックスがないためです)。 DB、それでの検索は遅いです）。

質問 1:検索を囲むこの実装は正しいですか? 助言がありますか？

質問 2:ArticleSearchCriteriaなどのプロジェクトでより多くの基準クラスが見つかりFavouriteSearchCriteria、基準は今後ますます増えると思います。それらはほぼ同じ動作メカニズムを持っていますが、コードを繰り返す必要があります。より良い解決策はありますか？

PSこれらの情報が必要な場合: jQuery + ASP.NET MVC 3 + MongoDB

似たようなタイトルの質問を見ましたが、成功しませんでした。別のビジネスエンティティからデータをプルするために、ビジネスレイヤーからサービス参照を作成できますか？それとも、サービスレイヤーから実行する必要がありますか？

別のクラスを表すことを意図したクラスの標準名はありますが、それを区別します。

例は説明に役立つはずです。たとえば、私のビジネスレイヤーが、システムで実行されているプロセスに関する多くの情報を含む.NETのSystem.Diagnostics.Processなどのクラスのオブジェクトにアクセスできるとします。システムリソースプロジェクトなどの別のプロジェクトでは、これらの情報をすべて使用することはできないため、ビジネスレイヤーでは、重要と見なされる属性のみを含むクラスProcessInfoを実装します。

そのような中間の代表的なクラスの名前はありますか？

私はADO.NETを使用しています.DALとBALを作成しました.構造は次のとおりです.

サービスを使用して BAL を公開します。また、Web、ウィンドウ、モバイルなどの複数のアプリケーションがこの BAL を消費します。

SQL トランザクションをどこから開始すればよいかわかりません。複雑なエンティティを作成する責任者。

たとえば、複雑なエンティティは

エンティティを作成する必要があるのは誰ですか? BALかDALか。SqlTransactions はどこから開始する必要がありますか? 私はストアド プロシージャのサポーターであり、リクエストごとに 1 つのデータベース接続を使用することを好むため、これらのエンティティで遅延読み込みをサポートするにはどうすればよいですか

EntityFramework4でn層アプリケーションの設計に問題があります。

サーバー側、私のアプリケーションには3つのレイヤーがあります：-1つのサービスレイヤー（WCF）-1つのビジネスレイヤー-1つのDataAccessレイヤー（EF4と連携）

エンティティはPOCOであり、独立したプロジェクト/アセンブリに配置されます。

ビジネスレイヤーとDataAccessレイヤーのオブジェクトを作成するために依存性注入を使用しているため、インターフェイスのみを操作し、ビジネスレイヤーのEFに依存していません。

パフォーマンスを向上させるためにEFコンパイル済みクエリを使用したいと思います。

しかし、私の（ビジネス）クエリはビジネスレイヤーで定義されています。私のアーキテクチャでは、DataAccessはCRUDメソッドのみを提供しているためです。

したがって、コンパイルされたクエリはビジネスレイヤーで定義する必要がありますが、EFに依存しておらず、結合を緩めたくないので、そこからObjectContextを呼び出すことはできません。

また、DataAccessでクエリを定義することは、私のアプリケーション設計に適合しません。

では、ビジネスクエリをビジネスレイヤーからDataAccessレイヤーに挿入して、コンパイル済みクエリで使用できるようにする一般的な方法があるかどうかを誰かが知っていますか？

私は多くのことを試し、どこを見ても、これに対する答えを見つけることができませんでした...:(EFはその種のn層アプリケーションにうまく適合しないようです。

非常によく似た2つのSQLテーブルがあります。テーブルごとに異なるのは外部キーだけです。

ほぼ同じコンテンツを持つ 2 つのテーブル (FK が異なるだけ) を使用する場合、サービスとデータプロバイダー (ado.net pure を使用) で CRUD メソッドの複製を本当に作成しますか?

サービスとデータプロバイダー クラスで 1 種類の Get/Add/Update/Delete メソッドのみが使用されるように、サービスをどのように改善しますか? また、単体テストを重複させたくありません...

アップデート：

これはこれまでの私の解決策です：

BLL と DAL の Get/Add/Delete メソッドは、必要なすべての情報を含む UnitDTO オブジェクトを取得します。

このプロジェクトがチームで行われる場合、UnitDTO を作成し、それを各 CRUD メソッドの BLL に渡すときに、DAL でどの変数が使用/必要とされるかを知る必要があるという欠点があります。

どう思いますか？

(私は比較的経験の浅いプログラマであることを心に留めておいてください。OOP には継承に関する非常に多くの哲学があるため、この質問はあまりにもオープンエンドと見なされる可能性があることを認識しています。この質問は、私の思考プロセスに向けられています。つまり、経験豊富なプログラマーにとって正しいと思われるような方法でこのシナリオに取り組んでいますか? 私の考えが明らかに正確または不正確であることは何ですか?)

私は、コンピューター、プリンター、スイッチ、ルーター、携帯電話、ハード ドライブ、およびその他のデバイスを含む IT ハードウェアに関する情報を追跡するインベントリ システムを設計しています。私はデータベースを設計しており、現在フロントエンド アプリケーションを計画中です。アプリケーションでデータ アクセス レイヤー、ビジネス ロジック レイヤー、およびビジネス エンティティを使用する予定です。私はまだ概念的な計画段階にあり、この時点で実装の詳細を検討するべきではないことを認識していますが、私の心は前に進む傾向があります。検索機能が動作するはずの方法は、ユーザーが検索条件を入力して検索を実行することです。一致するデバイス (または一致する唯一のデバイス) のリストが返されます。デバイスのリストはある種のリスト ビューで表示され、デバイスを選択すると詳細ビューが表示されます。

最終的なビジネス エンティティで継承を使用するとアプリケーションにメリットがあるのか​​、不要な複雑さを追加するのか、それとも単純に間違っているのか疑問に思っていました。私の最初の考えは、図のようなセットアップです。

(これは実際の設計ではなく、この投稿の単純化された概念にすぎません) タイプ固有の属性を持つ各デバイスに加えて、任意の時点でデバイスはアクティブまたはアーカイブの 2 つの状態のいずれかになります。これをモデル化する方法がまったくわかりません。

このセットアップを使用すると、クエリがどのように機能するかを考え始めました。次のように、データアクセス層からデバイスの特定のサブクラスを照会するのは簡単に思えます。

擬似コード:

この質問を書くに至った問題は、「特定の場所からすべてのデバイスを取得する」などのクエリを処理する方法です。

基本クラスのオブジェクト参照がある場合、基本的なデバイスの詳細を表示してから、特定のデバイスの詳細を表示するにはどうすればよいですか? （クレイジーなキャストやリフレクションの使用を避けようとしています）。その場所の各デバイスには、サブタイプの特定の属性がありません。特定のデバイスに関するすべてのデータを表示したい場合は、残りのフィールドを取得するためにデータベースを再度クエリする必要があります。別のクエリを実行する必要があるのは、設計が不十分な兆候ですか? さらに、正しいタイプのデバイスをどのように判断すればよいでしょうか? おそらく、それぞれをテストする大きな switch/case ステートメントDevice.Type属性、正しいクエリを実行し、完全なサブタイプを返し、詳細をユーザーに表示しますか? または...完全なサブタイプのオブジェクトを含む個別のリストを返し、すべてのリストを繰り返し処理してリスト ビューに共通の属性を表示し、詳細ビューにサブタイプの詳細を簡単に表示する方がよいでしょうか?

これは継承の有用なケースですか、それとも誤用ですか? 私は現在、情報過多の問題に苦しんでいます。私は OOD について可能な限りすべてを読みましたが、頭の中に非常に多くのルールとガイドラインがあり、自分が正しいことをしているかどうかわかりません。脳が吸収した情報を適用しようとしているような気がするので、間違った実装を想像しています。コードの柔軟性を維持するための抽象化へのプログラミングに関するこのすべてのビジネスについて考え続けていますが、ある時点で具体的なクラスを処理する必要がありますよね? 私の見解では、継承は属性ではなく動作に関するものです。私は実際に行動をモデル化しているわけではなく (または、私と私はそれを見ることができないのでしょうか?)、デバイスに関するデータを収集しているだけなので、それらの関係を解釈するのが難しくなっています。これらのクラスは本質的に属性の愚かなコレクションであるため、それらはすべて別のクラスであるべきだと思います。繰り返しになりますが、すべてのクラスでフィールドが重複していますが、この場合は本当に問題になるのでしょうか?

OOD、継承、構成などに関する本がたくさんあることは知っています。私はそれらの本のいくつかを読みました。私は現在、さらにいくつかを読んでおり、オンラインで調査するのに何日も費やしました。誰もが分かりやすい継承の例を便利に使用しています。果物、動物、形の例について悪夢を見ています。

私の質問を読んでくれてありがとう、そしてあなたが提供できる情報や洞察に感謝します。その他のヒント、洞察、企業秘密、埋もれた宝物への地図、耐航性のあるボートと六分儀、または役立つと思われるその他の情報をお気軽に提供してください。