問題タブ [n-layer]

VS2005 と C# のサンプル ソース コードを使用した n 層設計の正しいアプローチを示す Web リンクを提供してくれる人はいますか?

次のようなレイヤーを作成している場合、ある点で混乱します。

それでは、どうすれば真のOOPを達成できますか?

Coz OOP では、すべてのアクティビティをオブジェクト内にカプセル化する必要があります。

私の考えによれば、これは次のように階層化する必要があります。

しかし、このようなレイヤーを設計しようとすると、循環参照の問題が発生しました。

私の友人の 1 人が、Reflection でこの問題を解決したと教えてくれました。

それでは、ac# アプリケーションをレイヤーに分離する業界標準のアプローチとは何でしょうか?

切実な問題は、OR マッピングをホストするレイヤーはどれかということです。

アジャイル/XPは階層化されたアプローチと一緒に行くことができますか？

アジャイル/XPは階層化されたアプローチと一緒に行くべきですか？

ソースコードをレイヤーに分割するには余分な労力が必要であり、それによって開発時間が大幅に増加します。

注意：「レイヤー」とは、POCO、DAなどの個別のアセンブリを意味します。

DDD 方法論の研究に数か月を費やした後、私はこれらの概念を自社の実際の製品に適用し始めました。実際、私は将来の開発に適した保守可能なアーキテクチャを作成する任務を負っています。

次のテクノロジーを利用することにしました: EF4 (実際には v2)、Unity

私が得た情報の量は非常に啓発的でしたが、ベスト プラクティスとしていくつかの質問が残されています。

質問 #1: DTO - ベスト プラクティス

ドメイン オブジェクト (POCO クラス) があります。これらのクラスを実装するには、いくつかの方法があります。

1. 従来のアプローチ: パブリック ゲッター/セッター、検証、および適切なビジネス ロジックを含む POCO クラスを作成します。また、DTO を作成し、マッピング手法を使用してそれらを管理します。(オートマッパー)
2. 従来型 - DTO: 上記のように POCO クラスを作成しますが、POCO を転送オブジェクトとして使用します。ただし、ビジネスオブジェクトがドメインを離れてはならないことは私の理解です。
3. ハイブリッド:著者が POCO オブジェクトと DTO を作成している興味深いブログ投稿を偶然見つけました。ドメイン オブジェクト内に DTO のインスタンスを作成します。これにより、＃1のようにプロパティを複製しないため、保守が容易になります。そのようです：

質問 2: UI/サービス レイヤーから返されるオブジェクトは何ですか?

これが DTO の要点です。素の属性だけを含む、非常にシンプルで軽量なオブジェクトです。また、検証結果も含まれていません。DTO をシリアル化してクライアントに戻す場合、クライアントが InvalidRules コレクションのような検証結果を必要としていると想定する必要があります。

たとえば、Amazon の API を使用しているとします。個人ストアに本を追加したいと考えています。ISBN を送信せずに本を追加しようとすると、サービスはおそらく検証結果エラーを含む何らかの応答グループを返します。

何か不足していますか？私は、(少なくとも DDD の「純粋主義者」からは) DTO にはビジネス ロジックを含めるべきではないという印象を受けていました。DTO は転送オブジェクトとして十分な情報を提供していないように思えます。それか、DTO と検証結果をカプセル化する新しいタイプの Response オブジェクトが必要です。

質問 #3: どのくらいの IC が多すぎますか?

黄金律に従わなければならないことは明らかです。

「アプリケーションの変化する部分を特定し、同じままの部分から分離します。」

私にとって、これは IoC の適用に関して理にかなっています。依存関係を減らすために、私のプレゼンテーション、ビジネス ロジック、およびデータ アクセス レイヤーはすべて、IoC コンテナーを介して通信します。私のアプリケーション層には、共通のインターフェースと抽象化が含まれています。これ以上 IC を使用するのはやり過ぎのようです。モック テスト リポジトリを作成できる点が気に入っています。また、Unity の構成を変更するだけで、TDD を利用できます。

これらの質問を明確に述べたことを願っています。事前にご協力いただきありがとうございます。

この質問は私が解決策を見つけようとしている1年以来のように私を眠らせませんが...それでも私の心には何も起こりませんでした。これは非常に一般的な問題だと思うので、おそらくあなたは私を助けることができます。

私はn層のアプリケーションを持っています：プレゼンテーション層、ビジネスロジック層、モデル層。簡単にするために、私のアプリケーションのプレゼンテーション層に、ユーザーが顧客を検索できるフォームが含まれているとします。これで、ユーザーはUIを介してフィルターに入力し、ボタンをクリックします。何かが起こり、リクエストはプレゼンテーション層に到着し、のようなメソッドになりCustomerSearch(CustomerFilter myFilter)ます。このビジネスロジックレイヤーにより、シンプルになりました。モデルにクエリを作成し、結果を取得します。

さて、質問：データのロードの問題にどのように直面しますか？つまり、ビジネスロジック層は、その特定のメソッドがそのフォームだけで呼び出されることを認識していません。したがって、リクエストフォームに必要なのはCustomerオブジェクトだけなのか、LinkedOrderエンティティを持つCustomerオブジェクトだけなのかはわかりません。

私はもっ​​とよく説明しようとしています。私たちのフォームは、名前で検索している顧客をリストしたいだけです。それは注文とは何の関係もありません。したがって、ビジネスロジッククエリは次のようになります。

現在、これは正しく機能しています。2日後、上司から、他の顧客と同じように顧客を検索できるフォームを追加するように求められました。各顧客が作成した注文の総数を表示する必要があります。次に、そのクエリを再利用して、注文を添付（含む）してそれを取り戻すロジックを追加したいと思います。

このリクエストをどのように処理しますか？

これが私が今から持っていた最高の（私が思う）アイデアです。ご意見をお聞かせください。BLLのCustomerSearchメソッドはクエリを直接作成しませんが、次のようなObjectQueryを構成するプライベート拡張メソッドを通過します。

と

しかし、それは複雑すぎるように見えるので、これは私を納得させません。

ありがとう、マルコ

N層アーキテクチャの利点は何ですか？それはどのようにアプリケーションをより良くするのですか？

私はC＃でプログラムされた4層のWebアプリケーションを持っています... .Net 4.0：

• UIレイヤー
• ビジネスレイヤー
• データ アクセス層
• エンティティ レイヤー

データ レイヤーには edmx エンティティ レイヤーが含まれており、(t4 スクリプトによって生成された) POCO オブジェクトが含まれており、そのレイヤーは他のすべてのレイヤーで参照されています。

たとえば、新しい顧客を作成するために MVC フォームを作成する場合.... エンティティ レイヤーに名、姓などのフィールドを持つ顧客クラスが既にありますが、その自動生成された POCO クラスにはデータ注釈がありません。検証用... IE [必須] など フォーム送信時用

私の現在の解決策は、私の poco クラスとほぼ同じであるが、これらの追加の検証アノテーションを持つ新しいモデル クラスを作成することです。

私が知りたいのは、MVC モデル (UI レイヤー) で特定の POCO オブジェクトを使用する簡単な方法があるかどうかです。クラスをほとんど書き直す必要はありません...また、これらの POCO クラスを生成する t4 を変更する必要もありません ( 't4 の速度に達していません)。

これは、stackoverflow http://automapper.codeplex.com/の別の投稿から見ました... これでうまくいくかどうか、または最善の解決策であるかどうかはわかりません。

n層アーキテクチャについて質問があります。似たような質問がたくさんあるので、この質問をする前にじっくり考えました...しかし、文字通り1日半見て、これらの他の答えを読んだ後、私はまだ確信が持てません。一見似ているように見えるさまざまな用語と異なるアプローチは、私を混乱させました。

異なるクラスライブラリにBLLとDALがある場合、BLLとDALの間で通信する1つの方法は、BLLとDALの両方によって参照される別の別個のDLLで定義されたDTOのよ​​うなインターフェイスを利用することです。BLLの私のドメインモデルエンティティはこのインターフェイスを実装し、DALのORM生成オブジェクトも実装します。ビジネスエンティティを保存するために、それらをDALに渡すことができます。これにより、共有インターフェイスが実装されているため、正常に受け入れられます。このインターフェイスを実装するオブジェクトをBLLに戻すこともできます。これは、BLLとDALの両方が基本的なインターフェイスを認識するだけでよく、お互いに具体的な実装を認識する必要がないため、合理的と思われます。

私の質問は、反対側にオブジェクトを作成するための最良の方法は何ですか？たとえば、IPersonを実装するBLLにPersonオブジェクトがあり、IPersonも実装するDLLにPersonDataObjectなどがある場合、IPersonのパラメータを受け取るDALのメソッドにPersonを渡し、次にDALでI ' d永続化するには、PersonDataObjectを再構築する必要があります。これも最良の方法ですか？

申し訳ありませんが、私はかなり混乱しているので、おそらくこれをあまりよく説明していません。ダミーの回答のベストプラクティスをいただければ幸いです。

私のasp.netは非常に錆びており、ベストプラクティスに戻ろうとしています。そこで、Google を検索して例やサンプル、チュートリアルを探し始めましたが、何が見つかるでしょうか。「最新の」技術が石器時代にリリースされる前でさえ書かれがちな、古い無愛想なもの。

確かに、コンセプトはまだ持ちこたえているかもしれません。しかし、実際の実装は基本的に役に立ちません。私はLinq、n層（層ではない。層は層である可能性がありますが、層は必ずしも層であるとは限りません）を使用して何かを探しています現在のORM（L2S、EFなど）といくつかの実世界恣意的で役に立たない例ではありません。

誰にも指針がありますか？

新しいプロジェクトで MVC パターンを使用することを検討しています。データ層 (モデル) をプレゼンテーション層 (ビュー) に少し近づけることができるという主な利点がはっきりとわかります。アプリケーションの速度で。しかし、パフォーマンスの観点から離れて、view-logic-data 階層型パターンよりも MVC の利点は他にありますか?

編集: 興味のある方のために、MVC の使用をテストするために作成したサンプル PHP コードをアップロードしました。コードを読みやすくするために、意図的にすべてのセキュリティ チェックを省略しました。あまり批判しないでください。より洗練された高度なものになる可能性があることはわかっていますが、それでも機能します!!! 質問や提案を歓迎します: リンクは次のとおりです: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip

http://microsoftnlayerapp.codeplex.com/についてどう思いますか? データ アクセスの実装 (UnitOfWork、リポジトリ、トランザクション) に興味があります。これは、Microsoft テクノロジでこの問題を実装する「最良の」例ですか? UnitOfWork + Repository の実装とトランザクション管理について説明している興味深いサンプルや投稿があれば、共有してください。

編集:この実装に関する専門家の考えや、問題の解決に役立つ便利なリンクを知りたいだけです。