問題タブ [separation-of-concerns]

私は「ブログプレビュー」のテンプレートを持っています。これは基本的に、リスト内で繰り返すために構築された簡潔な構造のブログのサムネイル、タイトル、および短い抜粋です。

上で示唆したように、私は自分のサイトのトップ10のブログを、モデルのDBからプルし、それらをコントローラーに転送します。コントローラーは、ビューに関してそれらを提供します。ビューでは、結果をループして、ブログごとに新しい「ブログプレビュー」を入力する必要があります。

私の現在の解決策（MVCのルールに違反する可能性があると思います）は、ビューテンプレートでこれを行うことです：

どういうわけか、これはビューが許可されるべきではない何かのように感じますか？しかし、メインページテンプレート内の「プレビュー」テンプレートを他にどのようにループできるでしょうか。

ヘルプ？

Response.Redirect層の分離を正しく保ちながら、Model-View-Presenter パターンでa を呼び出す最良の方法は何ですか?

以下は、Ben Nadel のデモの単一ページで長寿命の AJAX アプリケーションからの JavaScript テンプレートの例です: [source]

そのような JavaScript テンプレート エンジンを使用する目的は何ですか? 帯域幅の節約のためですか？それは関心の分離の問題ですか？ブラウザのメモリ リークの問題に対処するのに役立ちますか?

テンプレート エンジンを使用する必要があるのはいつですか? また、生の HTML AJAX 応答を使用する方が簡単なのはいつですか?

関連する議論:

JQuery テンプレート エンジン

Python / PyQt で書かれた非常にデータ中心のアプリケーションがあります。主にまだ実際のテストが実施されておらず、明らかに変更する必要があるため、UI をコアから実際に分離するためにリファクタリングを行う予定です。

すでにある程度の分離があり、かなりの数のことを正しい方法で行ったと思いますが、完璧にはほど遠いです. どのようなことが私を悩ませているかを示すために、2 つの例を示します。

• ユーザーがデータ オブジェクトの表現を右クリックすると、ポップアップするコンテキスト メニューがデータ オブジェクトによって作成されますが、このデータ オブジェクト (基本的にデータベース行の ORM 表現) は明らかに UI とは関係ありません。 .

• データベースに何かが書き込まれ、書き込みが失敗した場合 (たとえば、データベース レコードが別のユーザーによってロックされているため)、従来の「再試行/中止」メッセージ ボックスがユーザーに表示されます。このダイアログは、データ プロバイダー* によって作成されますが、プロバイダーには UI 機能がないことは明らかです。明らかに、プロバイダーは代わりに例外を発生させたり、失敗を示したりすることができ、UI はそれをキャッチしてそれに応じて動作することができます。

  _{* これは、基本的にデータベース テーブルを表し、そのデータ オブジェクトとデータベース エンジンの間を仲介するオブジェクトに対して使用する言葉です。それが通常「プロバイダー」と呼ばれるものかどうかはわかりません}

私はテストの経験がないので、テスト可能性の問題などを簡単に「感じる」ことはありませんが、それに入る前に、いくつかの再編成を行う必要があります。

関連する複雑なビジネス ロジックはありません (主に CRU D だけです。はい、D がなくても) 。

私の計画は、Qt インターフェースの代わりに Web フロントエンドまたはテキストベースのインターフェースに置き換えるために、UI 部分を簡単に切り取ることができるという考えを念頭に置いてリファクタリングを開始することです。一方、Qt 自体は依然としてコアによって使用されます。これは、シグナル/スロット メカニズムがかなりの数の場所で使用されているためchangedです。

それで、私の質問: それはテスト容易性と保守性を向上させるための実行可能なアプローチですか? 特にPythonを念頭に置いて、他に何かコメントはありますか?

私は、ドメインロジックと永続性ロジックの懸念を分離するための最善の方法を模索しています。データアクセスにLinq-2-Sqlを使用しており、NerdDinnerチュートリアルに従っています。40ページを見ると、Linqで生成されたクラスのビジネスルールに部分クラスを使用していることがわかります。私にとって、それは間違っていると感じます（そうですか？）。アプリケーションのプレゼンテーション層に公開される独自のPOCOが必要です。ここでの1つのオプションは、個別のDTOクラスを使用することです。それは私には気分が良くなりますが、テストと保守のためにさらに多くのコードが追加されます。

部分的なクラスを追加してLinqクラスにビジネスルールを適用するという単純さは好きですが、データベースが変更された場合はプレゼンテーション層も更新する必要があるため、Linqクラスをプレゼンテーション層に公開するのは好きではありません。

データベースが変更された場合にプレゼンテーション層を更新する必要がないため、DTOアプローチはよりクリーンに感じられますが、処理するコードははるかに多くなります。

したがって、私の現在のアプローチは、2つのクラスライブラリです。1つはLinq-2-Sql DBML +部分クラスを持ち、もう1つは自動生成されたプロパティしか持たないクラスのセットを持ち、次に「リポジトリ」クラスからデータを取得することを管理します。 Linqアセンブリと変換IQueryable<T>.

もっと良い方法はありますか？より良い中間点はありますか？両方の長所を活かすことができますか？もしそうなら、どのようにそれらを異なるアセンブリに分離しますか？

アップデート

たぶん、私が本当にする必要があるのは、すべてのPersitence / Domainロジックを単一のアセンブリに統合し（NerdDinnerサンプルで使用されているのと同じアプローチ）、プレゼンテーション層に異なる「ビューオブジェクト」を作成することです。私のLinq-2-Sqlエンティティ？

サーバー側のコードがマークアップから分離されるように、コード ビハインド ファイルを使用したくない人がいるでしょうか? これは、従来の ASP に対する .NET の利点の 1 つではないでしょうか。

個人的には、コードとマークアップを混在させると、コードが理解しにくくなると思います。

私はそれらのくそ <% %> (サーバー側のブロック) がマークアップと相互接続されているのを見るのが嫌いです。これは、Classic ASP との下位互換性のためだけに ASP.NET にあると思いますが、MS の例には常に、黄色の括弧が含まれています。

ここでダウンロードできるコード例を理解しようとしていますが、ここに示されているサーバー側のブレークのいずれかが web.config で設定されているのに、コードを実行しても壊れない理由に戸惑っています。私は通常、コード ビハインドを使用するため、aspx のサーバー側コードについて、別の方法で処理され、runat=server コードのデバッグを妨げている何かがあるかどうか疑問に思っています。

そう。私の質問は次のとおりです。

1）サーバー側のコードがマークアップから分離されるように、コードビハインドファイルを使用したくないのはなぜですか?

2) サーバー側のロジックを中断できないのはなぜですか?

私の関連するコメントについても、あなたの洞察と意見を歓迎します。

「GET」または「POST」を実行し、出力ストリームを返し、出力ストリームを解析し、解析結果をインターフェイスに表示する必要がある HTTP リクエスト ディスパッチャーに使用する最適な設計パターンは何ですか?

現在、コンストラクターで UI クラスが定義されている HttpRequestDispatcher.java があり、スレッド化された run() メソッドで、結果が UIClass.requestSucceeded または UIClass.requestFailed に送信され、そこでストリームが解析され、結果が返されます。表示されます。

これに関する問題は、インターフェイス、パーサー、およびディスパッチャーの間で関心を分離したいということです。このようにして、将来、他の多くのクラスでディスパッチャーを実際に再利用できます...今のところ、「画面」ごとに1つのHttpRequestDispatcherが必要です...

アドバイスをいただければ幸いです、ありがとう！

大規模な ASP.NET MVC アプリケーションのビジネス レイヤーとデータ レイヤーを作成しようとしています。この規模のプロジェクトを試みるのはこれが初めてなので、本を何冊か読んで、物事を適切に分離することに細心の注意を払っています。通常、私のアプリケーションではビジネス ロジックとデータ アクセス レイヤーが混在し、複数のビジネス エンティティが 1 つのクラス内で絡み合っています (追加する場所を見つけようとしているときに、何度か混乱しました)。

私が読んできた内容のほとんどは、ビジネス レイヤーとデータ レイヤーを分離することです。これはすべて問題ないように思えますが、いくつかのシナリオでこれを行う方法を正確に視覚化するのに苦労しています. たとえば、管理者が新しい製品をシステムに追加できるようにするシステムを作成しているとします。

次に、リポジトリを作成してデータ アクセスを分離します。

製品の名前に少なくとも 4 文字を要求したいとしましょう。これをきれいに行う方法がわかりません。

私が持っていた 1 つのアイデアは、Name の set プロパティを拡張し、4 文字の長さの場合にのみ設定することでした。ただし、 Product.Name != 渡されたものを除いて、製品を作成しているメソッドが名前が設定されなかったことを知る方法はありません。

私が持っていた別のアイデアは、それをリポジトリの Add() メソッドに入れることですが、その後、ビジネス ロジックとデータ ロジックがすぐそこにあります。つまり、Add 呼び出しが失敗した場合、ビジネス ロジックまたは DAL が失敗したためです (また、モック フレームワークを使用してテストできないことも意味します)。

私が考えることができる唯一のことは、レポジトリの Add() メソッドから呼び出される第 3 層に私の DAL を配置することですが、私の本やweb (少なくとも私は見たことがある)。また、それが必要かどうか確信が持てない場合、ドメイン モデルの複雑さが増します。

もう 1 つの例は、名前が 1 つの製品だけで使用されるようにすることです。これは、Product クラス、ProductRepository の Add() メソッド、またはどこに入れますか?

補足として、私は ORM として NHibernate を使用する予定ですが、(理論的には) 必要なことを達成するために、TDD はすべてを分離できるはずなので、使用している ORM は問題ではありません。

前もって感謝します！

簡単な質問です。私は完全に間違っているに違いありませんが、この質問をする価値があると思いました。

View 内の ViewData["Message"] へのアクセスは、MVC で記述された関心の分離に従って正しいですか?

たとえば、コントローラーでは次のようになります。

ビュー内で呼び出します

別の方法 (関心の分離に違反しない) は、ビュー モデルにメッセージを設定することです。

たとえば、コントローラーでは次のようになります。

ビュー内で呼び出します

どんなアイデアでも大歓迎です。

ViewModel の使用と Automapper の利用に関するインターネットで見つかったすべての記事は、「Controller -> View」方向マッピングのガイドラインを示しています。ドメイン モデルとすべての選択リストを 1 つの特殊な ViewModel に取り、それをビューに渡します。それは明確で問題ありません。
ビューにはフォームがあり、最終的に POST アクションに入ります。ここでは、すべてのモデル バインダーが、[明らかに] 別のビュー モデルと共にシーンに登場します。[明らかに] 別のビュー モデルは、少なくともバインディングと検証のための命名規則の一部で、元のビューモデルに[明らかに] 関連しています。

それをドメイン モデルにどのようにマッピングしますか?

挿入アクションにすると、同じ Automapper を使用できます。しかし、それが更新アクションだったらどうでしょうか? リポジトリからドメイン エンティティを取得し、ViewModel の値に従ってプロパティを更新し、リポジトリに保存する必要があります。

補遺 1 (2010 年 2 月 9 日):モデルのプロパティを割り当てるだけでは不十分な場合があります。ビュー モデルの値に従って、ドメイン モデルに対して何らかのアクションを実行する必要があります。つまり、いくつかのメソッドはドメイン モデルで呼び出す必要があります。おそらく、ビューモデルを処理するために、コントローラーとドメインの間に立つ一種のアプリケーションサービスレイヤーがあるはずです...

次の目標を達成するために、このコードをどのように整理し、どこに配置すればよいでしょうか?

• コントローラを薄く保つ
• SoCの実践を尊重する
• ドメイン駆動設計の原則に従う
• DRYになる
• つづく ...