問題タブ [n-tier-architecture]

つまり、MVCアプリがあり、別のプロジェクトでは、アプリケーションのビジネスロジックとデータロジックを処理するクラスの通常のコレクションがあります。また、MVCプロジェクト自体のモデルにもいくつかのロジックがあります。このロジックは、ViewModelなどを処理します。これらは、MVCプロジェクト自体に関連しており、同じプロジェクトに存在する必要があるため、n層プロジェクトでは実行できませんでした。

私の質問は次のとおりです。

• モデルクラスには、n層のビジネスロジックに関する知識が必要ですか？または、コントローラーだけがこの知識を持ち、必要に応じてn層アプリケーションとMVCモデルの間でデータをやり取りする必要がありますか？
• モデルがn層アプリケーションを参照しても問題がない場合、コントローラーはモデルクラスを介してn層にアクセスする必要がありますか？

これが理にかなっていることを願って、私の主張を正しく伝えるのは難しいと感じました。

MVCのどのレイヤー（モデル、ビュー、コントローラー）でパーミッションロジックを処理する必要がありますか？

それを少し明確にしましょう。明らかに、UI（ビューとコントローラー）は、コンポーネントを表示/非表示にし、アクセス許可が拒否されたシナリオを処理するために、アクセス許可にアクセスできる必要があります。また、モデル層によってアクセス許可をデータベースに永続化する必要があることも明らかです。

しかし、このような「複雑な」許可ルールについてはどうでしょうか。
私が開発しているwiki/CMSシステムでは、各ユーザーはページごとの権限（表示、編集、名前変更など）のセットを持っています。既存のページの場合、これらの権限はデータベースから取得されます。新しいページの場合、ユーザーは（ページを作成/編集するときに）可能なすべての権限を持っていると見なされます。

もう1つの例は、ページのリストです
。現在のユーザーは、ページのリストで表示権限を持っているページのみを表示できる必要があります。

コントローラはこのロジックを処理する必要がありますか？または、コントローラーはGetPermissions（）メソッド（またはGetPageList）の呼び出しのみを担当し、それを設定するためのすべてのロジックはモデルで処理する必要がありますか？

多くのコントロールと検証を備えたネットページ。ユーザーがアプリケーションをデータベースに保存できるようにする必要があります。

Customerと呼ばれるマスターテーブルと、Customer_IDが外部キーである5つの異なる子テーブルがあります。

ユーザーが保存を押したら、顧客テーブルにレコードを挿入してから、作成したばかりのcustomer_IDを使用して関連する子テーブルにレコードを挿入する必要があります。

上記のシナリオの良い例を教えていただけますか。これは非常に役立ちます。

Customerとすべての子テーブルのモデルを作成しました。しかし、私は本当にわかりません;ここから先に進む方法がわかりません。

私はVB.netとASP.net2.0とoracle8gを使用しています。ASP.net3.5またはMVC1.0は使用できません。

助けてください

トンありがとう。

近々、いくつかの Web アプリケーションを設計します。それらはおそらくasp.net mvcで行われます。

Delphi で作成した既存の Web アプリでは、データ アクセス レイヤーが完全に別のアプリケーションに分離され、別のサーバーで実行されることもあります。これは、アーキテクチャ上の理由よりも、コードの再利用のために行われます。これはすべて新しいものになるため、次のアプリの要因にはなりません.

MVC アプリで個別のデータ アクセス アプリケーションを使用するのはやり過ぎですか? MVC を使用してビジネス クラスを分離し、ORM を使用してデータベースの永続化を行います。

編集：明確にするために。階層という用語は、単なる論理的な分離やレイヤー以上のものである、別個の物理アプリケーションを指すために使用します。

最近、かなりの数の Windows フォーム アプリケーション (データ入力アプリ、オフィス統合など) を設計してきました。常に論理層を念頭に置いて設計してきましたが、「中間層」のビジネス ロジック層は常に、デスクトップ PC (つまり、物理的なクライアント サーバー)。

より複雑なアプリケーションにアプローチするにつれて、代わりに物理的な中間層が欲しくなります。デスクトップ クライアントは要求をアプリケーション サーバーに戻して、ビジネス ロジック (定期的に変更される可能性があります) とインターフェイスを処理します。スケーラビリティや保守性など、Web アプリに本来備わっている要素を見逃しているように感じます。

他の WinForms 開発者が中間層の分離をどこまで行っているか知りたいです。

• 中間層サーバーで実行する処理 (ある場合) はどれくらいですか?
• WCF、リモーティング、Web サービスなど、どのような通信方法を使用していますか?
• パフォーマンスはどの程度の要因であり、サーバーへのラウンドトリップはどのくらいの頻度で行われますか?

ビジネス ロジックを別の層に移動する利点はありますか? それとも、コンポーネントを PC 上でローカルにホストする方がより実用的ですか?

あるいは、これらの要因が関係している場合、顧客を完全に WinForms から遠ざける必要がありますか? Silverlight や AJAX を使用した ASP.NET などの代替手段があるため、WinForms クライアントを選択する理由は縮小しているようです。

最近、私はn層アーキテクチャでチェーンの上位の通信を処理するための最良の方法について議論しています。

現在私が行っている方法は、エラーのレイヤー間で例外をスローして処理し、他の通信にイベント/デリゲートを使用することです（プログレスバーなどを更新するため）。これらは最良の方法ですか、それとも私が見落としていた、より良い実践と見なされる別の方法がありますか？

システムをゼロから設計および開発してきた私たちの多くは、プロジェクトのアーキテクチャについて厳しい決定を下さなければならない状況にあります。アーキテクチャ的に健全でスケーラブルなシステムを構築するための「次のステップ」を実行する上で、どこに線を引きましたか。

アーキテクチャの面でかなり崩壊した大規模なWebサイトを構築しました。フロントエンドコードを含むWebレイヤーがあり、次に、実行する実際の作業を処理するビジネスレイヤーとデータレイヤーがありました。論理分離のさまざまなレイヤーが同じ物理マシン上に共存していました。Webサービスのレイヤー/層を使用することで、物理的または単純に論理的な分離が存在する可能性があります。さまざまな理由で、そのように実装されていませんでした。決定が正しかったか間違っていたかは、単に意見の問題です。私の観点からすると、比較的単純なアプリケーションが過剰に設計されている他の状況にあります。

新しいプロジェクトのアーキテクチャを設計する際に考慮する要素には、どのようなものがありますか？頻繁に使用する一貫したプロジェクト設計がありますか、最初からn層ですか、それとも各プロジェクトが入ってくるたびに評価しますか？

これらの経験を繰り返し経験していると、同じ立場にいる他の人がこれらの考慮事項をどのように正当化し、行うのか疑問に思うことがよくあります。私たち全員がさまざまな意見を持っていると思いますが、意見の背後にある思考プロセスを理解することは啓発的であると信じています。

Web ソリューションには次の構造があります。

• ドメイン
• データアクセス
• アプリケーションサービス
• ウェブ
• テスト

私が使用しているいくつかの Web サービスを抽象化するために使用しているいくつかのアプリケーション サービスがあります。(具体的には、いくつかの出荷 Web サービスを 1 つのアプリケーション サービスにまとめています。) アプリケーション サービス レイヤーは、使用している Web サービスを参照し、他の層は無視したままにするか、または Web およびテストで Web サービスを参照する必要があります。アプリケーション サービスに Web サービスを挿入しますか?

n層構造をよりよく理解するために、現在持っている既存の動作中のアプリケーションを分割することに取り組んでいます。このアプリは、フォーム認証付きのカスタム メンバーシップとロール プロバイダーを使用します。

現在、すべてのデータ アクセスとビジネス ロジックはすべて同じ ASP.Net ソリューション内にあります。

ビジネス ロジック層 (BLL) とデータ アクセス層 (DAL) を構築し、ビジネス ロジックを抽出しています。MembershipProvider クラスが存在する場所について苦労しています。

• これらのクラスを利用するビルトイン UI コントロール (ログイン、ユーザー作成ウィザードなど) が密結合しているため、メンバーシップ プロバイダー クラスはプレゼンテーション レイヤーに常駐する必要がありますか?

• それらは BLL に存在できますか? もしそうなら、プレゼンテーションからそれらを参照するにはどうすればよいですか? BLL が UI から参照されたら、web.config を変更して BLL.membershipprovider を指すようにするだけですか?

間違った道に進む前に、サニティチェックを探しているだけです。残念ながら、Google経由でこれの例を見つけることができませんでした. ヘルプ/ポインタをいただければ幸いです。