問題タブ [business-logic]

XSD スキーマを定義する際に、属性よりも属性グループを使用する利点は何ですか?

わかりました...それで、それらを他の場所で宣言して参照できます...

ほかに何か？

N + 1selectの問題をHibernate/NHibernateで回避する基本的な方法は知っていますが、適切な解決策を見つけることができない問題の変形に遭遇しました。

次の3つのエンティティがマップされています：アイテム、カテゴリ、顧客。アイテムは多対多でカテゴリに関連付けられ、カテゴリは多対1で顧客にマッピングされます。これまでのところ、特別なことは何もありません。

私のアプリケーションの標準的なクエリは、特定の顧客のすべてのアイテムを取得することです。これは、アイテムのカテゴリプロパティを調べるときにN + 1が選択されないように、アイテムのカテゴリを熱心に取得しようとして、次の基準を使用して行います。

ただし、これは機能しません。NHibernateは、後でアイテムごとに1つの選択でカテゴリをフェッチします。

NHibernateは、最初のクエリの結果が（Customerで）フィルタリングされ、クエリによって返されるカテゴリが完全ではない可能性があることを知っているため、後で別のクエリを実行してカテゴリを取得する必要があると私は信じています。 。（この仮定は正しいですか？NHibernateが正しい結果を保証するためにこのように機能しなければならないことは私には合理的であるように思われます。）

ただし、私のビジネスルール（またはあなたがそれらと呼びたいもの）によれば、アイテムは複数の顧客のカテゴリに属する​​ことはできないため、実際には、最初のクエリの結果が実際に完了していることがわかります。

私の質問は、NHibernateにこのビジネスルールについて何らかの方法で伝えることができるかということです。このタイプの状況でN+1選択を回避する別の方法はありますか（これはかなり一般的なようです）？

コードを整理しようとしています。サービス層、つまり DLL への参照を持つプロジェクトがいくつかあります。これが意味することは、新しいサービス レイヤーを配布するときに、通常は同じ多数のサービス レイヤーをアップロードする必要があるということです。

もちろん、ADD Reference を使用すると、あるアセンブリが別のアセンブリと通信するため、非常に高速です...

別の方法の長所と短所を知りたかった..

Web サービス/wcf を使用してサービス レイヤーをラップできますが、これはオブジェクトを無効にするものではありません..

速度についてはどうでしょうか。デスクトップ アプリケーションは、アセンブリ参照にアクセスする代わりに、Web サービス/wcf を呼び出す必要がありますか??

私のサービスレイヤーはもちろん私のデータレイヤーと通信し、クライアントはデータレイヤーと直接通信することはありません..

私のビジネスロジックがいくつかのアプリ間で共有されているサービスレイヤーの問題です..

デスクトップ アプリ、2 つの Web サイト、2 つの wcf プロジェクト (Web サービスとして使用)

コードを繰り返さずに最速のシナリオを達成する方法についてのアドバイス。つまり、現在行っていることに影響します。

各アプリ (デスクトップ、Web サイト、wcf) は同じ DLL にコピーがあり、参照があります (vs 2008 で参照を追加します) ..

アイデア？

Web アプリケーションを作成するために Java を使用しています。アプリケーションは、長いビジネス ロジックを呼び出す jsp にデータが送信されるフォームをロードする必要があります。jsp が「サービスをご利用いただきありがとうございます。処理が完了するとメールが送信されます。」のようなメッセージを返す必要があります。

問題は、次のようなものを書く場合です：

jsp は長時間実行され、ユーザーは操作が終了するまで待機する必要があります。さらに、ユーザーがブラウザーを閉じた場合、jsp が引き続き機能するかどうかはわかりません。

ユーザーがすべての実行時間を待つ必要がないように、長い操作をjspから分離するにはどうすればよいですか?また、長い操作の実行をブラウザに依存しないようにするにはどうすればよいですか?

ナオール

私の現在のプロジェクトでは、ビジネスロジックはストアドプロシージャ（1000以上）に実装されており、ビジネスの成長に合わせてスケールアップしたいと考えています。アーキテクトは、パフォーマンスとスケーラビリティを向上させるために、ビジネスロジックをアプリケーション層（.net）に移動することを決定しました。しかし、彼らは何も再設計/書き直していません。つまり、SPから起動される同じSQLクエリは、ADO.Netを使用して.net関数から起動されます。これはどのようにパフォーマンスを生み出すことができますか？

私の理解する限りでは、DBに依存しない必要がある場合、またはRDBMSエンジンよりもOOP言語でより適切に実装できるビジネスロジックがある場合（階層のトラバースや画像処理など）、ビジネスロジックをアプリケーション層に移動する必要があります。等..）。残りの場合、実装する複雑なビジネスロジックがない場合は、ビジネスロジックをDB自体に保持する方がよいと思います。少なくとも、アプリケーション層とDBの間のネットワーク遅延はこの方法で回避できます。

ご意見をお聞かせください。私は少しためらってアーキテクチャの決定を検討している開発者です。この件についての私の無知を許してください。

適格性などの概念に関するシステムのすべての計算を処理するDLLにコンパイルされるビジネスオブジェクトがあります。オブジェクトは、その周りのラッパーを介してDBへの接続も処理します。

この.NETDLLを取得して、レポートサービスレポート（SSRS）のデータソースとして使用する方法はありますか？複数の場所にロジックを配置したくありません。

編集
Webアプリ自体のWebサービスの機能を公開し、レポートをWebサービスに接続するのはどうですか？誰かが前にこれをしましたか？それが役立つ場合は、Webアプリにasp.netMVCを使用しています。

VisualStudio統合テスト環境を使用していくつかのテストを作成しました。これらのテストは、BLLメソッド（UIレイヤーが認識して対話する必要があるメソッドのみ）を呼び出すことにより、Webアプリケーションが行うことをシミュレートします...

したがって、それらの動作が正しい場合（テストに合格した場合）、多くの文献で推奨されているように、DAL /ストアドプロシージャなどの下位層のテストを作成する必要があるのはなぜですか？

完璧な世界では、プレゼンテーションや永続化レイヤーではなく、ビジネスロジック レイヤーで入力の検証(検証) を行います。実際には、どこにでも配置できます (または配置したい)。

簡単なサンプルを作成してみましょう ( JSF や ZK などのフレームワークを使用するWeb アプリケーション): 特定の入力フィールドは、0001 から 0500 までの 4 桁を受け入れます。

1. これを行うには、Web フレームワークの制約機能を使用できます。ユーザーにとって便利で、追加のサーバー負荷はありません。

2. ビジネス層 (java-ejb など) で実行できます。同じ ejb を使用するすべてのアプリケーションが同じ検証を使用するため、簡単です。評価後にユーザーにエラーを返す必要があるため、最終的には良くありません。サーバーとの往復が必要です。

3. 誰かが (永続層を介して) 数字以外の値または 4 桁を超える値を入力した場合、DB が失敗することに (部分的に) 依存する可能性があります。醜い。

再開: 1. と 2. で (冗長に) 実行します (ユーザーにとって使いやすく、すべてのアプリケーションで一貫性のあるものにします)。(さらに DB col の長さは 4 になります)

質問: この検証をどのように文書化しますか? テキスト ドキュメントまたは UML ダイアグラム ? ある意味で、最大 3 つの場所にビジネス ロジックがあります。複雑なシステムでは、これを追跡して理解することはほぼ不可能です。

上記のサンプルの実際のシナリオ: 4 桁から 5 桁に変更する必要があります。ドキュメントがなければ、変更が必要な場所を探す必要があります。

あなたは何を経験しますか？このためのヒントやツールはありますか?

乾杯
スヴェン

次のような列挙テーブルがあるとしましょう。

そして、私は注文に関するいくつかのビジネスルールを取得しました

最良の例ではないかもしれません。しかし重要なのは、「p.ShippingType == 1」の部分をどのように読めるようにするかということです。次の人がこのコードを保守するためにやってきたとき、彼は本番データベースを見つけて、すべてのビジネス ルールのテーブルをクエリして、彼らが何をしているかを理解する必要があります。

コードで列挙型を作成するだけでデータベースにデータを複製することを検討しましたが、それも良い解決策とは思えません。

このように階層化された基幹業務アプリケーションがあった場合、これは適切な分業でしょうか。

データアクセス

• ストアド プロシージャのみを呼び出し、 DTOのプロパティをハッシュ テーブルにマップします。ハッシュ テーブルは、ADO.NET コマンドのパラメーター コレクションを設定するために使用されます。

• SqlDataClient を参照するアセンブリのみ。

• マッピングコードで空白、null、および空を意味するものを扱う重要なロジックですが、それ以外の場合は検証やその他のドメイン固有のロジックはありません。

いわゆるビジネスロジック

• 複数の結果セットを個々の DataTable に分割します。

  public void ReturnNthRecordSetFromStoredProcFoo()

• データセットのデータアクセスへのパススルー。

  public void ReturnDataSet(string name){ return (new PersonController).GetAnotherDataSet(name);}

• DataTable の 1 行を 1 つのDTOにマップします

• マッピング コードで空白、null、および空を意味するものを扱う重要なロジック。
• 単一のストアド プロシージャ呼び出しをラップするためにのみ使用されますが、トランザクション オブジェクトを保持します。
• SqlDataClient への参照がないため、SqlDataReaders を使用して DTO を埋めることはできません
• System.Web.UI への参照なし
• 承認規則、それ以外のドメイン固有のロジックはありません。

UI

• ASP.NET フォームへの DTO の双方向データ バインディング。
• コントロールのプロパティの検証 - 通常、DTO に対して直接検証を行うことはありません
• 「コレクション」は、DataSet をグリッドにバインドすることによってナビゲートされます。実際、コレクションで何かをしようとすると、UI が DataTables の DataRows を反復処理し、適切な列名が何であるかを知る必要があります (通常、DTO に似ているだけです)。

最後に質問ですが、このアプリケーションでは、データ アクセス レイヤーは、いわゆるビジネス レイヤーの役割を引き受けるべきでしょうか? これは、余分なアセンブリの不都合を除けば、すでに 2 層 (ほぼ 1 層!) のアプリケーションではありませんか?

追加情報: わかりました。アプリケーション サーバーは、ユーザー数の少ないイントラネット アプリであるため、おそらく永遠に 1 台のマシンであることがわかっています。したがって、物理的に分離されたアプリケーション層を設計するべきではないことを私は知っています。また、おそらく 1 つの UI のみをサポートし、ASP.NET 以外のものをサポートする必要がある場合は完全に破棄されます。これは、層/レイヤーのもう 1 つの理由としてよく引用されます。