問題タブ [n-tier-architecture]

これは本当に超基本的な質問です。

今日、n 層アーキテクチャを持つエンタープライズ CRUD アプリケーションを .NET で構築したいとします。どのデータ アクセス アプローチを使用すればよいですか? 相互運用性が必要なので、DataSet はリリースされています (そして、2003 年以降ではないと思います)。同様に、追加のサービスを介して非 Silverlight クライアントにその機能を公開する .NET RIA サービスの宣伝されている方法は、更新操作にはあまり説得力がないようです。私は、n 層の OOB をサポートしていない Entity Framework と何かを組み合わせることができたので、オプティミスティック コンカレンシーの類似性をシミュレートするために多くの奇妙なリフレクション タイプのものを必要としました (MSDN マガジンの例はそうではありません)。オプティミスティック コンカレンシーをサポートしているように見えます。これは EF4 で改善されていますが、私は少し懐疑的で、CTP 以外ではまだ実際には利用できません)。

では、更新チェック済みのオプティミスティック コンカレンシーを使用したエンタープライズ CRUD のプロジェクトで、実際に何ができるでしょうか? データセット? DTO を使用して DIY を行い、主はどれだけの作業が必要かを知っていますか? そして、それはバインドされたデータでどのように機能しますか? コレクションが DataGrid にバインドされているとします。変更のために CollectionChanged をリッスンする必要がありますか? 元に戻す場合に PK を比較できるように、変更のスタックを保持する必要がありますか? 悪夢のようです。

次に、オプティミスティック コンカレンシーの更新チェックが難しい要件ではない場合はどうでしょうか。じゃあ何？

基本的な3層設計を使用しています。柔軟性（およびテスト）の目的で、データレイヤーを抽象化し、コードで具象クラスを指定する必要がありました。しかし、これをどのようにビジネスオブジェクトに渡す必要がありますか。次に例を示します（擬似コード）。

問題は、PersonBALがどのConcreteDataLayerを使用するかをどのように知るかということです。私はいくつかのオプションの間で考えています：

1：具体的なデータレイヤーを人に渡します。これは、データレイヤーと対話する必要のある新しいクラス（新しいPersonBAL（IDataLayer、int）、次に新しいJobBAL（IDataLayer、int）など）を追加し始めるときに苦痛になります。

2：使用するデータレイヤーを保持する静的オブジェクトを作成します（読み取り：グローバル変数）

他のアイデアはありますか？

負荷分散された n 層システム用の DB 接続マネージャーを設計するための最良のアプローチについて疑問に思っています。

従来の n 層は次のようになります。

私が見ている負荷分散ソリューションは、次のようになります。

図のように、ビジネス サーバー コンポーネントは複数のインスタンスを介して負荷分散されており、ハードウェア ゲートウェイがそれらの間で負荷を分散しています。

セッション サーバーは、重複してはならない状態を管理するため、おそらく負荷分散アレイの外に配置する必要があります。

これまでの設計に重大なエラーがなければ、DB 接続管理を実装する最良の方法は何ですか?

私はいくつかのオプションを考え出しましたが、私が気付いていない他のオプションがあるかもしれません:

1. DBServer と他のコンポーネントの間に新しい Broker コンポーネントを導入し、DB 接続を処理させます。

   • 利点は、すべての接続を 1 つのポイントから管理できることです。これは非常に便利です。
   • 欠点は、システムに「単一障害点」が追加されることです。他のコンポーネントは、何らかの方法で DB に関係するすべての要求に対してそれを通過する必要があり、これもボトルネックになります。
     
     

2. DB 接続管理を BusinessServer および SessionServer コンポーネントに移動し、それぞれが独自の DB 接続を処理できるようにします。

   • 利点は、追加の「単一障害点」またはボトルネック コンポーネントがないことです。
   • 欠点は、DBServer 自体が提供できるもの以外に、競合やデッドロックの可能性を制御できないことです。

他に何ができますか？

FWIW: テクノロジは .NET ですが、ベンダー固有のスタックは使用されていません (たとえば、WCF、MSMQ などはありません)。

この回答で、彼は、3 層ソリューションの作成中に RIA サービスを使用できること、それがどのように役立ち、どのように時間を節約できるかを述べました。通常のasp.net Webサイトを作成しています。

ASP.Net MVC アプリがあり、このアプリ (UI) がビジネス ロジック層 (BLL) を参照し、BLL がデータ アクセス層 (DAL) を参照しているとします。

承認のためにカスタム メンバーシップとロール プロバイダーを利用しています。

メンバーシップ プロバイダーを参照する必要があるレイヤーを特定しようとしています。

MVC では、次の方法で承認チェックを実行できます。

また、私の BLL では、ユーザーがロールに含まれているかどうかを確認することもできます。

これを行う場合、両方のレイヤーでメンバーシップ クラスを参照してインスタンス化する必要があります。これは、このようなアプリを設計する正しい方法ですか? 多くの冗長性のようです。

BLL があるので、"[Authorize(Roles = "SomeRoleName")]" 属性の使用を避け、代わりに MVC コード内から BLL 関数を呼び出して、ユーザーがロールに属しているかどうかを確認しますか? これを行う場合、MVC は認証のためにメンバーシップ プロバイダーへの参照を必要とし、ログインやその他の ASP コントロールを利用する必要があります。

基地から離れて間違った方向に進んでいませんか?

EntityDatasource オブジェクトを使用して、マークアップで宣言型データ バインディングを使用して構築された既存の .Net 単一層 Web アプリがあります。UI からレイヤー (ビジネス ロジック、データ アクセス) を抽出し、これを ntier アプリに移行しています。

このアプリは、宣言型データ バインディングを使用しています。例えば：

ntier 環境で宣言型データ バインディングが使用されていますか?それとも、ビジネス オブジェクトに手動でデータ バインドする必要がありますか?

アプリのタイプで宣言型データバインドを使用できる場合、実装方法を学ぶことができる場所を教えてくれる例はありますか?

BLL から LINQ クエリを実行して EntityDataSource を設定できると考えましたが、これが正しい方法かどうかはわかりません。

EntityDataSouce オブジェクトは n 層 UI で使用できますか?

n-Tiered/Distributed アプリケーションを .net でプログラミングする方法を学びたい場合、COM+/Remoting/Web Services/WCF からどのテクノロジを学び始める必要がありますか?

これらのテクノロジーは補完的ですか、それとも排他的ですか?またその程度は?

私は現在、.NET 3.5 フレームワークを使用した n 層 (3 層) ASP.NET Web アプリケーションに取り組んでいます。

n 層アプリケーションの「ベスト プラクティス」を利用して、可能な限り最速の方法でリスト コントロールとドロップダウン リストにデータをロードする方法を知りたいです。

最新の実行可能なテクノロジ (ASP.NET MVC、Entity Framework、UI 用の Telerik Combobox、AJAX など) を使用したベスト プラクティスは何ですか?

私のチームは、統合リポジトリの抽象化の背後にさまざまな異なるデータソースを隠すドメインモデルを設計中です。このアプローチの主な推進要因の1つは、これらのデータソースが近い将来大幅に変更される可能性が非常に高いことであり、これが発生したときにビジネスロジックを書き直したくありません。データソースの1つは、デフォルトのASP.Netメンバーシッププロバイダーを使用して最初に実装されたメンバーシップデータベースです。メンバーシッププロバイダーはSystem.Web.Security名前空間に関連付けられていますが、ドメインモデルレイヤーがさまざまな環境で使用されるため、System.Web（またはその他の実装/環境依存関係）に依存しないことを要求する設計ガイドラインがあります-また、Webサイトがデータベースと直接通信することも望んでいません。

MembershipProviderアプローチを抽象化されたn層アーキテクチャと調整するための優れたアプローチは何かを検討しています。私の最初の感覚は、ドメインモデルと相互作用する「DomainMembershipProvider」を作成し、リポジトリを処理して検証/ビジネスロジックを処理するオブジェクトをモデルに実装できるということです。次に、リポジトリは、（まだ決定されていない）ORM/データアクセスツールを使用してデータアクセスを実装します。

このアプローチに明白な穴はありますか？私はMembershipProviderクラスと緊密に連携していないため、何かが欠けている可能性があります。あるいは、上記の要件をより適切に満たすと思われるアプローチはありますか？

よろしくお願いします。

よろしく、ザック

ソフトウェア エンジニアとして、私はアプリケーション レイヤーでビジネス ロジックを記述することに強い偏見を持っていますが、通常は CRUD (Create Retrieve Update and Delete) 操作以外はほとんどデータベースに依存していません。一方、大量のビジネス ロジックがストアド プロシージャで記述されているアプリケーション (通常は古いアプリケーション) に出くわしたことがあります。そのため、データベース レイヤーでビジネス ロジックを記述することを好む人がいます。

ストアド プロシージャでビジネス ロジックを書いたり書いたりすることを楽しんでいる人のために、この方法を使用する理由は何ですか?