サービス層、ビジネス ロジック層、およびデータ アクセス層に分離された WCF サービスがあります。

DAL で例外が発生した場合、そこでキャッチする必要がありますか?それとも、サービス レイヤーに戻しますか? なぜ？

このシナリオでのクライアントの関与は無視してください。WCF サービスで例外をログに記録することだけに関心があります。

特定のデータへのアクセスというビジネスレイヤーを強化できる必要があります。UIは、ビジネスレイヤーを呼び出して、ユーザーの詳細を受け取ることができます。その後、UIはユーザーに対して.Save（）を呼び出すことができ、ビジネスレイヤーはデータアクセスレイヤーを呼び出してユーザーを保存します。

ただし、ここでの問題は、ユーザーがuserdetailを受信して​​保存を呼び出すことができるようにするだけでなく、「admin」の役割を持つ認証済みユーザーのみを使用できるようにすることです。これを達成できるように、ビジネスレイヤー/ UIでこの認証/承認をどのように行うのですか？

UIにASP.NETを使用しており、メンバーシップ/ロールプロバイダーを読み込んでいますが、これは実際のUI用のようです。将来的にはいくつかの異なるUIが存在する可能性があるため、ビジネスレイヤーでセキュリティを確保する必要があります。たとえば、WindowsフォームやAsp.net。

考えや提案をいただければ幸いです。

ありがとう。

次のようないくつかのエンティティがあるソフトウェアを開発しています。

これらは私の EF4 POCO オブジェクトです。リポジトリ パターンと次のインターフェイスを使用しています。

リポジトリには内部 ObjectContext があります。私のリポジトリのインスタンスを含む UnitOfWork があり、それらに加えられた変更を保存する責任があります。

私はこれまでのところ正しくやっていますか？

次のようなビジネス ロジック レイヤーを実装しています。

今、私は正しい方向に進んでいるかどうか確信が持てません。私のPOCOは検証を担当しており、次のようなことができるようになります

これらのオブジェクトはコンテキストに関連付けられているため、それらを保存すると、コレクションへの変更もデータベースに保存されますか?

また、プレイグラウンドなしではワークスペースとサービスなしでプレイグラウンドを作成できないようにしたいと考えています。それらをどこで作成および削除する必要がありますか?

ありがとう。

私は開発の選択肢として NTiers の大ファンです。もちろん、すべてのシナリオに適合するわけではありません。

私は現在、新しいプロジェクトに取り組んでおり、通常の作業方法を試して、それをクリーンアップできるかどうかを確認しようとしています。私はとても悪い子で、プレゼンテーション レイヤーにコードを入れすぎていました。

私の通常のビジネス層構造はこれです（基本的な見方）：

• 仕事
  • サービス
    • FooComponent
      • フーヘルパーズ
      • Fooワークフロー
    • BahComponent
      • バーヘルパーズ
      • Bahワークフロー
  • ユーティリティ
    • 一般
    • ExceptionHandlers
    • 輸入業者
    • 等...

上記により、それぞれのヘルパーを介して Foo オブジェクトと Bah オブジェクトを直接保存するための優れたアクセスが得られます。

XXXHelpers を使用すると、それぞれのオブジェクトを保存、編集、およびロードできますが、オブジェクトを子オブジェクトと共に保存するロジックはどこに配置すればよいでしょうか。

例えば：

以下のオブジェクトがあります（私が知っているオブジェクトはあまり良くありません）

• 従業員
• 従業員の詳細
• 社員会員
• 社員紹介

現在、私はこれらすべてをプレゼンテーション層で構築してからヘルパーに渡しますが、これは間違っていると思います。データは、ビジネス層のプレゼンテーションの上の単一のポイントに渡され、そこで整理されるべきだと思います。

しかし、このロジックをどこに配置し、セクターを何と呼ぶか​​について、私は少し途方に暮れています。それは、EmployeeManager またはこのようなものとしてユーティリティの下に移動しますか?

あなたならどうしますか？私はこれがすべて好みであることを知っています。

より詳細なレイアウト

ワークフローには、DataRepository への直接のすべての呼び出しが含まれています。次に例を示します。

次に、ヘルパー プロバイダーがワークフローにアクセスします。

これは重複するコードを削減するためです。ワークフローで getBySomeProperty を 1 回呼び出してから、他の操作を実行してさまざまな方法でデータを返すことができるヘルパーで複数の呼び出しを行うことができるためです。悪い例は public GetByIdAsc と GetByIdDesc です。

DataRepository を使用してデータ モデルへの呼び出しを分離することで、モデルを別のインスタンスに交換することが可能になるということですが (そう考えていました)、ProviderHelper は分解されていないため、そのままでは交換できません。残念ながらEFにハードコードされています。アクセス テクノロジーを変更するつもりはありませんが、将来的には、代わりに実装したいと思うかもしれない、より優れたもの、またはすべてのクールな子供たちが現在使用しているものがあるかもしれません。

プロジェクト名.Core

プロジェクト名.プレゼンテーション

（アプリケーションの呼び出しが何であるかによって異なります）

テスト プロジェクト

シンプルな linq to SQL クエリ 製品オブジェクトが返される場合があります。明らかに、このオブジェクトをビジネス レイヤーに渡し、そのオブジェクトに対して直接データを読み取って更新することができます。

私は、linq クエリの実行に続いて、結果のオブジェクトが (automapper または手動で) カスタム ビジネス オブジェクトにマップされる一連の実装を見てきました。したがって、linq オブジェクトがある可能性のある製品の場合:

product.ProductId および Product.ProductName

次に、カスタム Product ビジネス オブジェクトを次のように定義します。

および次のようないくつかの単純なマッピング コード:

BusinessProduct myProduct = new BusinessProduct(); myProduct.ProductId = product.ProductId; myProduct.ProductName = product.ProductName;

次に、myProduct をビジネス レイヤーに渡し、変更し、読み取りなどを行い、後で linq オブジェクトを更新します。

カスタム BusinessProduct クラスを作成するのは、どのようなシナリオですか?

日付 私が興味を持っている特定の例を作成しました - しかし、同じカテゴリに分類される他のビットのデータがあります: 漠然と重要なエンティティについて取得したいデータです。

ビジネス ロジック (BL) とデータ アクセス レイヤー (DAL) のどちらが最適ですか?

これまで、テーブルへの挿入時に作成された日付を入力するために SQL Server に依存していましgetdate()たが、BL でこれをもっと行うべきかどうか疑問に思い始めています。

参考までに - これは主に、BL で (ユーザー入力に基づいて) オブジェクトを作成し、DAL でそれを起動する Web ベースのシステムで行われています。 (したがって、オブジェクトの作成時に BL で使用するためにオブジェクトに「作成日」プロパティを設定することは問題ではありません)。

おそらく3番目のオプションがあります-Marr75の回答を読んだ後、それを2回記録すると、いくつかのシナリオで役立つ可能性があることがわかりました（両方の場所で1回）。データレイヤーで一貫した日付/時刻の利点が得られますが、参照するBL駆動の値もまだあります-ユースケースに依存すると思います。ただし、このオプションにはリスクがないわけではありません。間違った日付を間違ったものに使用し始める可能性があります。

ASP.NET で Web アプリケーションを書き始めたとき、MSSQL サーバーへのデータベース アクセスに Linq-To-SQL マッパーを使用する小さなプロジェクトから始めました。
ある程度の経験を積んだ後、グラフィック レイヤー、ビジネス レイヤー、データ レイヤーを使用した従来の 3 層アプローチに切り替えました。データ層の唯一の機能は、挿入/更新/削除メソッドをロジックなしで提供し、ロジックを選択メソッドの形式で提供することでした。

時間が経つにつれて、GUI までデータベース クラスを提供しない方がよいことに気付きました (残念ながら時間がかかりました)。BL で実行されるすべての操作に使用され、ビジネス層からリストを取得する形式で GUI によって表示されるビジネス クラスを BL で使用するように切り替えました。
大きな利点は、データベース自体では表されない追加のプロパティを提供できることです。ただし、対応するビジネス層クラスをデータベース クラスにマップするメソッドを使用して、ビジネス層内でそのマッピングを自分で行いました。

それがO/Rマッパーが役立つところだと思いますか？今まで彼らの目的を理解できなかったが、やっと見つけた気がする。最近、.NET Framework 4 で新しい Entity Framework を使用してみましたが、Linq-To-SQL DataContext のようにしか使用していません。

マッピングを自動的に達成する方法はありますか? はいの場合、それは新しい Entity Framework が提供するものですか、それとも NHibernate のような O/R マッパーを探す必要がありますか?

ビジネス オブジェクトとビジネス サービスを含む独自のビジネス レイヤがあるとします。そして、"SilverLight ビジネス アプリケーション" (SL v 4.0 を使用) を作成することを決定し、開発予定の SL アプリケーションから既に使用されているビジネス レイヤーを使用したいと考えています。

SL プロジェクトではないプロジェクトを含めることができないことを知っています。

これを達成できるか教えていただけますか？

ありがとう

Web ベースのビジネス層関数のシグネチャの選択について意見が必要です。

function void CreateUser(Company UserCompany, 文字列名...)

また

function void CreateUser(int CompanyID, string name...)

これがウィンドウ ベースの場合は、int の代わりにオブジェクトを取る関数を選択します。これは、会社が既にウィンドウ フォームにロードされているため、それを利用しない理由です。また、ビジネスレイヤーはビジネスオブジェクトを取得する必要があり、タイプセーフです（誤って0または-1を渡すのを防ぎます）。

一方、これが Web ベースのアプリケーションの場合、id のみがクライアント サイトに読み込まれます。したがって、会社のオブジェクトをロードするのはちょっと冗長です。最終的には companyID だけがデータベースに保存されるからです。

私の説明があまり混乱しないことを願っています =P 読んでくれてありがとう。

ばかげているように聞こえるかもしれませんが、サービス層の必要性とビジネス層との違いを理解するのは難しいと感じています。

そのため、asp.net mvc 2 を使用しており、データベースですべてのクエリを実行するデータ アクセス レイヤーがあり、次に、実行する必要があるビジネス ロジックと検証を含むビジネス レイヤーがあります。最後に、基本的にすべてのビューを持つプレゼンテーション層があります。さらに、ライブラリの一部として、いくつかのヘルパー、DTO、およびビューモデル クラスが異なるフォルダーに含まれています。しかし、私はアーキテクチャについて読み込もうとしましたが、サービス層はアーキテクチャの重要な部分であるようです。

私が理解しているのは、サービス層はすべての機能を呼び出すものだということだけです。しかし、私たちのアプリケーションでサービス層の必要性を本当に見ることができませんか? または、すでに存在している可能性がありますが、表示されません...サービスレイヤーがどのように重要であるかを例を挙げて説明できる人はいますか? 私が読んだことからかなり似ているように見えるので、ビジネス層とどのように違うのですか? 最初に必要な場合は？私たちがやろうとしているのは、可能な限り最善の方法でアプリケーションを設計することだけです.それについてのあなたの考えや経験は何ですか?