問題タブ [business-layer]

現在、sqlite を使用して Windows アプリケーションを構築しています。データベースには というテーブルがUserあり、私のコードには aRepository<User>と aがありUserManagerます。よくあるデザインだと思います。リポジトリにはListメソッドがあります：

で複雑なことをしたい場合、これは問題を引き起こしますUserManager.cs:

List<User>クエリが予想よりも早く実行されるため、返すとパフォーマンスの問題が発生することがわかります。今、私はそれを次のようなものに変更する必要がありますIQueryable<T>:

TableQuery<T>IQueryable<T>クエリを提供し、すぐには実行しない EFとほぼ同じ sqlite ドライバーの一部です。しかし、問題は次のとおりです。 ではUserManager.cs、 が何であるかがわからないTableQuery<T>ため、新しい参照を追加using SQLite.Queryし、ビジネス レイヤー プロジェクトのように名前空間をインポートする必要があります。それは本当に悪いコード感をもたらします。ビジネス層がデータベースの詳細を知る必要があるのはなぜですか? ビジネス層が SQLite とは何かを知る必要があるのはなぜですか? では正しいデザインとは？

私のビジネス レイヤーはファイルを作成し、それらをApp_Dataasp.net mvc 4 Web フロントエンドのフォルダーに保存する必要があります。

ビジネス層で使用して、フォルダーServer.MapPathの物理パスを取得できます。しかし、ビジネス層でのApp_Data参照は避けたいです。System.Web

App_Dataビジネス層へのパスを取得する他の方法はありますか?

私が書いているアプリの SharePoint ビジュアル Web パーツ フロントエンドがあります。実際には、同じ問題がどの ASP.net アプリケーションにも当てはまるように思われるため、それは私の問題とは関係がないかもしれません。

このアプリには、ビジネス ロジック クラスとデータ アクセス クラスがあります。ビジネス層からログ ファイルに書き込もうとしていますが、問題は、ビジネス層から SharePoint ユーザーのユーザー名を取得する方法がわからないことです。何か案は？

.net 3.5 と Visual Studio 2010 で C# を使用しています。

ありがとう！！

WCF / C＃N層アプリ。

このスニペットを基本的なガイドラインとして使用して、ビジネスレイヤーにページングを実装しました。

ページング機能をテスト可能にするために、ページャーをManagerクラスのパブリックプロパティにするか、コンストラクターに挿入する必要がありますか？ユニットテスト用のリポジトリをすでに注入していますが、注入のルートをたどりすぎるのは正しいとは思いません。

または、ポケットベルを非公開にしておく方がよいでしょうか。とにかくページサイズは設定ファイルで指定されるので、テストapp.configでページサイズを指定できると思います。

ERP システムにいくつかのサポート アプリケーション (かなり小さい) を作成しています。

したがって、これまで私はデータ アクセス レイヤーを 2 つの役割に使用していると感じていました。ビジネス レイヤーとデータ アクセス レイヤーです。

何を別のレイヤーに移動する必要があるか、また移動する必要があるかどうかを判断するのに苦労しています。いつレイヤーを分離するかを知ることは知恵であり、パターンを知ることは単なる知識であるとどこかで読んだことがあります。どちらも十分な量ではありません。

だから私は何が何であるかを判断するためにいくつかの助けが必要です.

私の現在の DAL は、データの取得と基本的なロジックの適用を扱っています。たとえば、次のようなメソッドがあります

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

等

それらを分離する必要がある場合、私は何をしなければなりませんか?

私の頭の中にあるもう 1 つの問題は、DAL を正規化し、毎回異なるエンティティを返すようにするために (1 つの一般的な get メソッドを介して) DataTable、戻り値の型として使用する必要があるということです。現在List<PalletRecord>、戻り値の型などを使用しています。

私のアプリは非常に小さいため、これら 2 つのレイヤーを区別するのは難しい (そしておそらく役に立たない) と感じています。

私の基本的なニーズは、複数のフロントエンド (Web ページ、WinForms、WPF など) で使用できるものを構築することです。

追加の例:

バーコードについて話しましょう。取得したロット レコードが有効かどうかを確認する必要があります。DAL でレコードを取得し、ビジネス レイヤーで bool を返すメソッドを生成しますか?

次に、テキストボックスに有効なロットが含まれているかどうかを確認するために、どのプレゼンテーションからでも bool メソッドを呼び出すことができますか?

これは非常に単純化されたロジックですか？

すべてのレイヤー BLL 、DAL 、および UI でクラス (コンクリートまたはインターフェイス) を共有する必要があります。

これは本当に悪い習慣ですか？

私は、DAL メソッドからデータ テーブルを返すのではなく、BLL が直接使用できるオブジェクトを返すことを好みます。

すべてのレイヤーが知っておくべきクラスを含む別の VS プロジェクトが必要です。

例: すべてのレイヤーが認識すべきロット クラスを定義したいと考えています。UI は、ユーザーが処理するロットを表示または送信できるようにするために、ロット クラスを受け取ることができる必要があります。また、DAL は、ロット クラスを使用してデータベースにクエリを実行し、それらを返すことができる必要があります。一方、BLL はこれらのロットを取得し、ビジネス ルールを適用する必要があります。

これが完全に間違っている場合、代替手段は何ですか?

複数のデータベース (現在はすべて MS SQL Server 2008 R2) を使用する大規模な Web アプリケーションがあります。このアプリケーションは約 7 年前のもので、EntitySpaces フレームワークを中心に構築されています。現在、このフレームワークのバージョン 2009 を使用しており、C# で .NET を使用して記述され、.NET 3.5 をターゲットにしています。

ES がなくなったので、これを別のものに変更する必要があり、何を使用するかを決めるのに問題があります。

私たちのデータベース スキーマは非常に成熟しており、私たちにとって完璧に機能します。このアプリケーションは、英国の 80 以上のサイトにインストールされています。

理想的には、既存のデータベース スキーマを指定して、ビジネスおよびデータ アクセス レイヤー クラスを生成するだけの同様の ORM ツールが必要です。必要に応じて、上位の .NET フレームワークに更新することは気にしません。

このアプリケーションは、Entityspaces オブジェクトの両方を利用し、いくつかのストアド プロシージャを呼び出してレポート機能を提供します。これは変更できないものであるため、パラメーター化されたストアド プロシージャを呼び出す機能は不可欠です。

私の質問は - 誰かがこれを行った経験があり、試してみるために使用するツールを推奨できますか?

前もってありがとう、アンディ

私は2つのサブプロジェクトを持つウェブサイトに取り組んでいます。サブプロジェクトは次のように参照されます:
=> 私の Web サイトにはプロジェクト ビジネス層への参照があります=
> プロジェクト ビジネス層にはプロジェクトデータ層への参照があります

訪問者はログインする必要があります。そこの情報は DB に保存されます。私のDBには、Webサイトが正しい情報を計算するために必要なさまざまな構成情報があります。

例:
ユーザー A が Web サイトにログインすると、構成情報がオブジェクト名: UserInfoに格納されます。UserInfo クラスもビジネス層の一部です。

その後、常に Cookie またはセッションからオブジェクトを作成し、次のようにビジネス レイヤー オブジェクトを呼び出す必要があります。
BL.CalculatePrice(UserInfo.RegionID)
BL.CalculateTotal(UserInfo.RegionID)

Webサイトからの各呼び出しで 参照(UserInfo.RegionID)を送信する必要なく、ビジネス層プロジェクトで Web ページの変更間で「ユーザー」オブジェクトの状態を維持する方法はありますか?

レイヤード アーキテクチャについて質問があります。私たちは階層化されたアーキテクチャを起草しており、データ層、ビジネス層、およびビューモデルを備えたフロントを持つことにしました。私の質問は、ビジネス層とロジックを配置する場所に関するものです。データ レイヤー (Web サービス レイヤー) はすべてのデータを取得し、データを独自のエンティティ (DataLayerEntityClassA と呼ばれるクラス) に変換します。ビジネス層には、この変換されたデータ (DataLayerEntityClassA) を取得し、並べ替えなどのロジックを実行するクラス BusinessLayerClassA があります。ロジックが終了したら、クラス DataLayerEntityClassA を継承する BusinessLayerEntityClassA を返します。クラス BusinessLayerEntityClassA は BL 層にあり、DataLayerEntityClassA エンティティを検索およびクエリするための単純なロジックが含まれています。これは良い習慣ですか、それともこの単純なロジックをクラス BusinessLayerClassA に含める必要がありますか? この方法で落とし穴はありますか?

問題がある場合は、c# .net 3.5 を使用しています。