問題タブ [n-tier-architecture]

LINQ to SQL を使用する個人プロジェクト (C#/ASP.NET) に取り組んでいます。ソリューションには、(これまでのところ) Webform プロジェクト、Namespace プロジェクト (ビジネス ロジック)、および Tests プロジェクトが含まれます。これまでのところ、私は非常に初期の段階にいます (明らかに設計段階です)。

ここに 3 層アーキテクチャのパラダイムはありますか? この場合、DAL はまったく役に立たないようです。ビジネス ロジックから直接 LINQ クエリを実行する必要があるように感じます。

また、常駐の DataContext を 1 つだけ保持してそれを渡すと、開いている接続が 1 つだけ必要になることも思い浮かびます。これには、変更を細かくではなく一度にコミットするという追加の利点があります。それについて何か考えはありますか？

このスレッドを見つけましたが、不完全な絵を描いているようです。このテーマに関する詳細な記事はありますか?

標準的なアプローチに従う 3 層の .NET サービス アプリがあります。

私は途中で依存性注入について学ぼうとしていますが、これまでのところ、(Autofac を使用して) 素晴らしいことがわかりました。3 つの層のそれぞれは、さまざまなオブジェクトを作成する必要があり、場合によっては追加の構成などが必要になります。これを解決するには DI コンテナーが理想的であるように思われますが、システムの残りの部分との関係で、DI コンテナーがどこに存在するべきかを確認するのにいくつか問題があります。

現在、フロントエンドに DI コンテナーを構成するクラスがあります。それは基本的にコードの大きな束ですcontainer.Register<SomeType>()。

問題は、3 つの層すべてに対してコンテナーを構成しているため、データ アクセス レイヤーに関するかなり侵略的な知識が必要なことです。アプリを層に分割するポイントは、この正確な状況を回避することであるため、そのような知識を備えたフロントエンドにコードがあると、頭の中で警鐘が鳴らされます。
これは、データ アクセス レイヤーが単なる SQL サーバーではなく、多数の複雑な COM 相互運用機能と P/Invoke 呼び出しで構成されているため、DI に大きな影響を与えるという事実によっても悪化します。構成。

私はそれを分割することを考えました - おそらく層ごとに1つのコンテナーを持つか、グローバルDIコンテナーと通信して独自のビットを登録する「セットアップ」クラスを各層に持つことですが、それが原因かどうかはわかりません解決するよりも多くの問題...

多層アプリで DI を使用した経験を誰かが共有できれば、本当にありがたいです。

ありがとう、オリオン。

画面 DTO を使用してService LayerとPresentation Layerの間のデータをカプセル化するプロジェクトがあります。この場合、プレゼンテーション層は ASP.Net です。

DTO について知っている唯一のクラスは、サービス層クラスと、これらのサービスを呼び出して DTO を表示するページ/コントロールです。

DTO はほとんどの場合ページ/コントロール固有であるため、プレゼンテーション層に属していると思いますが、DTO を使用するには、サービス層がプレゼンテーション層を参照する必要があることを意味します。

私は、サービス層がより豊富なオブジェクトを返す必要があると考えています (ただし、ドメイン エンティティではありませんか?)。次に、プレゼンテーション層がこれらのオブジェクトを取得し、ページ/コントロールの懸念ごとに非常に具体的な DTO にマップできます。

ここにインターフェイス宣言と DTO があるので、私が話していることがわかります。

編集

ドメイン モデルが関与しないユース ケースを説明する別のコード サンプルを次に示します。多分これは物事を少し明確にするでしょう。DTO の意味を過負荷にしていると思います。私は、ネットワーク上でオブジェクトを転送する機能のための DTO について話しているのではありません。サービス層への通信間の契約を形式化するために DTO を作成しています。

たとえば、私の認証で突然 IP アドレス パラメータが必要になったとします。コントラクト インターフェイスを変更せずに、そのプロパティを DTO に追加できるようになりました。

プレゼンテーション レイヤーにエンティティを渡したくありません。自分のコード ビハインドに移動機能を持たせたくないBlogPost.AddComment(new Comment())

私は比較的小さなasp.netWebアプリケーションに取り組んでおり、完全なn層アーキテクチャを採用する必要があるかどうか疑問に思っています。サイズのアイデアについては; 約20のデータベーステーブルがあります。

以前は、ビジネスロジックとデータアクセスを1つのクラスライブラリにグループ化する2層アプローチを使用し、UI層を形成するasp.net Webアプリケーションを使用しましたが、これは問題なく機能するようでした。

n層を採用する必要があるしきい値サイズまたは経験則はありますか？

たとえば、Person（ID、Nameなど）というデータベーステーブルがある場合、データアクセス層はどのような種類のオブジェクトをビジネス層に戻す必要がありますか？私はこのようなことを考えています：

しかし、これはすべて少し面倒に思えますか？この問題に対するより洗練された解決策はありますか？代わりに、データアクセス層からビジネス層にDataRowを返す必要がありますか？

必要

1. CSLA展開でシングルティアからマルチティアに移行する際に必要な構成変更の迅速かつ迅速なリスト
2. 上記のチェックリストの詳細な説明
3. リストする方法

以前、私のASP.NETWebアプリケーションはADO.NETを使用してデータベースに直接接続していました。次に、ASP.NETレイヤー、ミドルWebサービスレイヤー、バックエンドデータベースレイヤーの3つのレイヤーに変更します。データソースをASP.NETフロントレイヤーに抽象化し、緩く結合し、潜在的なセキュリティリスクを減らして、外部に公開されたASP.NetWebアプリケーションがデータベースに直接アクセスできるようにするなどの利点があると思います。

2層アーキテクチャと3層アーキテクチャを比較すると、2つの大きな問題が発生しました。

1. 追加の中間Webサービスレイヤーでは、より多くのトラフィックが発生します。たとえば、ASP.NETはデータベースと直接通信しませんが、Webサービスと通信し、Webサービスがデータベースと通信すると、より多くのトラフィックが発生します。ボトルネックになりますか？ボトルネックの場合、この問題を解決するための一般的なアドバイスはありますか？

2. ASP.NETはデータベースに接続できませんが、Webサービスに接続できるため、DataSet/DataTableオブジェクトを簡単に取得できません。テーブルフォームデータをデータバインドされたコントロールに提示することが難しくなります。ASP.NETのプレゼンテーション層のコーディングを容易にするためのアイデアはありますか？

よろしく、
ジョージ

ドメイン オブジェクトをクライアントに公開する方法に頭を悩ませようとしています。リッチ クライアントを使用している場合でも、Web を使用している場合でも、MVP とリポジトリ パターンを使用したいと考えています。

私が理解しようとしているのは、サーバー上にあるリポジトリとモデルを公開する方法です。状態を持つ複雑なビジネス オブジェクトを Web サービス経由で公開することは可能ですか? それとも、.Net リモーティング、EJB、COM+、DCOM など、言語/プラットフォームにとらわれない独自のテクノロジを使用する必要がありますか?

他のいくつかの制約は、複雑なドメイン オブジェクトをデータベースからロードし続けたり、操作を実行するたびにネットワーク全体に渡したりしたくないということです。いくつかの複雑なロジックは、オブジェクトの状態と組み合わせたユーザーのアクセス許可に基づいて、画面の特定の領域が無効または非表示になる可能性があることです。検証およびエラー メッセージ情報もユーザーに表示する必要があります。同じマシン上で実行されているかのように、多くのドメイン オブジェクト操作を論理的に呼び出すことができるようにしたいと考えています。

Web を使用すると、自由に制御できます。サービスの境界を越えてオブジェクトを公開する必要がないため、必要に応じてオブジェクトをリッチにすることができます。モデルを呼び出すクライアントが別のマシン上にある場合に機能する、リッチで機能する N-teir アーキテクチャを作成しようとしています。

Firebird（ストアドプロシージャ、ビューなど）に強く結びついている比較的大きなアプリケーションがあります。現在、追加のデータベースをサポートするための多くのリクエストが寄せられています。また、多くの機能をクライアントからサーバーに移動したいと考えています。

今は、3（4）層アーキテクチャに移行する良い機会のようです。DataSnap2009とRemObjectsSDK/DataAbstractについてはすでに見てきました。どちらも仕事をしているように見えますが、注意すべき長所/短所はありますか？他に推奨できるフレームワークはありますか？

乾杯、ポール