問題タブ [multi-tier]

もともと、私の BO が情報を求めて呼び出し、UI に渡した DAL オブジェクトがありました。その後、UI のコードが減っていることに気付き始め、Controller クラスがありました。まともな推奨事項は何ですか。

私は現在私の構造を構築しています

次に、コントローラークラスがあります（最近このスタイルを実装しました）

次に、私のアプリケーションで

当初、共有クラスを使用すると、データを取得する必要があるたびに DAL の新しいインスタンスを作成し続ける必要がないことがわかりました

あなたの見解は？

ありがとう

セッション状態を多用して、現在のユーザーに関する情報、個人設定、セッション履歴の記録などを保存する Web アプリケーションがあります。

次のように、ビジネス層でこのセッション情報を取得していることに気付きました。

これは問題を引き起こします。将来のある時点で、私のアプリケーションには、明らかに Web セッション状態を参照できない Windows クライアントが含まれます。そのため、アプリケーションが Web で実行されているかデスクトップで実行されているかに依存しない、ビジネス レイヤーで参照できるホストまたはカスタマイズされたセッション クラスが必要です。何かのようなもの：

舞台裏では、Web 実装は明らかにセッション状態を利用して情報を保存しますが、これをビジネス層から隠す必要があります。誰かがこの問題を解決したり、これにアプローチする最善の方法について実用的なアドバイスを得たりしましたか?

助けていただければ幸いです。

最近、「N 層アーキテクチャの経験が必要」または「N 層アプリを開発できなければならない」というような文章を含む開発者の求人情報をかなりの数見ました。

このことから、N 層アーキテクチャとは何かという疑問が生じます。どうやって経験を積むのですか？

私はMVCと多層Webアーキテクチャの概念に不慣れです。PHPアプリケーションを開発していて、利用可能なMVCフレームワークの1つを使用しています。私の質問は次のとおりです。

私が理解していることから、MVC自体は多層アーキテクチャとは見なされません。MVCを単独で使用することは、構造化されていないアプローチを採用することからのステップアップであることが理解できますが、単純な3層アーキテクチャがどのように適合するかを考えていました。MVCはプレゼンテーション層に存在しますか？階層型アプローチを追加するメリットは何ですか？私が収集したものから、MVCだけでは、データベースからデータを取得する責任のある明示的なデータオブジェクトはなく、これは通常、モデルに詰め込まれています。同様に、3層アーキテクチャでは「ビジネスレイヤー」（またはそれを呼び出したいもの）に存在するビジネスロジックをコントローラーに詰め込むことができます。

私の理解はやや正しいですか？多くの質問をしたことは知っていますが、2つは相互に排他的ではないと想定しているため、MVCフレームワーク（PHPまたはその他）にn層アーキテクチャをどのように組み込んだかについて話し合いたいと思います。ありがとう！

3つのデータベース（2つのSQL Serverデータベースと1つのOracleデータベース）と通信する.NET WinformClick-Once-deployedファットクライアントがあります。

最初のSQLServerデータベースであるマスターを呼び出します。マスターデータベースにさらにテーブルと列を追加したかったのですが、それを行う権利は与えられない、交渉できないと言われました。そこで、新しいSQL Serverデータベースを追加することにしました。これを拡張データベースと呼び、マスターに配置したい追加情報を格納します。

拡張データベースをマスターと同じサーバーに配置する権限がなかったため、別のサーバーに拡張データベースを作成し、拡張データベースサーバーからマスターのデータベースサーバーへのデータベースリンクを作成しました。これにより、2つのデータベースにまたがるクエリを実行できました。また、時々接続する3番目のデータベースであるOracleデータベースもありました。

Oracleデータベースに接続するには、エンドユーザーのPCにインストールされていない可能性が高いOracleドライバーをインストールする必要があると考えたため、WinFormクライアントにWebサービスを呼び出させ、Webサービスが結果を返すことにしました。一貫性を保つため、またデータベースアクセス操作は1つの場所から実行する必要があると内臓から言われたため、ファットクライアントがSQL Serverデータベースと通信する必要がある場合、つまりWebサービスを経由する場合も同じアプローチを採用しました。

ファットクライアントでユーザーのPCの接続を開いて直接接続する代わりに、最初にWebサーバーを呼び出してから、Webサーバーにデータベースを呼び出させることで、パフォーマンスが大幅に低下するかどうか疑問に思っています。 SQLServerデータベース。私が参照しているアプリは、これら3つの本番データベースにアクセスする必要があるが、実際に本番環境で実行することは許可されていない非公式のユーティリティであるため、開発Webサーバーと本番データベースの間の通常の高速パイプが疑われます。ここでは適用しないでください。

最高のパフォーマンスを得るには、WinformアプリでSQL Serverデータベースへの直接接続を確立する必要がありますか？トレードオフは何ですか？

追加のドライバーがOracleデータベースに接続する必要があるというのは今日でも本当ですか、それともすべてが.NET Frameworkにあり、必要に応じてOracleデータベースにも直接接続できますか？

また、リンクサーバーの使用は、2つの別々のデータベース接続を作成してデータを一緒にプールするよりも遅いことがわかりました。私の最良の結果は、2つの非同期クエリを開始し、dbリンクを使用して1つのクエリによって返されたかのようにデータを結合したときに得られました。ただし、これはメンテナンスの問題につながり、データベース間でSQL do結合を変更する必要があるときに、このアプローチを後悔することになりました。

私は PHP には比較的慣れていませんが、SOA アーキテクチャーと多層アプリケーションを備えた複雑なエンタープライズ環境で経験を積んだ Java プログラマーです。そこでは、通常、中間層にビジネス ロジックを含むビジネス アプリケーションを実装します。

私は代替通貨システムをプログラミングしています。これは、個人やコミュニティによって簡単に展開およびカスタマイズできる必要があります。オープンソースになります。そのため、php/mysql が私にとって最良の選択と思われます。

ユーザーにはアカウントがあり、残高を取得します。また、システムは、提供されるサービスの合計と利用可能な資産の合計に応じて価格を計算します。

これは、購入時に一連の計算が行われることを意味します。残高と合計が更新されます。これらは導出された数値であり、通常はデータベースに入れられません。

それにもかかわらず、私はトリガーとストアド プロシージャを db に入れることに頼り、php コードでこれらの更新が行われないようにしました。

人々はどう思いますか？それは良いアプローチですか？私の経験から、これは最善の解決策ではないことがわかり、中間層を実装するよう促されました。しかし、私はそれを行う方法さえ知りません。一方、ストア プロシージャに関してこれまでに得たものは、私には最も適切に思えます。

私の質問が明確になったことを願っています。すべてのコメントに感謝します。「完璧な」解決策はないかもしれません。

一般的な答えを使用できる特定の質問があります...PHPで多層アプリケーションを構築する場合、すべてをビジネスロジック層で行う必要がありますか、それともどの層でも機能しますか...例、プレゼンテーション層に（データベースからの）ユーザー情報を表示するアプリケーションを構築しています。ビジネスレイヤーを使用してデータをプレゼンテーションレイヤーに渡すだけにするか、データベースからプレゼンテーションレイヤー内で直接情報を取得する必要があります。プレゼンテーション層はデータを表示するためにJUSTを使用する必要があり、アクセサ層はデータを取得するためにJUSTを使用し、すべての作業はビジネス層で実行する必要がありますか？

また、さまざまなレイヤーについて言えば、手続き的に行うか、OOPを使用するのが最善です（テンプレートを表示するためにインクルードを使用するか、テンプレートを含めるためにクラスを使用するか、データを手続き的に検証するか、クラスを使用するか、関数とクラスを使用して取得するなど）データベースからのデータなど）

ご覧のとおり、私は物事がどのように機能するか、そして物事を行うための最良の方法を理解しようとしています。そうは言っても、何かアドバイスや、このテーマに関する一般的なヒントがあれば...そのままにしておいてください。

ありがとう

多層アプリケーションでは、再接続コードをテストするためにさまざまな TCP/IP エラーをシミュレートする必要があります。この目的で使用できるツール (Windows ベース) を知っている人はいますか? ありがとう。

関心の分離のみに関して、ユーザー インターフェイス レイヤー、ビジネス ロジック レイヤー、およびデータ アクセス レイヤーを備えた多層アプリケーションに ASP.NET Web フォームの代わりに ASP.NET MVC を使用する利点はありますか?

すべてのデータ アクセスのリポジトリ パターンから始まるマルチレイヤー アプリケーションがあり、サービス レイヤーに IQueryable を返します。すべてのビジネス ロジックを含むサービス レイヤーは、IList をコントローラーに返します (注: UI レイヤーには ASP.NET MVC を使用しています)。データ アクセス レイヤーで IQueryable を返す利点は、リポジトリを非常にシンプルにし、データベース クエリを延期できることです。ただし、サービス レイヤーでデータベース クエリをトリガーしているため、単体テストの信頼性が向上し、クエリを再形成する柔軟性をコントローラーに与えていません。しかし、私は' 最近、コントローラーが UI 固有のデータに対していくつかのプロジェクションを実行する必要があったため、クエリの実行をコントローラーに延期する方がパフォーマンスが大幅に向上するという状況に遭遇しました。さらに、oData などの出現により、エンドポイント (Web UI や Web API など) が IQueryable と直接連携する必要があるかどうか疑問に思い始めていました。あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか? あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか? あなたの考えは何ですか？サービス層から UI 層に IQueryable を返し始める時が来ましたか? それとも IList に固執しますか?

このスレッドはこちら: To return IQueryable<T> or not return IQueryable<T> は、IList を UI レイヤーに返すことを保証しているように見えますが、新しいテクノロジーやテクニックのために状況が変化しているのではないかと考えていました。