問題タブ [multi-tier]

n 層アプリケーションを継承しましたが、ファイルをグループ化する方法について説明が必要です。

BAL はビジネス アクセス層、DAL はデータ アクセス層だと思います。

EALの推測はありますか？EALとは何か知っている人はいますか?

また、BAL のファイル名の内容が DAL と同じになるのはなぜですか?

What is the difference between the clean and the n-tier architectures?

私は n 層アプリケーションを持っていますが、コア Web サービスは Web API で構築されています。Web サービスのメソッドの多くは HTTPGET として設定され、DTO オブジェクトをパラメーターとして受け入れます。MVC 5 で構築された私のクライアント アプリは、HttpClient を使用してこの API を呼び出しています。

したがって、 client.PostAsJsonAsync() を使用することでオブジェクトを渡すことができるようですが、 client.GetAsync() を使用するとオブジェクトを渡すことができません。これにより、URL で DTO のプロパティを明示的に指定する必要があります。これは機能しますが、少し冗長に思えます。

誰かが GET 呼び出しでこれが不可能な理由を説明し、より良い方法を提案できますか?

stackoverflow に関する Q/A をいくつか読んだ後でも、Web アプリケーションでの DTO の正しい実装についてまだ混乱しています。私の現在の実装は、(Java EE ベースの) 多層アーキテクチャ (永続性、サービス、およびプレゼンテーション レイヤーを含む) ですが、すべてのレイヤーで使用される "共通" パッケージを使用し、(とりわけ) ドメイン オブジェクトを含みます。この場合、レイヤーは実際には独立しているとは見なされません。共通パッケージを段階的に削除する予定ですが、さまざまな課題/質問に遭遇します。

• パーシスタンス レイヤーがクラスmyproject.persistence.domain.UserEntity (JPA ベースのエンティティ) を使用して、データベースとの間でデータを格納およびロードするとします。ビューにデータを表示するには、別のクラスmyproject.service.domain.Userを提供します。どこで変換できますか? ユーザー向けのサービスは、2 つのクラス間の変換を担当しますか? これは本当に結合を改善するのに役立ちますか?
• Userクラスはどのように見えるべきですか? 不変にするためにゲッターのみを含める必要がありますか？ビューが既存のユーザーを編集するのは面倒ではありませんか (新しいUserを作成する、既存のUserオブジェクトのゲッターを使用するなど)。
• 同じ DTO クラス ( User ) を使用して、既存のユーザーを変更する/新しいユーザーを作成する要求をサービスに送信する必要がありますか、それとも他のクラスを実装する必要がありますか?
• myproject.service.domain 内のすべての DTO を使用することで、プレゼンテーション レイヤーはサービス レイヤーに大きく依存していませんか?
• 自分の例外を処理する方法は? 私の現在のアプローチでは、ほとんどの「重大な」例外は、プレゼンテーション レイヤーによって処理されるまで再スローされます (通常、例外はログに記録され、何か問題が発生したことがユーザーに通知されます)。一方では、共有パッケージを再び持っているという問題があります。一方、これが「ベストプラクティス」と見なせるかどうかはまだわかりません。何か案は？

回答ありがとうございます。

この質問は、あなたが思っているほど根本的なものではないかもしれません。初めまして、読んでいただきありがとうございます。私はコンピューターサイエンスの学生です。私は AWS、特に Route 53 について学び始めたばかりなので、目を痛めるようなことがあればご容赦ください :)

Amazon Route 53 が、複数のアベイラビリティ ゾーンとリージョンにまたがる EC2 インスタンス、S3 バケット、Elastic Load Balancer にユーザーをルーティングする機能を顧客に提供し、次のようなさまざまな形式の DNS 負荷分散があることは誰もが知っています。

• LBR/レイテンシー ベースのルーティング。レイテンシーが最も低いリージョンにルーティングします。
• WRR/Weighted Round Robin (さまざまなターゲットに重みを割り当てるため)

また、両方を組み合わせたユーザー指定の構成も可能です (LBR+WRR)。

Route 53 の柔軟性により、ユーザーはコストを節約できますが、手動構成は最終ユーザーにとってますます複雑になる可能性があります。最適な非確率的ポリシー (WRR 重みなど) を探すことは NP 完全です。

サーバーの IP アドレスに異なる重みを付ける必要があるのは、どのような場合ですか? 複数のアベイラビリティーゾーンとインスタンスにまたがる EC2 サーバーが存在する可能性があることを考えると、フロントエンドとバックエンドの両方を含むか、アプリケーション層またはデータベースのみを含むことができますか? インタラクティブな多層クラウド アプリケーションのパフォーマンスを向上させるために、Route 53 を他の AWS サービスと組み合わせてより適切に使用する方法を見つけるアイデアはありますか?

長い質問で申し訳ありません。Route 53 をより効果的に使用するための最良の方法/実験の開始点についての考えやアイデア、および多層クラウド アプリケーション用の他の AWS サービスとの組み合わせについての考えやアイデアを探しています。必ずしも 100% 正しい答えではありません。アイデアや提案は大歓迎です。よろしくお願いします！

アップデート：

おそらく質問を言い換える必要があります: Route 53、つまり DNS サービスに加重レコードを設定する目的は何ですか? 明らかに、DNS の WRR はトラフィックの一部を制御できますが、単にこの DNS 負荷分散 (または負荷分散) に依存すると、他の多くの DNS サーバーに大きな負荷をかけることになります。私が考えることができる 1 つのケースは、Google や Facebook などの Web サイトが大量のドメイン名クエリを取得する可能性があることです。WRR DNS 負荷分散は有用であり、サーバー間でセッションを共有することは悪いアイデア。

Route 53 で加重レコードを使用する他の方法/目的はありますか?

私の質問を考えてくれてありがとう！

私は、ASP.NET の仕事に応募した PHP プログラマーです。彼らは、多層アーキテクチャを実装する (私が選んだ) アプリケーションを作成するという課題を私に与えました。

私は多くのジレマを持っています。私が理解しているように、多層は普遍的な形を持たない概念であり、誰もが自分にとって何が最善かを決定する必要があります. しかし、彼らは、プレゼンテーション レイヤーがデータ アクセス レイヤーへの参照を持つべきではないとアドバイスしてくれました。これは理にかなっています。しかし...

Add new projectプレゼンテーション層である (コントローラーとビューを持つ)新しいプロジェクトを作成しました。現在、プレゼンテーション層には、class libraryNinject を使用してアプリケーション全体の依存関係を注入する というもありますNinjectIoC。NinjectIoC は、引数としてコントローラーに依存関係を直接挿入するために、プレゼンテーション層プロジェクトへの参照を持っている必要があります。また、他のすべてのレイヤー (DataAcessLayer、BusinessLayer など) を依存関係にバインドするために、それらへの参照も必要です。

主な問題は、プレゼンテーション レイヤー プロジェクトが NinjectIoC への参照も持つ必要があり、Global.asax 内に StandardKernel を作成する必要があることです。これにより、循環的な依存関係が作成され、許可されません。

唯一の解決策は、すべてのレイヤー (DataAccessLayer を含む) のプレゼンテーション レイヤー プロジェクトへの参照を追加することです。これは、私が理解しているように、悪いことです。しかし、それがすべてのレイヤーのすべてのインターフェイスをバインドし、Global.asax 内で実行する唯一の方法です。

私は間違って考えていますか？

編集：

NinjectIoCNinject がインストールされており、アプリケーション全体でそれらをバインドするためにすべてのレイヤーへの参照があります。Global.asax で呼び出すには、UI への参照が必要です。

UI はNinjectIoC、コントローラーのバインドのために Global.asax で呼び出すことができるように、への参照を持っている必要があります。

NinjectIoC への参照を持つ中間クラス ライブラリを作成しようとしました。そのライブラリは UI で参照されます。問題は、コントローラーをバインドするために NinjectIoC が UI の参照を持たなければならないため、循環依存関係も作成されることです。