問題タブ [business-logic-layer]

次のように、BLL (ビジネス ロジック レイヤー) のないASP.Net 2.0アプリケーションを使用することは "許容" されますか?

1. SQL Server データ ストレージとストアド プロシージャ
2. ストアド プロシージャに接続するデータ リンク レイヤー (厳密に型指定されたテーブル アダプター)
3. DLL に直接接続するためのコード ビハインドおよび ObjectDataSource を含むプレゼンテーション レイヤー ASPX ページ

ビジネス ロジックがプレゼンテーションのコード ビハインドで完全に検証可能であっても、BLL は常に望ましいですか? BLL を使用しないことの潜在的な欠点は何ですか?

「ビジネスロジックを他のコードと混合してはならない」またはそのようなステートメントを何度も聞いたことがあります。私が書くすべてのコード（つまり、処理ステップ）は、ビジネス要件に関連するロジックで構成されていると思います。

誰かがビジネスロジックで正確に何で構成されているか教えてもらえますか？他のコードとどのように区別できますか？ビジネスロジックとは何か、そうでないものを判断するための簡単なテストはありますか？

かなり標準的な Web/サービス/データ アクセス レイヤード デザインを使用して、楽しみ/学習用の小さな Web サイトを構築しています。

サービス レイヤー/データ アクセス レイヤー クラスのインスタンスを常に作成する必要がないように、それらのメソッドをすべて静的にしました。ローカル変数などを使用し、リソースを共有しないため、同時実行の問題は発生しないはずです (現時点では、これについては十分に単純です)。

私が見る限り、これに対する唯一のトレードオフは、実際には真のオブジェクト指向アプローチに従っていないということですが、それでもコードをよりクリーンに保ちます。

これが実行可能なアプローチではない理由はありますか? 後でどのような問題が発生する可能性がありますか？必要に応じてサービスおよびデータ層クラスのインスタンスを返すことができる「ファクトリ」クラスを用意した方がよいでしょうか?

これは、この質問の特定のバージョンです。
重複する行を挿入していないか確認したい。アプリケーション層でプログラムで確認する必要があります。

または、データベースレイヤーによってスローされ、制約に違反したときにトリガーされる例外をキャッチする必要がありますか？

編集：言い換えると、制約は残っていますが（とにかくデータベース設計は優れており、テーブルにアクセスするのは私のアプリだけかどうかはわかりません）、制約に依存して、その違反を処理しますか？上がるか、とにかくチェックしたほうがいいですか？

EDIT2：もちろん、トランザクション内でチェック+挿入を行い、その間に他のプロセスが別のレコードを書き込んでいないことを確認するためにテーブルをロックします

周りを見回すと、ルール、検証、ビジネス オブジェクト (エンティティ) などを定義するための優れたコード スニペットがいくつかありますが、優れた適切に作成されたビジネス レイヤー全体を見たことがなかったことを認めなければなりません。

嫌いなものはわかっていても、何が素晴らしいのかはわかりません。

優れた OO ビジネス レイヤー (または優れたビジネス オブジェクト) を指摘したり、ビジネス レイヤーをどのように判断したり、優れているかを教えてもらえますか?

ありがとう

階層化されたアプリケーションがあるか、少なくとも階層化されたアプリケーションに移行中です。次のように分類されます。

• インターフェイス (ユーザー インターフェイスまたはアプリケーション インターフェイス、つまり Web サービスなど)
• ビジネスの論理
• データアクセス

この質問の残りの部分をより具体的にするために、特定のインスタンスについて説明します。

ユーザー インターフェイスがあり、その背後にコントローラー オブジェクト (ビジネス ロジック層) があります。このコントローラーは、別のオブジェクト (データ アクセス層) を介してデータベースと通信します。

特定のコンテキストでは、ユーザー インターフェイスを使用して、実行中の操作を関連付ける従業員をユーザーが選択できます。ユーザーが選択できる従業員に関するルールがあるため (実際には、コントローラーの外にあるすべての世界)、コントローラーはこれに対して 2 つのことを提供します。

• 選択可能な従業員のリストを含む読み取り可能なプロパティ
• 現在選択されている従業員を含む読み取り/書き込み可能なプロパティ

ユーザー インターフェイスはリストを読み取り、それを使用してコンボボックスに入力する場合があります。

このアプリケーションのバージョン 1 では、コンボボックスに従業員の識別番号と従業員の名前が含まれています。

すべては順調です...

... バージョン 1.1 まで、バグ修正。ユーザーは、ジミー オルソンとジミー オルソンのどちらかを簡単に判別できないため、ジミー オルソンとジミー オルソンのどちらかを選択できないと不満を漏らしています。彼は、ジミーが営業部門に 1 人、開発部門にもう 1 人いることを知っているので、この 1.1 バージョンの修正は、コンボボックスにスラッシュと部門名を追加するだけです。バージョン 2 では、コンボボックスを列をサポートするコンボボックスに置き換え、スラッシュを削除することを選択しましたが、1.1 では、さらなるバグのリスクを最小限に抑えるためにこれが選択されています。

つまり、コンボボックスには次のものが含まれます。

• 1 - ジミー・オルソン/セールス
• 2 - ジミー・オルソン/開発
• • 他の人

ただし、ユーザー インターフェイス コードには SQL コードや、その部門を把握する方法がないため、コントローラーに移動してそこでコードを確認する必要があります。コントローラーには部門は必要ありません。正直なところ、従業員の名前も必要ありません。識別番号だけで十分です。コントローラーには、部門に要求したり、何かをしたりするものは何もありません。そのため、データ アクセス レイヤーに降りて、そこで SQL を変更する必要があります。

この解決策は率直に言ってにおいがします。

このコントローラーに複数のインターフェイスがあり、要件が異なる場合、3 つの解決策が考えられます。

1. データ アクセス レイヤーを変更して、複数のインターフェイス (2 レイヤー離れた) の (増加/多様な) ニーズに対応します。これは、すべてのインターフェイスが必要なすべてのデータを取得する可能性があることを意味します。他のインターフェースの
2. ユーザー インターフェイスがデータ アクセス レイヤー (まだ 2 レイヤー離れている) に必要なものを通知できるようにするものを追加します。
3. 関係するコントローラーまたはアクセス層を変更せずに、何らかの方法でユーザー インターフェイス層が必要なデータを取得できるようにします。

上記の解決策はどれも気分が良くありません。

私が疑問に思っているのは、私たちは完全にコースから外れているのでしょうか? これをどのように行いますか？上記の 3 つの下に 4 つ目と 5 つ目の解決策はありますか?

この質問: Separation of Concerns に従って、受け入れられた回答には次の引用が含まれています。

関心の分離は、これらの関心のそれぞれのコードを別々に保つことです。インターフェイスを変更しても、ビジネス ロジック コードを変更する必要はありません。

これは単に、コントローラー/データ アクセス レイヤーが提供する必要があるのは、その仕事を行うために必要なもの (つまり、従業員の識別番号) だけであり、ユーザー インターフェイスがデータベースと通信して詳細情報を要求する必要があることを意味するだけですか?これらの特定の従業員について？

ローカルとオンラインの両方で動作するゲームを作成したいと考えています。

私が最初に考えたのは、GUI がビジネス ロジックに必要とするすべてのメソッドを持ち、ネットワーク実装とローカル実装を持つインターフェイスを作成することでした。

これは、要求応答メッセージに対してはうまく機能します。しかし、いくつかの GUI コンポーネント (すなわち JLabels) を更新しなければならない場合に、サーバーが送信するメッセージはどうでしょうか?

これに対する私の最初の解決策は、実装の各変更がイベントを発生させるリスナーを実装することでした。GUI は、そのコンポーネントを適切に登録および変更します。ただし、ビジネス ロジックでイベントを発生させる呼び出しは少し間違っているように見えます。

私は正しい軌道に乗っていますか？私はそうではないと思うからです。助言がありますか？

ありがとうございました。

注: クライアントは単純な Java Swing GUI です。

DTO

多くのユーザーに拡張したい Web アプリケーションを構築しています。また、Web サービスを介して信頼できるサード パーティに機能を公開する必要があります。

LLBLGen を使用してデータ アクセス レイヤーを生成しています (SQL Server 2008 を使用)。目標は、Web アプリを DAL の詳細から保護するビジネス ロジック層を構築すること、そしてもちろん、DAL を超えた追加レベルの検証を提供することです。また、現時点でわかる限り、Web サービスは基本的に BLL のシン ラッパーになります。

もちろん、DAL には独自のエンティティ オブジェクトのセット (CustomerEntity、ProductEntity など) があります。ただし、これらのオブジェクトには DAL 固有のメソッドが含まれており、アセンブリは DAL に固有であるなどの理由から、プレゼンテーション レイヤーがこれらのオブジェクトに直接アクセスできるようにしたくありません。したがって、アイデアはデータ転送オブジェクト (DTO) を作成することです。アイデアは、これらは本質的に、実際にはデータベース テーブル Customer である CustomerEntity のすべてのフィールドを持ち、おそらく一部の IsChanged/IsDirty プロパティを除いて、他のものではない単純な古い C#/.NET オブジェクトになるということです。したがって、CustomerDTO、ProductDTO などがあります。これらは基本 DTO クラスから継承されると思います。LLBLGen のテンプレートを使用してこれらを生成できると思いますが、まだ確信が持てません。

そのため、BLL はこれらの DTO オブジェクトを受け入れて返すことにより、その機能を公開するという考え方です。Web サービスは、それを使用するサード パーティのためにこれらのオブジェクトを XML に変換することを処理すると思いますが、多くは .NET を使用していない可能性があります (また、JSON を使用して、Web アプリの AJAX 呼び出しからスクリプトを呼び出すことができるものもあります)。

これを設計する最善の方法と、正確にどのように進めるかはわかりません。ここにいくつかの問題があります:

1) これをクライアントにどのように公開する必要があるか (プレゼンテーション層と Web サービス コード)

これらのメソッドを持つ1つのパブリッククラスがあり、すべての呼び出しがアトミック操作になると考えていました:

InsertDTO、UpdateDTO、DeleteDTO、GetProducts、GetProductByCustomer など...

次に、クライアントはこれらのメソッドを呼び出して、適切な引数 (通常は DTO) を渡します。

これは良い、実行可能なアプローチですか？

2) これらのメソッドから何を返すか? 明らかに、Get/Fetch のようなメソッドは DTO を返します。しかし、インサートはどうですか？署名の一部は次のようになります。

ただし、何を挿入するときに何を返す必要がありますか? エラーの通知を受け取りたい。ただし、一部のテーブルには自動インクリメント主キーを使用します (ただし、いくつかのテーブルには、特に多対多の自然キーがあります)。

私が考えた 1 つのオプションは Result クラスでした。

したがって、挿入時に、DTO は get ID (CustomerDTO.CustomerID など) プロパティ セットを取得し、この結果オブジェクトに配置します。クライアントは、Result.Error != null の場合にエラーがあるかどうかを認識し、Result.AffectedObject プロパティから ID を認識します。

これは良いアプローチですか？1 つの問題は、冗長な大量のデータをやり取りしているように見えることです (ID だけの場合)。一部の挿入にはそのような自動インクリメントキーがないため、「int NewID」プロパティを追加してもきれいになるとは思いません。もう 1 つの問題は、Web サービスがこれをうまく処理できるとは思わないということですか? 派生DTOではなく、ResultクラスのAffectedObjectのベースDTOを返すだけだと思います。さまざまな種類の Result オブジェクト (おそらくベースの Result から派生し、Error プロパティを継承する) をたくさん持つことでこれを解決できると思いますが、それはあまりきれいに見えません。

わかりました、これが言い過ぎではないことを願っていますが、明確にしたいと思います。

私は個人的なプロジェクトのために NHibernate をいじったり、学んだりし始めたばかりで、何かを「得られていない」と感じています。私はアプリが次のように機能することに慣れています：

プレゼンテーション層 --> ビジネス層 --> 永続層。たとえば、私のプレゼンテーション レイヤーは BusinessLayer.GetCustomer(id) を呼び出します。そのメソッドでは、呼び出し元が顧客を取得する権利を持っていることを確認します。OK、それでも NHibernate で問題なく動作します。私の質問は、更新、追加、および削除のセキュリティをどのように確保するかということです。たとえば、戻ってきた顧客を変更したいとします。通常、私はこれをしたでしょう：

繰り返しますが、UpdateCustomer メソッドは、この顧客を更新できることを確認します。わかりましたが、NHibernate を使用して顧客を更新するには、単純に FirstName を設定します。すべて透過的であるため、Update を呼び出す必要はありません。それが Hibernate のポイントです。「透過的で自動化された持続性」です。では、この透明性を確保しながらセキュリティ チェックを行うにはどうすればよいでしょうか。私は、間違いを犯して次のようなことをしないように、自分自身を十分に信頼していません。

おっとっと。データベース内のすべての顧客の名前を消去しました。これはわざとですか？はい。ここで、何らかの BusinessLayer チェックを行った場合、そのユーザーは他のユーザーの名前を更新できないため、例外がスローされます。

別の問題。私が管理者で、システム内で本当に何でもできるとします。次のようなコードがあります。

OK、ここでは注文をフィルタリングしたかったのですが、誤ってデータベースから削除してしまいました。透明性が原因で、私は非常に悪いことをしました。そのリスクをどのように軽減しますか？

私は本当にNHibernate を使いたいのですが、間違った方法で使いたくないのです。ヘルプ！:)

上記を行うには簡単なパターンが必要です。注意事項:

1）実際のデータの取得を行うクラスを使用する義務があり、DataTableを返します

2) 考えられるすべてのデータベース タイプをサポートする汎用インターフェイスには関心がありません。1 つのデータベース タイプに固執しています。

3) エラーをエレガントにトラップし、エラーが発生したことをユーザーに通知するにはどうすればよいですか。

4) MVC の学習を勧めないでください。現在、MVC はオプションではありません。

実際のパターンデザインに興味があります。