問題タブ [n-layer]

TableProfileProviderを使用して、n層アーキテクチャでASP.NETプロファイルシステムを使用しています。
UIレイヤーはWebアプリケーションであるため、プロファイルを使用できるようにするには、profilecommonクラスを公開する必要があります。
これが私のアーキテクチャの単純化されたスキーマです：
UI： ASP.NETWebアプリケーション。
BusinessEntities：純粋なPOCOクラス。パーシスタンスイグロナス。
BLL：ビジネスロジック層。
DAL：データアクセス層。

Profilecommonの定義は次のとおりです。

すべてがWebアプリケーションプロジェクトで定義されている単純な設計アーキテクチャでは、次のようにprofilecommonにアクセスします
。ProfileCommonstrongleyTypedProfile =（ProfileCommon）this.Context.Profile;

ビジネスロジックレイヤーからプロファイルコモンにアクセスできるようにしたいので、ProfileCommon定義をBusinessEntitiesライブラリに移動し（BusinessEntitiesライブラリにSystem.Webアセンブリへの参照を追加する必要がありました）、新しいProfileBLLクラスを定義しました。

これで、次のようにUIから共通のプロファイルにアクセスできます。

さて、Business Layer / BusinessEntities LibraryでSystem.Webを参照することは、n層アーキテクチャの分野に違反していますか？もしそうなら、これを達成するためにあなたは何を提案しますか？

管理者が C# を介してデータベースと対話し、要件に合わせて新しいテーブルと列を追加できる Web アプリケーションを構築しようとしています (非常に単純なデータベース スタジオのようなものです) が、スパゲッティ アプリケーションを作成するだけではありません。 .

だから私は、彼がテーブルを作成し、テーブルを使用してそれらを構築するときに、これらのものを動的に (自動的に) 許可する方法を理解しようとしています:

1- ビジネス オブジェクトまたはエンティティ (クラス、そのオブジェクトおよびプロパティ)。2- データ アクセス層 (データベースに接続し、項目 (オブジェクト) を取得、追加、更新、削除する単純なメソッド)。

これは可能ですか？それを達成する方法についての指針はありますか？

編集

リンクを開いたところです!! .. データ バインド コントロールなどについて話しています。.. 私の質問はそれよりもはるかに高度です!. N層アプリケーションを構築するときは、データベーススキーマと実装から始めます。プログラムで簡単に実行できます。次に、このデータベースで(追加、編集など、つまりCRUD操作)DALクラスの構築を開始して、このデータベースを形成します。

私がやりたいことは、Web 管理者がアプリケーションを介して新しいテーブルを追加することを選択できるようにすることです。その後、動的に、アプリケーションはテーブル名と列をパラメーターとして受け取り、新しいクラスを作成し、それらの中で実装する CRUD メソッドを定義します。 SQL CRUD 操作

次に、クラスを動的に作成し、それらの中で変数、プロパティ、およびメソッドを定義して、DAL メソッドを呼び出して使用します..これはすべて、テーブル、列名に基づいています

注 : これはすべて実行時に行われます。

N 層 ASP.NET アプリケーション: すべてのレイヤーに 1 つのクラス ライブラリを使用するか、各レイヤーに 1 つのクラス ライブラリを使用するか?

私は常に3層アプローチ（プレゼンテーション+ビジネスロジック+データアクセス）について聞いていましたが、それは私がいつも取り組んできた方法です（データベース自体を数える場合は「4」層を追加します）が、これはレイヤーとティアのアーキテクチャに関するすべて（レイヤーとティアの違いはすでに知っています）、5層以上のアプローチはありますか？コントローラー、サービス、アプリケーションティアについても聞いたことがありますが、これはコンテキストにどのように適合しますか？

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

n 層 (たとえば 5 層) アプリケーションで、特定の操作で層の 1 つをバイパスして次の層と直接通信するオプションがある場合、それを「n 層」アーキテクチャと呼ぶことはできますか? 、または（n-1）層（4層）アーキテクチャになりますか？

そして、バイパスできる問題のレイヤーは、「レイヤー」と見なす必要がありますか？

編集:次の構造を持つアプリケーションを実装しようとしています-
プレゼンテーション層(WPF グリッドを含む)
アプリケーション層(アプリケーション ロジックとワークフローをアプリケーション サービスとして含み、ドメイン モデル オブジェクトから表示モデル オブジェクトを抽出し、UI グリッドにバインドします) )
ドメイン層(ドメイン モデル オブジェクトのみを含む)
リポジトリ(データベースから取得したデータを格納し、上位層から下位層を分離する)
データ マッピング層(ドメイン モデル オブジェクトをデータ モデル オブジェクトにマップする)
データ アクセス層(データ モデル オブジェクト、データベースとの間でデータを保存および取得する)
-上記のそれぞれは個別のプロジェクトとして実装され、ドメイン層はアプリケーション層、リポジトリ、およびデータ マッピング層によって参照されます。アプリケーション層は、ドメイン層を介してではなく、リポジトリと直接通信しており、ドメイン層 (レイヤーと呼ぶことができる場合) は、横断的な参照のように機能しています。それが私の質問の出所です。それをドメイン「レイヤー」と呼ぶべきですか? 私はそうは思いません。しかし、ドメイン駆動設計にはドメイン層が存在しますよね? 私のアーキテクチャに何か問題があるのでしょうか? それはどこで、何ですか？

n層アーキテクチャのAsp.netアプリケーション（DDDアーキテクチャの場合に適しています）。

プレゼンテーション層には、製品のリストを表示する必要があるグリッド（たとえば、telerik radgridまたは標準のgridview）があります（製品は私のエンティティです）。

グリッド用のLinqdatasourceプロバイダーについて話すのは理にかなっていますか？このシナリオでどのように使用できますか？または、バインディング操作を「手動で」作成する必要があります（バインディングイベントをインターセプトし、アプリケーション層からgetproductlist関数を呼び出しますか？

例は大歓迎です...ありがとう。

私はかなりのサイズのwinformプロジェクトを開発するつもりです。ORMツールとしてEntityFrameworkを使用することを計画しています。現在、これらすべてを実装するためのアーキテクチャ（MVC / MVP / MVVMなど）を探しています。まず、Windowsフォームのn層アーキテクチャにはいくつかの選択肢があり、EFが市場に出る前に私が入手したもののほとんどは書かれています。codeplex（ http://rocketframework.codeplex.com）からRocketFrameworkというフレームワークを入手しました

私はそれを見回しましたが、それが幅広い要件に対応できるかどうかについては懐疑的です。誰かがすでにホイールをすでに発見している場合は、私を案内してください。また、EF4より前の既存のアーキテクチャがそれに対応できる場合は、試してみることができます。アイデアをお願いします！

私は多くのアーキテクチャ（N層およびDDD）を読んでいますが、ほとんどの記事はWebサイトのアーキテクチャに関するものであり、主にWindowsサービスを開発しています。
アーキテクチャを同じように使用できますか？

それで、私はここで仕様パターンに関するいくつかの投稿を見ましたが、これに対する答えはまだ見つかりませんでした。

私の質問は、n層アーキテクチャでは、仕様を正確にどこで「更新」する必要があるのか​​ということです。

1. それらをサービス層（別名、アプリケーション層と呼ばれることもあります...基本的には.aspxコードビハインドが通信するもの）に配置することはできますが、そうすることで、ビジネスルールを漏らしてしまうような気がします。ドメイン。ドメインオブジェクトが（サービスレイヤー以外の）他の方法でアクセスされる場合、ドメインオブジェクトは独自のビジネスルールを適用できません。

2. コンストラクターインジェクションを介して、仕様をModelクラスにインジェクトでき​​ます。しかし、繰り返しますが、これは「間違っている」と感じます。モデルクラスに注入する必要があるのは、キャッシング、ロギング、ダーティフラグトラッキングなどの「サービス」だけだと思います。それを回避できる場合は、モデルのコンストラクターを散らかす代わりにアスペクトを使用します。大量のサービスインターフェイスを備えたクラス。

3. メソッドインジェクション（「ダブルディスパッチ」と呼ばれることもあります???）を介して仕様を注入し、そのメソッドに注入された仕様を明示的にカプセル化して、ビジネスルールを適用することができます。

4. 「ドメインサービス」クラスを作成します。このクラスは、コンストラクターインジェクションを介して仕様を取得し、サービスレイヤーがドメインサービスを使用してドメインオブジェクトを調整できるようにします。仕様によって適用されるルールはまだ「ドメイン」にあり、ドメインサービスクラスは、調整しているドメインオブジェクトと非常によく似た名前を付けることができるため、これは私には問題ないようです。ここで重要なのは、仕様パターンを「適切に」実装するためだけに、たくさんのクラスとコードを書いているような気がすることです。

これに加えて、問題の仕様は、それが「満たされている」かどうかを判断するためにリポジトリを必要とします。

これにより、特にパフォーマンスの問題が発生する可能性があります。コンストラクタインジェクションを使用する場合、b / cを消費するコードは、おそらく仕様をラップするプロパティを呼び出す可能性があり、それがデータベースを呼び出します。

それで、何かアイデア/考え/記事へのリンクはありますか？

仕様を更新して使用するのに最適な場所はどこですか？

ASP.NET WebフォームC＃を使用して、ソリューションを最初から作成しています。

各レイヤーにモデルオブジェクトの重複セットを作成したくないので、モデルオブジェクトについて心配しています。の3層アーキテクチャでモデルオブジェクトを使用するためのベストプラクティスは何Web Formsですか？

私が考えている構造は次のとおりです。

• UI
• BLL
• DAL
• モデル

モデルには、レイヤーの各セクションで使用できるすべてのモデルクラスが含まれます。各レイヤーがモデルオブジェクトにアクセスする必要があるので、これは便利だと思いました。例えば：

1. UIは、データで満たされたモデルオブジェクトを渡すBLLのメソッドを呼び出します。
2. BLLは、データベースなどに保存されているオブジェクトを通過するDALのメソッドを呼び出します。

ありがとう