問題タブ [separation-of-concerns]

この種のアプリケーションの正しいアーキテクチャを理解するのに苦労しています。これは、MSVisioに似たダイアグラム作成アプリケーションです。ダイアグラムは、別のアプリケーションに渡されるデータを生成するために使用されます。

アプリケーションを設計するとき、私は常にレイヤリングを使用しようとしましたが、データがプレゼンテーションと非常に緊密に結合されている場合、これを行う方法を決定できません。たとえば、私のキャンバス内の特定のオブジェクトには（X、Y）データがあります。これはプレゼンテーション目的でのみ使用されますが、ドメインデータのように保存する必要があります。

どこが間違っているのですか？私はこれを間違った角度から見ていると確信していますが、正しいものを理解することはできません。

再度、感謝します！

アップデート：

また、この場合、 UIをドメインから分離するべきではないことも認識しています。もしそうなら、いつ分離を適用するか、いつ適用しないかについての合理的な理由を教えてください。

PHPMVCフレームワーク用にさまざまなディレクトリ構造を試してきました。これを行っている間、アプリケーションのさまざまな部分を互いに分離するいくつかの理由を考えました。

たとえば、これが私の現在の構造であるとしましょう。

私のやり方では、 / private / framework /ディレクトリを上書きするだけでフレームワークを更新できます。これは、 / private /config/内のユーザーのフレームワーク構成や/private/libraries/内のサードパーティライブラリには影響しません。

/index.phpファイルは、ほぼ純粋に/private/framework/bootstrap.phpファイルをロードするために使用されます。つまり、/ private / framework /ディレクトリを更新すると、メインのブートストラップファイルも更新されます（/を更新する必要がなくなります。 index.phpファイル。これはほとんどないため、そのままになります）。

また、アプリケーションはフレームワークに関連するすべてのものとは別のものであるため、ユーザーは他のディレクトリを気にすることなく、必要に応じてアプリケーションを切り替え/変更/更新できます。

更新を容易にするためにディレクトリを互いに分離することに関して、私はここで正しい方向に進んでいますか？

一部のフレームワークでは、フレームワークディレクトリ内に/ private /libraries/ディレクトリと/private/ application /ディレクトリの両方があることがわかりました...しかし、これは、フレームワークの新しいバージョンに更新するのが難しいように思えます必要に応じて。それとも私はそれを間違った方法で考えていますか？

興味があれば、ここで私の以前のdir構造を見ることができます。私の新しい質問は、私の質問と同じように少し異なります（うまくいけば...）ので、新しい質問を投稿する必要があると思いました。

それは私が望んでいたほど小さな質問ではありませんが、まあ！;）

よろしくお願いします=）

Rails アプリのロギングを作成しようとしていますが、Rails で使用される哲学についてジレンマがあります。私のアプリには次のLinkモデルがありhas_many Hitます：

リンクがヒットするたびに、hit!メソッドを呼び出してリンクにリクエストを記録します (コントローラーをスリムに保つために、モデルをファットにします)。

ここで私は混乱しています。オブジェクトに付属するデータ（リモートIP、リファラー、ユーザーエージェントなど）を記録したいrequestので、リクエストオブジェクトをモデルに渡す必要がありますが、これは「関心の分離」に準拠しておらず、ぼやけていると思いますMVC デザイン パターンの責任行 (もちろん、間違っている場合は訂正してください)。またHit、コントローラー自体にオブジェクトを作成する場合は、スキニー モデルとファット コントローラーを作成します。

後者の場合はテストがはるかに簡単になりますが (モデル仕様でリクエストをモックする必要はありません)、正しくないように思えます。

これに関するアドバイス - 大変感謝しています。

PSextract_data_from_request(req)メソッドは、必要に応じて適切な場所に配置されます。オブジェクトに必要な属性のハッシュを返しHitます。

私は mvc に不慣れで、このプログラミング方法全体は私にとってかなり慣れていないので、優しくしてください...

私は記事のリポジトリに持っています：

関心の分離を維持しながら、パラメーターのカテゴリと位置をインターフェイスから渡すにはどうすればよいですか?

私は考えました：

Article オブジェクトと共にパラメーターを渡しますが、これは、コントローラーでカテゴリと位置を渡す必要があることを意味します。私はここで正しい方向にいますか？

私はphpBB2をハッキングして、他の人がダウンロードして使用したデータベースにいくつかのmodを送信することで、 PHPを学びました。（phpBB2がphpBB3でサポートされるようになったのは今のところ長いとは思わないので、v2 modsデータベースはもうサポートされていません。）

phpBBで私のお気に入りの1つは、エディターがHTMLとPHPを完全に分離できるテンプレートシステムでした。PHPファイルには、PHP：ロジック、データベースクエリ、およびテンプレートのアクティブ化が含まれていました。TPLファイルには、テンプレート（HTML、テンプレート変数、および条件付きブロックまたは繰り返しブロックを可能にする特殊なHTMLコメント）が含まれていました。

ただし、誰かのPHPコードをオンラインで見ると、それは単一の関数などで動作する小さなスニペットであるか、PHPがHTMLを含む文字列でいっぱいです（さらに悪いことに、PHPが散在しているHTML）。phpBBは、私が調べた唯一のPHPであり、実際に言語とマークアップ言語を分離しています。これは、他のPHPコードベースがそのようなことを行うものはほとんどないことを示唆しています。

もう一度PHPを使い始めたいと思っていますが、今回はphpBBフォーラムではなく、チームで開催されます。私の経験によると、PHPとHTMLの分離は一般的ではありません（これが間違っている場合は訂正してください！）。しかし、私はその境界線にとても慣れているので、PHPとHTMLの混合を読むのは嫌いです。

PHPプログラミングの「現実の世界」では、どのような方法が推奨されますか。

• HTMLの文字列を含むPHPファイル
• PHPブロックで分割されたHTMLファイル
• PHPとHTMLは完全に分離しています（私は望みますか？）
• 他に何かありますか？

これはほとんどの人にとって明白に思えるかもしれませんが、依存性注入 (DI) がインターフェイスの使用に依存していることを確認しようとしているだけです。

より具体的には、特定のインターフェイスをコンストラクターのパラメーターとして持つクラス、またはプロパティとして定義された特定のインターフェイス (別名セッター) を持つクラスの場合、DI フレームワークは、ニーズを満たすために具体的なクラスのインスタンスを渡すことができます。そのクラスのそのインターフェイスの。(この説明が明確でない場合は申し訳ありません。用語/概念がまだ私にとって少し新しいため、これを適切に説明するのに苦労しています。)

私が尋ねる理由は、現在、ある種の依存関係を持つクラスを持っているからです。オブジェクトの依存関係ではなく、URL です。クラスは次のようになります [C#]:

SoapHttpClientProtocol クラスには、Public プロパティUrl(これは単純な古い「文字列」) があり、ここのコンストラクターはそれをハードコードされた値に初期化します。

DIフレームワークを使用して、構築時に別の値を注入することはできますか? 私はそうでthis.Urlはないと思っていInterfaceます。それはStringです。

[ちなみに、私が作業しているコードのコメントによると、上記のコードは「wsdl によって自動生成された」ものでした。したがって、このコードを特に変更したくはありませんが、自分で再生成することもありません。したがって、このコードを変更しても問題ないかもしれません。]

文字列をパラメーターとして取り、そのように初期化する代替コンストラクターを作成しているのを見ることができましたが、this.Url疎結合の懸念の分離を維持することに関して、それが正しいアプローチであるかどうかはわかりません。(SoC)

この状況に対するアドバイスはありますか？

CakePHP1.2で作成したCakePHPアプリのオーバーホールに取り組んでいます。1.3にアップグレードし、アプリケーションの管理ルーティングパラダイムからの移行を検討しています。フロントエンドと管理者の機能が重複しているため、一部のコントローラーが非常に大きくなっていることがわかりました。私の直感では、管理コントローラーのセットを作成し、管理ルーティングをすべてまとめて削除する方がはるかにクリーンですが、他のユーザーが行っていることや、もしあれば、見逃してしまう機能についての情報を入手したかったのです。ルーティングを削除します。

この点で、堅牢なCakePHPアプリ（または他のMVCフレームワーク）のベストプラクティスと見なされるものは何ですか？

適切な URL でページに到達したかどうかを確認する関数を作成しているとします。ページには「正規の」スタブがあります。たとえば、ページは stackoverflow.com/questions/123 でアクセスできますが、(SEO の理由から) stackoverflow.com/questions/123/how-do にリダイレクトすることをお勧めします。 -i-move-the-turtle-in-logo - 実際のリダイレクトは独自のメソッド (redirectPage($url) など) に安全に含まれていますが、それを呼び出す関数を適切にテストするにはどうすればよいでしょうか?

たとえば、次の関数を使用します。

checkStub() 関数の単体テストを行う場合、リダイレクトが邪魔になりませんか?

これは、特定の関数が大きくなりすぎて、単体テストの領域を離れて統合テストの世界に入るように見える、より大きな問題の一部です。私の頭の中では、ルーターとコントローラーがこの種の問題を抱えているとすぐに思います。それらをテストすると、それら自体の機能だけに限定されるのではなく、必然的にページの生成につながるからです。

単体テストで失敗するだけですか?

アプリケーション アーキテクチャに関するアドバイスの大部分は、(疎結合を促進し、依存関係を減らし、テスト容易性を高めるために) HTTPContext にアクセスできるのはプレゼンテーション レイヤーだけであるべきだと強くアドバイスしているようです。

では、人々はキャッシングとセッションをどのように扱うのでしょうか? アプリケーションのパフォーマンスを最大化するためにキャッシュが必要な項目を判断するには、非常に具体的な DataAccess とビジネス ロジックの知識が必要です。ただし、ASP.Net Web アプリケーションでは、これらへのアクセスは HTTPContext を介して提供されます。

1 つのオプションは、CacheFactory と SessionFactory、および ICache と ISession インターフェイスを作成することです。その後、何らかの方法で DI 原則を使用して、ISession と ICache を BLL の各メソッドに渡し、続いてそれを必要とする DA レイヤーに渡します。

これは本当に開発者が最終的に行うことですか? これに対処する別の簡単な方法はありますか？

アドバイスをありがとう。

私は中途採用の哲学的建築危機を経験しています。クライアントコード（UI、Webサービス、MVC、MVPなど）と見なされるものとサービスレイヤーの間に非常に明確な線があります。ただし、サービスレイヤーからの線は、1分ごとにぼやけてきています。そして、それはすべて、Linqを使用してコードをクエリする機能と遅延読み込みの概念から始まりました。

コントラクトと実装で構成されるビジネスレイヤーを作成しました。その場合、実装は他のコントラクトなどに依存する可能性があります。これは、DIを備えたIoCコンテナを介して処理されます。DataAccessを処理するサービスが1つあり、それが行うのはUnitOfWorkを返すことだけです。このUnitOfWorkは、拡張時にトランザクションを作成し、Commitメソッドでデータをコミットします。[この記事を見る（Testability and Entity Framework 4.0） ]：

リポジトリは汎用であり、2つの実装（EF4とInMemoryデータストア）に対して機能します。Tは、データベーススキーマまたはEF4マッピングから生成されるPOCOで構成されます。テスト容易性はリポジトリ設計に組み込まれています。インメモリ実装を活用して、期待どおりの結果を表明できます。

データソースは抽象化されていますが、IQueryableを使用すると、ビジネスロジック内の任意の場所にクエリを作成できます。これが例です。

これで、複雑なフィルターを使用して結合を実行すると、クエリがさらに複雑になる可能性があることがわかります。

したがって、私の質問は次のとおりです。

1. BLLとDALの間に明確な区別がないことは重要ですか？。
2. InMemory抽象化のように機能するリポジトリ層の背後にある場合、クエリ可能性はデータアクセスまたはビジネスロジックと見なされますか？

追加：考えれば考えるほど、2番目の質問だけが尋ねられるべきだったのかもしれません。