問題タブ [multi-tier]

多くの定期的なアクティビティを実行する Windows サービスがあり、Windows フォーム アプリからこのサービスの設定を変更したいと考えています。ただし、サービスに最新のユーザー設定が含まれていることを確認する最善の方法についてはわかりません (実行する頻度、使用するフォルダー、ユーザーが指定できるその他のこと)。ユーザーはいつでも自由に設定を変更できるので、すぐにサービスに知らせてほしいと思います。私が検討しているオプションは次のとおりです。

1. フォームとサービス共有は、3 番目の共有プロジェクトから同じ「Settings」オブジェクトを使用し、フォームは WCF の「UpdateSettings(newSettings)」呼び出しを使用して、変更があったことをサービスに通知します (または、必要に応じて、への呼び出し個々の設定を更新しますが、これはさまざまな呼び出しで多くのように思えます)。私は現在、基本的なメッセージに WCF を使用していますが、設定オブジェクトは他にもたくさんあるため、巨大になる可能性があります。
2. フォームとサービスは、共通の構成ファイル (XML、または #1 と同じ設定オブジェクトですが、ディスクにシリアル化されています) を使用します。フォームは、オブジェクトが変更された後にオブジェクトの新しいコピーを書き込むだけで、サービスは頻繁にチェックし、新しいかどうかを選択して、設定のコピーを更新します。
3. #2 と同じですが、サービスに設定を取得するように指示する基本的な WCF 呼び出しがあります。基本的に、#2 の「ポーリング」バージョンではなく「オンデマンド」バージョンです。

私は主観的であることを最もよく知っていますが、これらの選択の明白な賛否両論の理由に興味があります. アプリケーションの実行間 (再起動など) に設定を保存する必要があるため、とにかく設定をディスクにシリアル化する必要があるため、すでに #2 または #3 に傾いています。設定を保存できるディスク上の場所が必要ですが、おそらく AppData フォルダーは問題なく機能しますが、この場所への書き込み権限を持つのは管理者だけであるため、設定を変更できるのは管理者だけです。 (サービス アカウントを含むすべてのユーザーが読み取ることができます)。

あなたの洞察に感謝します！

私はアーキテクチャにまったく慣れていないので、次の .NET プロジェクト用にアプリケーションを設計しています。私の提案するアーキテクチャ設計は次のとおりです。

これは、以下を含む従来の 3 層アプリケーションです。 DataLayer (LINQ + 部分クラス) BusinessLogicLayer (エンティティ + 検証ロジック) (オプション) Service Layer (WCF) UI (Web サイトおよび Windows アプリ)

データ レイヤー: データ レイヤーには、DataContext クラス (つまり LINQ) と部分クラスが含まれます。これらの部分クラスには、基本的な計算ロジック (Calc. VAT など) とその他のデータベース レベルの検証ロジックがあります。

ビジネス層: これには、データ層と同様のエントリがありますが、UI レベルの検証ロジックも含まれます。たとえば、ユーザーがデータベースに存在しないユーザー名を入力しようとした場合、ユーザーが存在しないことをユーザーに伝える必要があります。（これは私が苦労している場所です）。オブジェクトは、オブジェクトの作成時ではなく、プロパティが呼び出されるたびに遅延ロードされます。

UI: これは、ビジネス エンティティが呼び出される従来の UI レイヤーになります。

LINQ を使用している場合でも DataLayer からビジネス層を分離している理由は、WCF サービスなどの中間層エンティティを追加したい場合は、Data ではなく Business Layer と通信する必要があるためです。アプリケーションが大きくなると、デカップリングが役立つと思います（と思います）。

誰かが上記の行についてコメントできれば幸いです。私の本当の問題は、ビジネスクラスを書くことです（明らかに）。たとえば、オブジェクトをロードしようとしたときの遅延ロードで、データベースにデータがない場合、ユーザーが存在しないことをUIに表示したい(ユーザー名を検索している場合)。これに関してあなたの推奨事項は何ですか。これへの入力は非常に高く評価されます。

どうもありがとう、Preyash

多層および/または分散型アプリ、それらは同じ意味を持っていますか？

これらのアプリのレイヤーについて話すとき、それは物理レイヤー（データベース、ブラウザー、Webサーバーなど）ですか、それとも論理レイヤー（データアクセスレイヤー、ビジネスレイヤーなど）ですか？

第 19 章: MSDN の物理層と配置では、「分散配置」について説明しています (図 2 を参照)。すべて順調です。

私の経験では、私たちは常に Web ベースのシステムを「非分散展開」と呼ばれるものに従って展開してきました (図 1)。私の理解では、Microsoft の世界では、独立したものとしての「アプリケーション サーバー」は (Java の世界のように) 実際には存在しないということです。

私の質問は、UI とビジネス ロジック (BL) を異なるサーバー / 層に分散するとしたら、どのように通信するのでしょうか?

答えの 1 つは、「サービス レイヤー」を使用することです。実際にどうやってそれを行うのですか？コードの観点からはどのように見えるでしょうか?

データベースでタスクを実行することになっているC＃の多層アプリケーションがあります（初めて使用する場合は、データベースを作成してデータを入力する場合があります）。最初にアプリケーションを設計したとき、進行状況のレポートは言うまでもなく、進行状況バー コントロールの可能性についても考慮していませんでした。データベース操作の進行状況を UI レイヤーに報告できるようにアプリケーションの設計を変更するにはどうすればよいですか? 再利用可能で、レポート用に追加の入力を取得するためにすべての関数を変更する必要がないソリューションはありますか?

私は新しいウェブサイトのアーキテクチャを設計しています。多層アーキテクチャには間違いなく時期尚早の最適化のすべての症状（複雑さ、開発の長さなど）があるので、現時点では避けたいと思いますが、システムの作成後にそのようなアーキテクチャを導入する（そして導入する）と思います適切に）非常にコストがかかります。サイトが十分に大きくなった場合、そのようなアーキテクチャが不可欠であると私は信じています。

どう思いますか？

私たちのアプリケーションには、さまざまなレイヤーがあります。サービス層、DAO 層、およびアクション (Struts アプリケーション)。

データは、あるレイヤーから別のレイヤーに渡されます。

入力検証を理想的にどこに配置する必要がありますか?

ユーザーID、電話番号はUIから来ているとしましょう。これらは必須です。そのため、すでにクライアント側で検証を行っています。

さて、私の意見では、必要なのはそれだけです。他に検証すべき場所はありません。

しかし、私の同僚の 1 人は、クライアントが直接要求した場合はどうなるかを主張しています。したがって、アクションも追加する必要があります。

現在、Dao でも同様のメソッドが他のアクションで使用されており、検証が行われていません。

または、サービス層と言って、それは Web サービスとして公開されている可能性があるので、そこにも検証があります。

本質的に、彼は提案しています..私たちはどこでも検証を行う必要があります。これは私には意味がありません。レイヤー全体での複製。

これに対する理想的なアプローチは何ですか? 検証が単純なnullチェックまたは複雑な検証であるとします。

最近のコースワークで最高の成績を収めるために、c++ と多層プログラミングを使用して特定のアプリケーションを開発するよう求められました。

多層アーキテクチャの背後にある理論と、このアプリケーションのどの部分がどの層に属しているかを正確に理解していますが、「n 層」アプリケーションを実際に実装した経験はありません。

階層を完全に分離する必要がありますか? たとえば、1 つのプロセスがデータベースを実行し、1 つのプロセスが UI を実行し、3 番目のプロセスが 2 つの間の対話を管理するなどでしょうか?

それとも、GUIがデータベースなどに直接アクセスしないように、アプリケーションをコードのレイヤーに分離するのと同じくらい簡単ですか.

C++ での多層プログラミングに関するヒントがあれば、大歓迎です :)

メンバーが他のユーザーの下に参加するクライアントのメンバーシップサイトをプログラムしました。例えば

ジョンとジルが一番上にあり、ジョーとファンがジョンの下にあり、ジャネットとジョージがジョーの下にあります。階層化は、手数料を渡すために使用されます。私のクライアントは、特定のユーザーの下にいるユーザーの数を確認できるようにしたいと考えています（少なくとも、8層に制限されています） 。

今のところ、ユーザーテーブルに追加のフィールド `num_below`を追加しました。このフィールドは、誰かがユーザーに参加またはユーザーの下を離れるたびにインクリメントまたはデクリメントされます。

これに関する最初の問題は、データベースの正規化の適切な慣行に違反しているように感じることです。これは、すでにDBにあるデータを保存しているためです。

2つ目は、クライアントが来て「ジョージはフアンの下に参加するつもりだったので、彼を動かしてください」と言うと、毛むくじゃらになるということです。

要求されるたびに以下の数値を動的に計算することを検討しましたが、dbクエリは指数関数的に増加するように見えます。

すべての`num_below`フィールドを調べて修正できる関数を作成しましたrectifySubs()が、メンバーが増えるにつれて、実行するのがますます集中的になります〜

何かお勧めはありますか？DBに冗長なデータを入れすぎたくないのですが、毎回8層にするのは、プロセッサに負担がかかりすぎるようです。

- 編集 -

ティアがどのように機能するかについて十分に明確ではなかったので、テーブルを大きくしました。私が編集で取り組んでいる重要な問題は、誰でもそのすぐ下の層に複数の人がいる可能性があるということです。それが理にかなっていることを願っています。

-ソリューション-（「メンバー」クラスのメソッドとしてのカカオのソリューションの実装）

通常、アプリケーションがサーバー ファームにデプロイされる場合、アプリケーションには中央データベース、1 つ以上のアプリケーション サーバー、および 1 つ以上の Web サーバーがあります。

アプリケーション層のすべてのサービスは Web サーバー経由でアクセスされるため、アプリケーション サーバーと同じ物理層に Web サーバーをデプロイしない理由はありません。

具体的な質問は、Web サーバーを別の層としてデプロイする理由は何ですか?

より広い観点から、展開シナリオを決定する際の一般的な考慮事項は何ですか?