問題タブ [loose-coupling]

エンティティへの参照InvoiceInputModelであるProjectIdプロパティを持つを持っています。Project理想的には、AutoMapperがからInvoiceエンティティ全体をマップできるようにする必要がInvoiceInputModelあります。これは次のようになります。

明らかに、以下は悪いです：

緩い結合を維持しながら、プロパティに基づいてエンティティinvoice.Projectにマップする必要があるAutoMapperにどのように指示しますか？ProjectProjectIdInvoiceInputModel

私の請求書/編集InvoiceController：

「Resolvers」とResolveUsingについて何か見つけましたが、使った経験がありません。

エンティティモデル、入力モデル、およびビューモデル間の緩い結合を維持しながら、これを行うようにAutoMapperに指示するにはどうすればよいですか？それとももっと良い方法はありますか？

C# でコーディングされた ASP.NET MVC アプリケーションがあります。アプリケーションは次のように構成されています。

1. コントローラ

2. リポジトリ

3. エンティティへの LINQ (エンティティ フレームワーク)

4. 意見

Repository( _ProductRep) を使用して LINQ to Entities にクエリを実行し、Controller に実際のエンティティ or を渡しList<T>ますIQueriables<T>。

疑問を抱く以上の状況について、助けていただきたいと思います。次のコードがあります。

これlproduct_monthlyReportを取得したら、foreach 内でクエリを実行し、特定のレコードを取得する必要があります。現在、次のようなソリューションを実装しました。

litemList製品が持つことができるすべてのアイテムのリストはどこにありますか.

このソリューションがカップリングを賢明に増加させる (そしてDemeter の法則にList<T>違反する) のか、それとも ではなくa を実際にクエリしているので許容できるのかを知りたかったのIQueriable<T>です。間違っている場合は訂正してください。ただし、List は EF DataContext にアクセスする必要がないため、Controller と EF の間に結合はないと思います。

私が間違っている場合、考えられる唯一の解決策は、クエリを Repository メソッドに置き換えることです (まだ実装する必要があります)。

ただし、このソリューションでは、リポジトリはループ サイクルごとに 4 つの条件で 1 つのクエリを作成しますが、以前のソリューションでは、リポジトリは 1 つの条件だけでクエリを作成していました。

この問題について教えてください。ありがとう。

PS: 両方の変数が必要でlproduct_monthlyReport、lproductItem_monthlyReportループ内では 1 つだけを使用することはできません

PPS: コントローラーとリポジトリの間にビジネス サービス レイヤーを配置する必要があることはわかっています。これが次のステップです。

たとえば、他の iPhone からの Bluetooth メッセージの受信を処理するモデル クラスがあります。これらのメッセージのいずれかを受け取ったら、ビューを更新する必要があります。これを行う標準的な方法は、View Controller を使用することだと思います。ビュー コントローラーはモデルとビューへの参照を持っているため、それぞれと通信できます。

しかし、どのようにメッセージを VC に送り返す必要があるでしょうか? それらはそれぞれView Controllerへの参照を持つことができます（プロパティとして、保持ではなく割り当てを使用）。それは悪い習慣ですか（私が間違っていなければ循環参照です）？
これを行う別の方法はありますか？私はデリゲート パターンを検討しましたが、デリゲート全体とすべてを記述することは、単純な問題に対して非常に多くの作業のように思えます。または、私が考えすぎていると思われる場合は、お気軽にお知らせください。

[この質問はおそらく以前にもあったと思います。かなり一般的なようですが、少し検索してもあまり見つかりませんでした]

ご協力いただきありがとうございます、

ASP.NET MVC で REST API を作成しています。リクエストとレスポンスのフォーマットは JSON または XML にしたいのですが、別のデータ フォーマットを簡単に追加できるようにしたり、最初に XML だけを作成して後で JSON を追加したりできるようにしたいと考えています。

基本的に、API GET/POST/PUT/DELETE リクエストのすべての内部動作を指定したいのですが、データがどのような形式で入ってきたのか、何を残すのかを考える必要はありません。後で形式を簡単に指定したり、変更したりできます。クライアントごと。したがって、1 人が JSON を使用し、1 人が XML を使用し、1 人が XHTML を使用できます。その後、大量のコードを書き直すことなく、別の形式を追加することもできました。

すべてのアクションの最後に一連の if/then ステートメントを追加し、それによってデータ形式を決定する必要はありません。インターフェイスや継承などを使用してこれを行う方法があると思います。最善のアプローチがわからないだけです。

この一連のコードを受け取ったので、コードの結合とクラスの結合を改善する方法を提案する必要があります。しかし、これらのクラスはイベントを利用しているように見えるので、非常にうまく分離されていると思いました。結束に関しては、すべての init() 呼び出しが一緒に配置され、すべてがまったく問題ないように思えます。

クラスの結束と結合を改善する方法はまだありますか? 私には問題ないように見えますが、何かが欠けていると思います。

これに関する提案をありがとう。

緩い結合とインターフェースについて、概念的/理論的な質問があります。

したがって、インターフェースを使用する1つの方法は、特定のコンストラクターに必要なパラメーターをカプセル化することです。

渡されたオブジェクトがコントラクトを実装している限り、すべてが機能します。私の理解では、ここでの主な利点はポリモーフィズムを可能にすることですが、これが本当に緩い結合と関係があるかどうかはわかりません。

議論のために、IFooInterfaceは次のようになっているとしましょう。

緩い結合の観点からは、上記のコンストラクターでIFooInterfaceを使用せず、代わりにFooを次のように設定する方がはるかに良いでしょう。

Fooの機能を別のプロジェクトに落としたいと言うからです。つまり、他のプロジェクトもIFooInterfaceを参照し、別の依存関係を追加する必要があります。しかし、この方法でFooを別のプロジェクトにドロップすることができ、それが機能するために必要なものを正確に表現します。明らかに、オーバーロードされたコンストラクターを使用することはできますが、議論のために、Fooのコンストラクターを変更したくない、および/または変更できないとしましょう。

（少なくとも私にとって）最も顕著な欠点は、多数のプリミティブパラメータを持つメソッドがあると、醜くて読みにくくなることです。そこで、すべてのプリミティブ型ではなく、インターフェイスを渡すことができる一種のラッピング関数を作成するというアイデアがありました。

ここでの考え方は、Fooの要件に準拠するインターフェイスのインスタンスを取得する関数を取り戻すことができるということですが、Fooは文字通りそのインターフェイスについて何も知りません。次のように使用できます。

インターフェイスがどのようにルーズカップリングを可能にするかについての議論を聞いたことがありますが、これについて疑問に思っていました。

一部の経験豊富なプログラマーがどう思うか疑問に思います。

ASP.NET MVC3 と SQL Server のデータベースを使用して、Web アプリケーション プロジェクトに取り組んでいます。REST サービスを介して同じデータベースのデータを使用するモバイル アプリケーションもあります。ここに私のアプリケーションのレイヤーのいくつかがあります:

• モデル- Entity Framework を使用した ADO.NET データ モデル

• データ アクセス レイヤー- データベースからデータを取得するためのクエリを含むリポジトリ

• Web アプリケーション- リポジトリを使用する MVC3 プロジェクト、構造マップと DI を使用した疎結合、HttpRequest の最後でデータベース コンテキストが破棄される

• コア- DAL とサービス層の間の別の層で、リポジトリを使用し、データをサービス層に公開します。ビジネスロジックレイヤーの一種。

• サービス層- REST サービスは、コア層については知っていますが、DAL については知りません。データを DTO にマップし、クライアントに公開します

このようなアプリケーション アーキテクチャで私が抱えている問題は、サービス層での疎結合です。サービス層はコア層への参照を持っています。コア層はデータ アクセス層への参照を持ち、そのリポジトリを使用します。ただし、リポジトリにはデフォルトのコンストラクターがありません。1 つのパラメーターとそのデータベース オブジェクト コンテキスト (使い捨てオブジェクト) が必要です。

私のウェブサイトでリポジトリを直接使用しても問題ありません。私は構造マップを使用しており、DI はそれを疎結合にします。各コンテキストは、HttpRequest の最後で破棄されます。

問題は、そのサービス層とコア層です。そこにも疎結合が欲しいのですが、それを達成する方法がわかりませんか? それらにデータコンテキストを挿入し、特定の瞬間に破棄されるようにする方法は? すべてをまとめる方法についていくつかの提案を聞きたいです。

アプリケーションブログを作成するとしましょう [これは関係ありません。そこにあるので、app.blog.posts を実行できます。つまり、実際には単なるフォルダーです]。次にブログで、ブログ内にアプリの投稿を作成し、posts でモデルの投稿を定義します。 . これを行った後、モデルの投稿 (または投稿のようなモデル - 投稿にカテゴリ フィールドを追加) を拡張するアプリケーション カテゴリをブログに作成し、独自のテーブルを作成します。これらのアプリケーションがまったく無関係 (例: django-tags) である場合、カテゴリは最終的にそれを認識せずにどのように投稿を拡張できますか? 私はdjangoの疎結合について少し混乱しているので、おそらく誰かが私にそれを説明してください.

Flashアプリ（FlashDevelopを備えたAS3のみ）を構築していますが、イベントシステムの周囲で物事を緩く結合するのに問題があります。私は中央イベントシステムと静的イベントディスパッチャーについて多くのことを読みましたが、それらは私にとっては完全に適合していません。

私が作っているのはビデオプレーヤーに似ています。アプリの他のすべての小さな部分の親であるPlayerクラスがあります。PlayerクラスはSpriteを拡張し、現在、複数のPlayerをインスタンス化してステージに配置できるように設計しています。EventDispatcherを拡張するControllerクラスもあり、このクラスを介してすべてのイベントをディスパッチします。中心的なイベントクラスです。

問題は、他のすべてのクラスがディスパッチしてリッスンできるように、このクラスへの参照を渡す必要があることです。 参照の受け渡しは機能しますが、緩い結合とは正反対です。すべてのクラスが見ることができる静的なEventDispatcherを作成できることは知っていますが、ステージ上に2つまたは3つのプレーヤーがいる場合、すべてのクラスがお互いのイベントを聞くことになります。

参照を渡したり静的にしたりせずに、 Playerインスタンスのすべての子クラスが中央ディスパッチャーを認識できるようにするタイプのサンドボックスを作成するにはどうすればよいですか？

特定のロジックがデータ アクセス層とビジネス ロジック層のどちらに属するかについて、同僚と議論しました。

シナリオは、BLL が動作するデータを必要とすることです。そのデータは主にデータベースに存在します。そのデータを (System.Runtime.Caching を使用して) キャッシュして、後続の要求ですぐに利用できるようにします。アーキテクチャは、DAL と BLL が同じボックスと異なるアセンブリ (同じソリューション内のプロジェクト) に存在するようなものです。そのため、ワイヤーを介して DAL をヒットするなどの懸念はありません。

私の主張は、キャッシュをヒットするかデータベースをヒットするかの決定は、DAL の問題であるということです。ビジネス ロジック層は、データがどこから来るかを気にする必要はなく、必要なデータを取得することだけを考えるべきです。

彼の主張は、データアクセスレイヤーは「純粋」で「愚か」であるべきであり、キャッシュとデータベースのどちらをヒットするかを決定するロジックは、ビジネスロジックレイヤーにある必要があるというものです。

私の意見では、彼が言っていることは、関心の分離を弱体化させ、目標が物事を疎結合に保つことである場合に、レイヤーをより緊密に結合させることです。データの移動先を決定する特定のプログラム/UI 関数である場合、BLL がこれを制御したい場所がわかりますが、ここではそうではありません。これは、データベースがプライマリ データ ストアである非常に単純なキャッシュ シナリオです。

考え？