3

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

データアクセス

  • ストアド プロシージャのみを呼び出し、 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 つの理由としてよく引用されます。

4

3 に答える 3

3

ティア間の責任は少し混乱しているように私には聞こえます。データレイヤーはかなり標準的に聞こえます。（「いわゆる」）ビジネスレイヤーは、物事が混乱する場所です。

ビジネスレイヤーに関するいくつかの考え：

  • 多くのデータ表現があるようです。あなたはDataTables、DataSets、DataTransferObjectsについて言及しています。アプリケーション全体にわたる標準的なアプローチの方が適しています。

  • ReturnNthRecordSetFromStoredProcFooやReturnDataSetなどの名前のビジネスレイヤーメソッドは意味がなく、ビジネスサービスに適切なレベルの抽象化を提供しません。（たぶん、それらはアプリケーションからではなく、単に不十分に選択された例でしたか？）

  • 通常、ビジネスレイヤーは、DataSetパススルー以上のものを提供します。マッピングやヌルなどを処理する代わりに、ビジネスレイヤーは検証、ビジネスルール、セキュリティ、さらには監査に焦点を当てる必要があります（ただし、データベースでそれを行うことを好む人もいます）。

  • ビジネスレイヤーは単一のストアドプロシージャのみを呼び出していますが、ビジネスレイヤーのトランザクション制御に問題はありません。ビジネスレイヤーは、複数のデータオブジェクトがすべて同じトランザクションに参加できるようにトランザクションを制御する必要があります（異なるデータベースにまたがる場合もあります）。現在の呼び出しは1つだけですが、将来さらに呼び出しを追加する必要がある場合、これは簡単であり、アプリケーションにトランザクション制御を後付けすることにはなりません。

  • 依存関係は問題ないと思います。ビジネスレイヤーからのWeb.UIまたはSQLClientへの参照はありません。

  • 承認ルールもOKです。承認だけでなく、セキュリティも含めるように拡張します。また、ビジネスロジックはどこにも表示されません。ビジネスロジックがストアドプロシージャに含まれているかどうかだけ知りたいですか？推測すると、各ビジネスメソッドが1つのストアドプロシージャのみを呼び出すことを考えると、「はい」と言えます。もしそうなら、それは私にとって大きなノーノーです。


ビジネスレイヤーとデータレイヤーを組み合わせることはしません。私は、ビジネスロジック層とデータアクセス層を分離しておくことを好みます。それらを組み合わせるか、責任をもう少し分離しようとするかの選択を考えると、私は後者に傾倒するでしょう。

ただし、これが問題のある既存のアプリケーションであるかのように見ると、より実用的な観点をとることになります。すべてにコストが伴い、どのような変更が行われているのか、変更の労力とリスクは何か、変更の実際のメリットは何か、変更がテストサイクルにどのように影響するかを判断することが重要です。

考えるべき他のいくつかの質問は次のとおりです：あなたが対処したい主な問題は何ですか？それらは機能していますか（バグ、安定性の欠如など）？またはパフォーマンス関連？それとも建築ですか？または、おそらく保守性に関連しています-新しい機能を追加する必要がありますが、それは難しいと感じていますか？時間枠や予算はありますか？あなたがそれらの質問のいくつかに答えることができるならば、それはあなたを導くのを助けるかもしれません。

于 2009-07-31T04:39:04.570 に答える
3

サーバーの負荷に応じて、物理層の数を決定する必要があります。論理レイヤーの数は、実際には個人的な選択です。

私たちの組織では、CSLA フレームワークを使用しています。これは、データ レイヤーに柔軟性を与えながら、豊富なデータバインドされた UI を簡単に使用および維持できるようにすることを目的としたビジネス オブジェクト フレームワークです。

フレームワークを使用する価値があるかどうかを自分で判断する方がよいため、ここではあまり詳しく説明しませんが、言うまでもなく、null を考慮した独自の SafeDataReader クラスがあり、データセットを使用します。

その「dataportal」 (記事は古いですが、まだ関連性があります) を使用すると、データ アクセスを独自のレイヤーに簡単に移動できます。コードを変更する必要はほとんどありません。

DNRtvには、CSLA の設計者である Rockford Lhotka がサンプル アプリケーションの動作を示すビデオ ポッド キャストがいくつかあります。第 1部と第 2 部。

ショーはそれぞれわずか 1 時間で、使用するのが適切かどうかを判断するのに役立つでしょう。

于 2009-07-31T02:48:24.197 に答える
1

あなたがビジネスレイヤーとして説明しているものを、データレイヤータイプのものとして見ることを期待しています。私のデータレイヤーが、ヌルなどについて心配する必要がないようにしてくれることを願っています。また、私のビジネス レイヤーには、より抽象的なビジネス ルールと概念が含まれていることを願っています。たとえば、「グループ」が「ユーザー」のコレクションである場合、それらのユーザーを高レベルのグループの一部として操作するビジネス タイプの関数が必要です。たとえば、そのグループのすべてのメンバーにアクセス許可を割り当てたり、UI レベルでグループのメンバーとしてそれらのユーザーにポリシーを適用できるようにする機能が考えられます。それらがすべてデータベースに由来するという事実を隠そうとする関数を見たいとは思いません。これがお役に立てば幸いです。

于 2009-07-31T02:39:18.517 に答える