問題タブ [separation-of-concerns]

私は最近、CakePHP を使用して数年前に行ったプロジェクトを書き直し始めました。今回はすべてを「正しく」実行しようとしているので、誰かが次のことを行うための指針を教えてくれるかもしれません:

ビューで Model->find('all') を使用して、テーブルから単純なテーブルを表示しています。このテーブルには 2 つのブール型フィールドがあり、これらを組み合わせて、ユーザーに表示する必要があるものを構成しています。したがって、0x0 = 'A'、1x0 = 'B'、0x1 = 'C'、1x1 = 'D' です。このロジックをどこに置くべきですか？以下の方法を考えてみました。

1. 景色
2. ビューヘルパー
3. コントローラー
4. Model->find('all') がこの値を出力するようにモデル内に何か (それは可能ですか?)

このタスクは些細なことのように思えるかもしれませんが、このプロジェクトを最初から整理して保守できるようにすることを学ぶことができると思います。

ありがとう！

3層モデル（プレゼンテーション-ビジネス-データアクセスレイヤー）では、一貫して下位レイヤーを上位レイヤーに依存しないようにすることができます。たとえば、私のデータアクセス層は、それがどのように表示されるか、またはどのビジネスルールがその上で操作されるかを決して知りません。私のビジネスルールは、それらがどのように提示されるかに依存していません。

しかし、私はDemeterに許しを祈るか、少なくともStackoverflowの仲間にアドバイスを求めなければなりません。プレゼンテーション層のデータアクセスオブジェクトを参照せずに、ユーザーに「テーブル」を提示するにはどうすればよいですか。何度も、GridViewオブジェクトでADO.NETDataTableを参照していることに気付きます。現在、両方のレイヤーでサードパーティのツールを使用しています。テーブルは、OpenLinkのOpenComponentsテーブルオブジェクトからのものです。グリッドはInfragisticsUltraGrid（Windowsプラットフォーム）です。しかし、私は同じ違反で有罪です。

編集： 私はこれがWinForm3.5.NETでどのように行われるかについて特に興味があります。以下の私のコメントに注意してください。コメント内のリンクは私がすべきことだと思いますが、ドメインオブジェクトに夢中になる必要がないことを望んでいました。過剰なデザインで非難されたくありません。これは良いバランスですか？

サービス層と直接通信する (CRUD 操作、検証などを実行する) 「ブラック ボックス」ユーザー コントロールを作成することは、設計が不十分であると見なされますか?

「ブラックボックス」とは、ホストされているページとは無関係にデータを取得/保持することを意味します (IoC 注入サービスを使用)。各 UC をページにドロップするだけで機能します。これらの UC にはビジネス ロジックがまったく組み込まれていないことに注意してください (それはすべてドメイン層にあります)。

このアプローチは、次の 2 つの要因によって推進されました。

1. 私たちのアプリケーションには、基本的に同じビューのバリアントである (レイアウトがわずかに異なる) 多くのページがあります。

2. さらに、UI デザイナーは、ページの個々の部分を開いて編集できるようにすることを好みます。この概念を説明するための貧弱な試みについては、ここをクリックし てください。

   とにかく、UC に自分自身をレンダリングして永続化する能力/責任を与えることで、かなりのコードの重複をなくすことができるように感じました。

このアプローチが実際に「厄介」であると考えられる場合は、より魅力的な別のアプローチ (おそらく MVP ?) を提案してください。

ありがとう！

私の ASP.NET アプリケーションでは、データ、ビジネス、および UI レイヤー用に個別のプロジェクトがあります。

私のビジネス層は、DataAnnotations を使用して、宣言型の検証を行うプレーンなオブジェクトで構成されています。

問題は、それらを保存するときに、検証を処理する方法がわからないことです。それらはデータ コンテキストに直接バインドされておらず、別のデータ レイヤー オブジェクトにマップされているためです。

これらの種類のオブジェクトで検証をトリガーする方法はありますか?

1 人でプロジェクトに取り組んでいるときの最悪の事態は、通常、同僚から得られる情報が不足していることです。そして、それが欠けているために、明らかな間違いを犯す傾向があります。

しばらくその道を進んだ後、コミュニティからの助けが必要になります。

私は、ある種のポータルになる小さな自作プロジェクトを開始しました。そして、私を悩ませている主なものは、私が作成した永続層です。手始めにプレゼンテーション層から完全に分離する必要があり、OR マッパーもどこかにあります。これは、使用する必要があるデータ ストアが複数あるためです。

したがって、基本的な考え方は、個々の「リポジトリ」が個々のデータベースでそれぞれ動作し、ビジネス層がビジネス オブジェクトを集約し、プレゼンテーション層でビュー オブジェクトに変換するというものでした。

私が直面する主な問題は次のとおりです。

同じ概念に対する複数のクラス- ユーザーの DAL 表現とユーザーの BL 表現、およびユーザーのビュー表現があります。ツールで変換を処理できますが、これは本当に正しい方法ですか。つまり、それらはすべてうまく分離されていますが、オーバーヘッドはかなりのものです。

どう思いますか？懸念の分離のうさぎの穴に深く入り込みすぎているのでしょうか、それともこれはまだ正常ですか?

UIコンポーネントがデータ構造であってはならない理由を説明しようとしている別のプログラマーがいます。

たとえば、「データベース」からレコード セットを含むデータ構造を取得し、そのレコード セットをアプリケーション内の UI コンポーネントに表示したいとします。

このプログラマー (彼は無名のままで、彼は若く、私は彼に教えています...) によると、アプリケーション内で UI コンポーネントを描画するクラスにデータ構造をサブクラス化する必要があります!!!!!!

したがって、このロジックに従って、レコード セットは UI の描画を管理する必要があります。

******ヘッドデスク*****

UI 上の複数の種類のコンポーネントで同じデータ構造をレンダリングしたい場合、レコードセット自体に描画を要求するのは間違っていることはわかっています。レコード セットの基本クラスからレンダリングするすべての UI コンポーネントに対して、さらに別のクラスを拡張する必要があります。

私は、MVC パターンの「クリーンさ」を十分に認識しています (つまり、データ (モデル) を UI (ビュー) またはその上で行われるアクションと混同しないということです)。 data (コントローラーは多かれ少なかれ...まあ、実際にはAPIが実際にそれを処理する必要はありません...そして、コントローラーはできる限り少ない呼び出しを行い、どのビューをレンダリングするかを伝えます))しかし、それは確かにかなりきれいですデータ構造を使用して UI コンポーネントをレンダリングするよりも!

上記の例以外に、彼に送ることができる他のアドバイスはありますか? OOP を初めて学ぶときは、すべてを拡張したいという「段階」を通過することを理解しています。

デザインパターンがすべての問題の解決策であると考える段階が続きます...これも完全に正しいわけではありません...ジェフに感謝します。

この子をそっと正しい方向に向ける方法はありますか? 私の言いたいことを彼に説明するのに役立つ例は他にありますか?

私はモッキングと依存性注入に不慣れで、いくつかのガイダンスが必要です。

私のアプリケーションは、BLL が DAL を参照し、UI が BLL を参照するが DAL を参照しない典型的な N 層アーキテクチャを使用しています。かなり簡単です。

たとえば、次のクラスがあるとします。

それぞれが別のアセンブリに存在します。

MyBusinessLogic のテストで MyDataAccess をモックしたいと考えています。そこで、MyBusinessLogic クラスにコンストラクターを追加して、依存性注入用の IMyDataAccess パラメーターを取得しました。しかし、UI レイヤーで MyBusinessLogic のインスタンスを作成しようとすると、DAL への参照が必要になります。

MyBusinessLogic でデフォルトのコンストラクターを定義して、デフォルトの IMyDataAccess 実装を設定できると考えましたが、これはコードのように見えるだけでなく、実際には問題を解決しませんでした。署名に IMyDataAccess を持つパブリック コンストラクターがまだあります。そのため、UI レイヤーは、コンパイルするために DAL への参照を必要とします。

私が考えている解決策の 1 つは、IMyDataAccess パラメーターを使用して MyBusinessLogic の内部コンストラクターを作成することです。次に、テスト プロジェクトのアクセサーを使用してコンストラクターを呼び出すことができます。でもあの匂いはまだある。

ここでの一般的な解決策は何ですか。私は何か間違ったことをしているに違いない。どうすればアーキテクチャを改善できますか?

疎結合コンポーネントをサポートするために Web フォームでイベントを使用する方法を置き換えることができる ASP.Net MVC の機能はどれですか?

たとえば、Web フォームの単純なページャー コントロールを考えてみましょう。

1. ページ番号をクリック
2. ページャーは、新しいページ番号で「PageChange」イベントを発生させます
3. このサブスクライブしているページ/コントロールはイベントを受け取り、新しいデータを取得してバインドするための呼び出しの開始を処理します。

同様にサポートする ASP.Net MVC で使用できるツール

• 疎結合
• コンポーネントの再利用性
• 単一のページ/ビュー (非常に複雑な「ポータル」タイプのページなど) のロジックの分離。

ASP.NET MVCは、「関心の分離」というモットーを推進およびサポートしていると主張しており、これは素晴らしいアイデアだと思います。

ただし、コントローラー、モデル、またはビューを独自のアセンブリに分離したり、領域をアセンブリに分離したりする方法はないようです。

ASP.NET MVCの固定フォルダーとフォルダーを使用するとController、実際には、物事の巨大な寄せ集めを作成していることになります。それは関心の分離ですか？私とは正反対のようです。ModelView

だから私が疑問に思っているのは：

• コントローラー、モデル、およびビューでいっぱいのフォルダーを別々のアセンブリに分離するASP.NET MVCソリューションを作成するにはどうすればよいですか？

• ASP.NET MVC 2の領域を個別のアセンブリに配置するにはどうすればよいですか？

• または、他にどのように大規模なASP.NET MVCアプリを管理しますか？数十または100を超えるコントローラー、多数のモデルおよびビューモデルクラス、および数百のビューがありますか？

ユーザー インターフェイス コードをドメイン コードから分離しておくことが重要であることはわかっています。アプリケーションは、理解しやすく、保守しやすく、変更しやすく、(場合によっては) バグを特定しやすくなります。しかし、ここに私のメンタルブロックがあります...

Delphi には、私が望むことを行うメソッドを備えたコンポーネントが付属しています。たとえば、RichText Memo コンポーネントを使用すると、リッチ テキストを操作できます。TMS の文字列グリッドなどの他のコンポーネントは、私が望むことを実行するだけでなく、機能に対して追加料金を支払いました。これらの機能により、R は RAD に配置されます。

他の誰かがすでに私のために行ったことを行うために、私自身のクラスを書くのは非論理的です。これは車輪の再発明です [リッチ テキストを直接操作したことはありますか? :-) ] しかし、このようなコンポーネントに組み込まれた機能を使用すると、多くの UI とドメイン コードが混在することになります。ほとんどのコードがイベント ハンドラに組み込まれたフォームができてしまいます。

この問題にどう対処しますか？... または、他の人が既に私のために書いたコードを引き続き使用したい場合、問題にどのように対処することをお勧めしますか?