問題タブ [separation-of-concerns]

私はより良い開発者になろうとしています...

私が取り組んでいるもの：

1. .Net MVC Framework 1.0
2. Entity Framework 3.5

私はいくつかの読書をしてきました、そして私がしたいことは次のとおりだと思います：

1. ドメイン内の各アグリゲートのリポジトリを作成します。たとえば、Orderリポジトリは、OrderのOrderItemを管理します。
2. ビジネスロジックを処理するサービスレイヤーを作成します。各リポジトリには、同様のメソッドを持つ対応するサービスオブジェクトがあります。
3. リポジトリとサービスの間を通過するDTOを作成します
4. おそらく、ビューが使用するクラスであるViewModelを作成します。

集約リポジトリインターフェイスが実装するベースリポジトリインターフェイスがあります...

私の注文リポジトリのインターフェースは次のように定義されています...この学習演習にさらに取り組むにつれて、追加のメソッドが存在する可能性があります。

私のサービスクラスは、各サービス実装にビジネスロジックが含まれていることを除いて、基本的にリポジトリと同じように定義されています。サービスはコンストラクターでリポジトリーインターフェースを取ります（この演習ではIoCの準備ができていませんが、それが最終的にはそこにあると信じています）。

1. リポジトリの実装は、EntityFrameworkを使用してデータベースからプッシュおよびプルします。データを取得するとき。メソッドはDTOのみを返し、EFで生成されたオブジェクトは返しません
2. サービス（私はそれらを呼んでいます）はリポジトリを制御し、ビジネスロジックを実行します。サービスは、コントローラーに表示されるもの、つまり_orderService.GetById（1）です。
3. ここでフリップフロップを開始し、フィードバックを使用できます...サービスクラスにViewModelクラスを設定させる必要があります... ViewModelクラスを持たない必要があります...多分、あるタイプから別のタイプへのマッピングが多すぎますか？

関心の分離に関して、私が向かっている方向性についてフィードバックをもらいたいと思います。

ありがとう

つまり、MVC が選択肢にない場合でも、MVP は次善の選択肢でしょうか?

私のように、グリーン フィールド プロジェクトに参加する余裕がなく、Web フォーム UI をリファクタリングしてプレゼンテーションをビジネス オブジェクトからより適切に分離したいと考えている人がいると確信しているので、ここで質問したいと思います。 .

私は、比較的小さな要件、機能強化、およびバグ修正を追加するタスクを負ったレガシー アプリケーションに取り組んでいます。

ここで取り上げるアプリケーションの部分は、リレーショナル データベースに永続化されるビジネス オブジェクトに対する一連の CRUD 操作の UI として特徴付けられる場合があります。

既存の UI は、MultiView コントロールを使用して、関連付けられたビジネス オブジェクト (1 対 1 の関連付けまたは 1 対多 / 親子) の編集間を移動します。はい、そうです - すべてが 1 ページにあります。残念ながら、UserControls の使用は非常に控えめであるため、マークアップとコード ビハインドは数百行の長さになります。

各ビューで、FormView はさまざまな ObjectDataSources を介してビジネス オブジェクトの CRUD を管理します。各 FormView の ItemTemplate 内で、さまざまなサーバー コントロールが ObjectDataSource のフィールドまたはメソッドにデータバインドします。

関心の分離をさらに導入し、ページのコード ビハインドから大量のコードを取り出したいと思います。

これまでの私の調査では、次のことを検討できることが示唆されています。

1. Model View Presenter のフレーバーを使用します。より具体的には、Web Client Software Factory の ObjectContainerDataSource を使用して、現在の UI と一連の新しい Presenter クラスの間のブリッジを容易にします。

2. MVC フレームワーク (オプションではありません) を使用してゼロから再構築します。

3. よく放っておきます。MVP パターンは、異なる UI シナリオでプレゼンテーションを再利用する必要がある場合にのみ正当化されますか?

(3) で解決したとしても、プレゼンテーションをより適切に分離するためにリファクタリングを開始する方法を知りたいと思います。

あなたならどうしますか？感謝して受け取った他のアイデア...

興味のある人のための背景を次に示します。

ドメインは製薬研究にありますが、それはかなり無関係であり、非常に典型的な基幹業務 (アプリケーションの別の部分の動作条件を形成する一連の設定のユーザー構成) と考えることができます。

ビジネス オブジェクト層は、非常に一貫した方法で既に構築されています。気に入らないかもしれませんが、必ずしも変更を正当化することはできません。各オブジェクトは、「ID による取得」および「条件によるリストの取得」のための静的メソッドがあるという点で、独自のリポジトリ/データ アクセス オブジェクトです。可能な場合、一般的な操作は抽象基本クラスで実装されます。各ビジネス オブジェクトは、ADO.NET 2.0 プロバイダー ファクトリ メカニズムを使用して具体的なプロバイダーから比較的抽象化された状態を維持するデータ アクセス層にデータ アクセス作業を委任します。この点で、Microsoft Enterprise Library の Data Access Application Block を使用するすべてのアプリと多くの共通点があります。

NUnit で記述されたかなり徹底的な統合テストがあり、テスト データベースをゼロからセットアップするため、実行に時間がかかりますが、少なくとも、それらが正常に機能することを確認します (とにかく過去のある時点で ;-)。真の単体テストは (まだ) ほとんど行われていません。

私の職場では、コア製品であるいくつかの「モジュール」を備えたWebアプリケーションの主要なリファクタリングを計画しています。それが私たちの主な関心事の1つであるため、モジュールは実際にはモジュールではないため、すべてがモノリシックであると引用しました。このアプリケーションはPHPで作成されており、MySQLデータベースにアクセスするためにPearを賢くテンプレート化して使用しています。データベースの独立性についてはあまり関心がありませんが、実装に数か月もかからないのであればいいのですが。

私たちの主な懸念は、無関係な場所でバグが発生し、最も一般的な機能を取得するために依存する健全な共通アーキテクチャがないため、開発時間/コストが指数関数的に増加していることです（各モジュールは基本的に前のモジュールからコピー/貼り付けされます）適応する）。

主にASP.NETMVCで、WebMVCの原則についてある程度の経験があります。私はそれが提供するきれいな分離とテスト容易性が好きです。ただし、ローカルマシンでこれを試すと、アプリは本来よりもはるかに遅くなります。

さて、十分な紹介ですが、質問に移ります：-キャッシングモジュールに依存する必要がありますか？これにより、優れたアーキテクチャが提供するオーバーヘッドのほとんどが削除されますか？APCのようなもの。

• アプリケーションは主に読み取られます。書き込みは主に単一の値です（レコードの単一のフィールドを変更します）。これが得意なPHPのOR/Mはありますか？
• また、柔軟なMVCフレームワークを探しています。Zend、CakePHP、多分Symfonyを知っていますか？

トリッキーな部分は、完全な書き換えを実行できるという贅沢がないことです。現在非常に厄介なコードベースを段階的に改善する必要があります。これは、新しいコードを記述しているとき、またはバグを修正しているときに実行する必要があります。私が本当にやりたいことの1つは、新しいバグを修正する前に回帰テストを作成して、後で再び発生しないようにすることです（これはときどき発生します）。

私が現在検討しているスタックには、次のものが含まれています。

• 選択したMVCフレームワーク
• ロギング（log4php？）
• 選択したOR/M（動的である必要はなく、コード生成も問題ありません）
• 選択したIoCコンテナ
• Smarty Templating、おそらく抽象化されているので、必要に応じて切り替えることができます。
• 選択したオペコードキャッシュ（現在使用していますが、どれを忘れたか、sysadminに問い合わせる必要があります）

私が心配している主なポイントは、PHPでクリーンなコードを作成することのパフォーマンスへの影響です。.NET / Java Webスタックのようなものとは対照的に、解析された言語であるため、インラインコードの抽象化を作成すると（異なるファイルでの分離が義務付けられます）、別のレベルで新しい問題が発生する可能性があります。

注：より適切なタグを思いついた場合は、タグを付け直してください。現在のタグについてはわかりません。

設計パターンがソフトウェアを悪化させるのはいつですか?

GUI とロジックの間でファサード パターンを使用するプログラムを見たことがあります。彼らは、これを介してオブジェクトを転送することはできないと考えていたため、コーディングが困難なプリミティブ型のみが使用されました。

優れたオブジェクト指向設計を実際に体験したいので、関心の分離をレガシーアプリに適用することにしました。

私は、これらの呼び出しがコードベース全体に散らばっているのは気が進まないと判断しました。

これらの呼び出しを静的メソッドにカプセル化するヘルパークラスを作成することでこれに取り組んだことがありますが、もう少し先に進む機会になると思いました。

最終的には、依存性注入の使用を目指し、常に「インターフェースへのコーディング」を行う必要があることを認識しています。しかし、私はあまりにも大きな一歩を踏み出したくありません。それまでの間、私はその究極の目標に向けて小さな一歩を踏み出したいと思います。

誰かが彼らが推奨するステップを列挙できますか？

頭に浮かぶものは次のとおりです。

• クライアントコードを具体的な実装ではなくインターフェイスに依存させる

• コンストラクターまたはプロパティを介してインターフェースに依存性を手動で注入しますか？

• IoCコンテナを選択して適用する前に、コードを実行し続けるにはどうすればよいですか？

• 依存関係を満たすために、構成値を必要とするクラスのデフォルトコンストラクターは、（静的CreateObject（）メソッドを使用して）Factoryを使用できますか？

確かに私はまだファクトリーに具体的な依存関係を持っていますか？...

Michael Feathersの本に浸ったので、継ぎ目を導入する必要があることはわかっていますが、十分な数または多すぎる数を導入した時期を知るのに苦労しています。

アップデート

クライアントがWidgetLoaderのメソッドを呼び出して、必要な依存関係（IConfigReaderなど）を渡すと想像してください。

WidgetLoaderは、構成を読み取ってロードするウィジェットを見つけ、WidgetFactoryにそれぞれを順番に作成するように要求します。

WidgetFactoryはconfigを読み取り、ウィジェットをデフォルトでどの状態にするかを認識します

WidgetFactoryはWidgetRepositoryに委任してデータアクセスを行います。WidgetRepositoryはconfigを読み取り、ログに記録する診断を決定します。

上記のいずれの場合も、IConfigReaderは、コールチェーンの各メンバー間でホットポテトのように渡される必要がありますか？

工場は答えですか？

以下のコメントを明確にするために：

私の主な目的は、いくつかのアプリ設定を構成ファイルから他の形式の永続性に徐々に移行することです。注入された依存関係を使用すると、抽出してオーバーライドして単体テストの良さを得ることができますが、私の主な関心事は、設定が実際に永続化される場所を認識し始めるのに十分なカプセル化を行うことではありません。

詳細を説明するケースの例を次に示します。

ビューで ItemsControl を使用して単純な棒グラフを動的に作成し、BarGraphViewModel で項目を BarViewModels (それぞれパーセンテージ値を含む) のコレクションにバインドしています。各バーは異なる色にする必要があります。色はコレクションから選択する必要があります。{Color1, Color2, ..}

コレクション自体は一定ですが、バーの数は状況によって異なります。

簡単な解決策は、次のような単純な BarViewModel を作成することです。

（簡潔にするために、変更されたプロパティと検証の実装を省略しました）

これで、BarGraphViewModel からパーセンテージごとに BarViewModels を作成し、Color コレクションから作成した適切な ColorBrush を渡すことができました。

次に、Xaml で、これらのプロパティにバインドする単純な ItemsTemplate を作成します。

今だけ、SolidColorBrush 型のプロパティが含まれているため、ViewModel はプレゼンテーション フレームワークに依存しており、別の環境で使用する必要がある場合は変更する必要があります。

したがって、これはMVVMのベストプラクティスを破っていますか、それとも許容できますか（どこかで線を引くか、物事が複雑になりすぎます）

他の人がこれについてどう思うか、また複雑になりすぎずにViewModelがプレゼンテーションレイヤーを完全に認識しないようにする他のソリューションがあるかどうかを知りたかっただけです。ValueConverters が役立つと想像できますか?

したがって、この質問は、ここからの一種のフォローアップです（複数のイベント引数を処理する方法）。その質問は私にこれについて考えるように導きましたが、それ自身のスレッドを正当化するのに十分異なっています。

私は（楽しみと学習の目的で）ゲームを作成していますが、デザインに優れた基準を使用しているかどうかを知りたいです。関心の分離でOTTに移行したか、全体が間違っていたのではないかと思いますが、そうではないことを願っています。「ベストプラクティス」とその実用化を学びたいので、書き直しても問題ありません。

編集

ゲームについてもう少し説明しましょう。これは、多くの携帯電話で見られるゲームであるJawbreakerに基づいています（クイックデモはここにあります）。目的は、グループに含まれるボールを選択して、それらをプレーから除外し、できるだけ多くのポイントを獲得することです。

私はそれを少し拡張しようとしていて、ボードの種類、ボールの動き、ボールの種類が異なります。ボールは指示された場所に移動するか、途中で何かをする可能性があります。

これが私が作成したオブジェクトの構造です。上の行はDLLとそのオブジェクトを示し、2番目の行はそれらのオブジェクトが参照するものを示しています。

_{（出典：ggpht.com）}

これがUMLを実行するための私の試みです。

代替テキストhttp://yuml.me/3279d2ac

UMLの全ページにリンクするには、ここをクリックしてください。少し大きくなり、読みやすくなります。

オブジェクトDLLは、ゲームで使用される基本的なオブジェクト、ボール、およびボードを保持します。それらには、状況にどのように作用/反応するかについてのロジックは含まれていません（ボールはCompareToメソッドとEqualsメソッドを実装しています）。IBallの実装はX個ある可能性があります（IBoardについても同じですが、私が想像するほど多くはありません）。

InstanceManager DLLは、オブジェクトを作成する方法として使用されます。これが100％必要であったかどうかは、ObjectsDLLに含まれている可能性があります。ファクトリは、IBallオブジェクトを作成するためのさまざまなオーバーロードされたメソッドを持つ静的クラスです。BallFactoryは、BallType列挙型、Drawing.Colorオブジェクトなどを受け取ることができます。BoardFactoryは非常によく似ています。Jawbreakerは、非常に定期的に使用されるランダムオブジェクトや一部のGameConfigurationデータ（このトピックにはあまり関係ありません）の保持などを処理するシングルトンオブジェクトです。

エンジンDLLは、ほとんどの作業が行われる場所です。LogicFactoriesは、BallTypeオブジェクトとBoardTypeオブジェクトを使用して、関連する論理オブジェクトを作成します。ロジックオブジェクトは、IBallおよびIBoardオブジェクトの動作を制御するために使用されます。BallLogicは、イベントが発生したときに何ができるかをボールに伝えます。たとえば、ボールが選択されると、ボードYのボールXが選択されたことを示すメソッドがボールロジックで呼び出されます。その後、ボールは、そのタイプのボールが実行すべき/実行できることは何でも実行できます。BoardLogicは非常によく似ており、ボードの動作を処理します。

エンジンオブジェクトは別のシングルトンであり、GUIがゲーム全体とどのように相互作用するかを示します。GUIは、他のオブジェクトを直接インスタンス化しません。

したがって、IBallクラスとIBoardクラスはそれらに関するデータのみを保持するため、Logicクラスはすべての機能を処理します。

私が知りたいのは：

1）これは賢明なアプローチですか？

2）（一般的に）ロジックはオブジェクト/データから分離する必要がありますか？

3）関心の分離に行き過ぎていませんか？

4）設計/構造に関するその他のコメント

編集

私がいくつかのシングルトンを使用した理由の一部は、オブジェクトを常に保持せずに1つの場所でデータにアクセスすることを簡単にするためです。また、単一のゲームであり、ハイエンドまたは複数のマシンにまたがってスケーリングされないためです。 。それらは素晴らしいものではなく、私が定期的に使用するものでもないことは理解していますが、コメントに感謝します。

ご意見・ご感想をお寄せいただきありがとうございます。

複数の .NET スターター キットを見て気付いたのは、ビジネス オブジェクトの構築はクライアント レベルで処理されることが多いということです。次に、ビジネス オブジェクトは、操作やデータベースへのシリアル化などのためにビジネス レイヤーに渡されます。クライアントが必要なデータのみを渡す必要があるように、このコードをビジネス レイヤーに抽象化する必要はありませんか? オブジェクトを引数としてのみ受け入れる CRUD 抽象化を備えたビジネス層を持つことには利点がありますか?

いくつかのサンプルプロジェクトでは、ViewModelsを使用してデータオブジェクトを文字列に変換し、Viewで使用するのを見てきました。

ViewModelには通常、1つのパラメーター（データオブジェクト）を受け取るコンストラクターがあります。次に、コンストラクターはViewModelのさまざまなプロパティ（主に文字列とint）にデータを入力します。

これにより、ビューで複雑なロジックが発生するのを防ぎます。

一見すると、これは複雑なロジックからのビューの分離をより完全に強制するため、私には良い考えのように思えます。

たとえば、私のビューがデータオブジェクトのプロパティ「サイズ」をレンダリングしようとしていたとします。サイズは「小/中/大」を表す1〜3の数値です。

ビューにif/switchステートメントを含める代わりに、ViewModelに「SizeString」などを含めるだけで、if/switchステートメントをViewModelコンストラクターに入れることができます。

誰かがこのアプローチに同意しませんか？

ヘルパーなど、他のアプローチを使用する方がよいでしょうか？もしそうなら、なぜですか？

ASP.NET MVC Web サイトのすべてのページに "最新のニュース項目" サイドバーを配置する例を考えてみましょう。NewsItems に注意を向けるページに適した NewsItemController があります。ホーム ページの HomeController にニュース サイドバーを表示するのはどうでしょうか。または、そのことに関する他のコントローラーはありますか？

私の最初の本能は、上位 5 つの NewsItem を選択するためのロジックをユーザー コントロールに配置し、それをマスター ページで呼び出すことです。そうすれば、NewsItem ロジックで他のコントローラーを汚染することなく、すべてのページにニュース サイドバーが表示されます。これは、通常コントローラーに入るプレゼンテーションレイヤーであると私が理解したものにロジックを入れることを意味します。

私はそれにアプローチするための約半ダースの異なる方法を考えることができますが、関心事やその他の関連する流行語の分離に関しては、どれも「正しい」とは思えません。