問題タブ [three-tier]

3層アーキテクチャで実装され、ユーザー認証やユーザー権限などの複雑さがあるasp.net Webサイト(ソース付き)の例を探しています。

そのような例を知っている人はいますか？

古いレガシー プレゼンテーション ライブラリが何年にもわたって維持されており、性急な修正のプロセスと適切なアーキテクチャ上の監視の欠如によって、ますます多くのビジネス ロジックがコード化されているという架空の状況を考えてみてください。あるいは、アセンブリの境界によってプレゼンテーションから分離されていないビジネス クラスまたは名前空間を考えてみてください。したがって、参照を強制的に追加することなく System.Windows.Forms のようなものを参照できます (単純な using 句よりもはるかに冷静なアクションです)。 .

このような状況では、この UI コードで使用されるビジネス コードが最終的に再利用のために呼び出されることは想像に難くありません。これを可能にするために2つのレイヤーをリファクタリングする良い方法は何ですか?

私は設計パターンに大まかに精通しています - とにかく少なくとも原則として。しかし、私は実務経験が豊富ではないので、直感に自信がありません。私はこれに Strategy パターンを使用する道を歩み始めました。アイデアは、ビジネス ロジックが UI コンポーネントを呼び出してユーザーに質問し、データを収集する場所を特定し、それらを一連のインターフェイスにカプセル化することです。そのインターフェイスの各メソッドには、元のワークフローの UI 指向のコードが含まれ、UI クラスはそのインターフェイスを実装します。

問題のビジネス ロジックを再利用する新しいコードもこのインターフェイスを実装しますが、UI コンポーネントによって最初に回答された質問に対する新しいウィンドウ、または場合によってはプレハブまたはパラメーター化された回答のいずれかを置き換えます。このようにして、いくつかのメソッドに渡されたやや厄介なインターフェイス パラメーターを使用しても、biz ロジックを実際のライブラリとして扱うことができます。

これはまともなアプローチですか？これについてどうすればよいですか？私はあなたの集合的なインターネットの知恵に従います。

ありがとう！

新しい ASP.NET MVC Web アプリケーションの作業を開始するたびに、DataAnnotations検証を使用するかどうかがわかりません。それについての何かが間違っていると感じます。

たとえば、のアクションからUserService渡される があるとします。ユーザーが常に名前を指定できるようにするために、モデルのプロパティに属性を設定しました。名前がない限り、モデル バインダーが私に.CreateUserModelCreateAccountControllerName[Required]CreateUserModel

私の問題はUserService、システムの再利用可能なコンポーネントになるためには、上のレイヤーが有効なデータを提供しているという事実に依存できず、このデータも確実に検証する必要があることです。を完全に再利用する Web サービスを作成する必要があると考えると、この必要性がさらに強調されますUserService(モデル バインダーですべてのデータ アノテーションの検証を行う必要はありません)。

私の質問は次のとおりです。この状況のベストプラクティスは何ですか? データ注釈を使用して検証し、その検証をサービスで繰り返しますか? サービスでのみ検証し、例外をスローしますか? 両方のミックス？

私の質問が主観的すぎないことを願っています。私は主に、検証をデータ注釈に移動することが最終的に私を噛むことになるかどうかについてコンセンサスを確立しようとしています.

新しい Web アプリケーションの作業を開始するとき、ASP.NET MVC、BLL (すべてのビジネス ロジックを含む一連のサービスで構成される)、および DAL (一連のリポジトリで構成される)の同じ実証済みのアーキテクチャに到達する傾向があります。 EF /*Linq to SQL*などの作業単位パターンを容易にします)。

コントローラはサービスとのみ対話し、サービスはリポジトリと他のサービスとのみ対話します。サービス層では、モデルが定義され、これらはコントローラーへの/からの入出力として使用されます。

私の質問は次のとおりです。他の人は何をしていますか? ASP.NET MVC Web アプリケーションのコンテキストで人々が何か違うことをしているかどうか知りたいです。たとえば、CQRSやDomain Eventsなどの概念があります。上記の方法で問題を解決するためにこれらを使用している人はいますか?

この質問は主に、私が知らないことを発見しようとする源です。漠然としすぎていないことを願っていますが、自分の方法を評価するために他の人が何をしているのかを見ることが重要だと思います.

3 層アーキテクチャは、プレゼンテーション層、ビジネス ロジック、およびデータベース層で構成されることがわかっているため、ビジネス ルール (ストアド プロシージャ、トリガーなど) はデータベース層に格納されるため、データベース エンジンを置き換えたい場合は、 (ms sqlserver など) 新しい db エンジン (oracle など) では、これらのルールを新しい db エンジンに転送する必要があります。

私の質問は、これらのルールを新しいエンジン用に書き直すのではなく、自動的に転送する方法です。

私は、次の設計で 3 層アーキテクチャを実装するプロジェクトに取り組んできました。

1. プレゼンテーション レイヤー - MVC フレームワークで PHP を使用して、フロントエンドのプレゼンテーションとビジネス ロジックを処理します。この層は、データにアクセスするサービス層を呼び出します。
2. データ アクセス層 - C# .NET を使用し、サービス、ビジネス ロジック、およびデータ層に分かれています。プレゼンテーション層によって呼び出されます。データベースを呼び出し、応答をシリアル化してプレゼンテーション層に返します。
3. データ層 -データベース。上記の 2 つのレイヤーのすべてのデータを提供します。

プレゼンテーション層が侵害された場合でもデータにアクセスできないため、3 層のアプローチがセキュリティに役立つことを理解しています。これは事実ですが、特に最初の 2 つのレイヤーで同じオブジェクトに対して 2 つのモデルを作成する必要があるため、このアプローチは少し複雑すぎるようです。

私の質問: これは 3 層アーキテクチャの不適切な実装ですか? もしそうなら、どのように改善できますか？データベースにアクセスできる MVC 実装を単純に持つことの欠点は何ですか? Web アプリケーションにどのようなアプローチを使用していますか?

助けてくれてありがとう！

MVC と 3 層アーキテクチャの基本的な違いは何ですか?

データベース アプリケーションの観点から、2 層アーキテクチャと 3 層アーキテクチャの比較エッセイを書いています。いくつか確認したいことがあります。

2 層はクライアント - サーバー 2 層はクライアント上のアプリケーション - サーバー上のデータベースです。2 層は直接通信を実装します。直接通信によるセキュリティの悪さ？ただし、ユーザーが 50 人未満の小規模なイントラネット ベースの環境には適しています。

一般的に、2 層はユーザー インターフェイスに関して Java アプリケーション (つまり、swing) を使用し、3 層は Web ブラウザーを使用しますか?

3 層はよりスケーラブルです。3 層は、中間層を使用することでより安全になります。3層はクライアント - ウェブサーバー - データベースサーバー

皆さんが私が書いたことのほとんどに反論し、さらに調査する必要があるいくつかの領域を明らかにしてくれることを願っています.

ありがとう

シ

したがって、この質問に答えるだけでなく、提案や改善を投げ出すこともできます。私はこれまで大規模なWebアプリケーションをまとめたことがありません。これが私の思考プロセスです：

• 永続層：標準データベース（現在はMySQL）
• ビジネスロジック層：RESTのような構造（PHP、Javaサーブレットなど...）
• プレゼンテーション層：Webブラウザー、Androidデバイス（ブラウザーではなくアプリケーション）など

このアーキテクチャを選択した理由は、デバイスが独自のカスタムUIを考案し、GET、POST、およびサーバーと対話しないものを使用して、RESTのような機能を利用できるようにするためです。

問題1：

問題は、ユーザーの情報をどのように保護するかということです。SSL接続を介してユーザーを認証し、特別なHASHを返すことで、ユーザーはアカウントを操作できますが、誰かがネットワークでリッスンしている場合は、REST呼び出しをリッスンしてHASHを盗むだけです。1つの解決策は、すべてのRESTのような呼び出しがSSLを介して行われる必要があることですが、これは別の問題を引き起こします。

問題2：

RESTプロシージャがSSLである場合、ブラウザはすべてにSSLを使用する必要がありますが、私の理解では、不要な場合は遅くて面倒です。また、SOPを使用すると、セキュリティで保護されていないブラウザからRESTプロシージャへのSSLajax呼び出しを使用できなくなります。HTTPとHTTPSは、同じオリジン、異なるプロトコルであっても、異なるオリジンと見なされます。

このソリューションは実行可能ですか？これらの2つの問題をどのように解決しますか？または、おそらく（おそらく）Webアプリケーション用に調査する必要のあるより優れたアーキテクチャがあります。すべての提案を事前に感謝します。

Javaで3つのレイヤー（データ/ビジネスロジック|サービス/ UI）を使用するのが好きで、これをPHPのWebサイトに適用したいと思います。この点に関して、どのようなアドバイス、リンク、チュートリアルを提案できますか？

PS：ドメイン/エンティティオブジェクトをどのように記述して使用できるかを知ることに特に興味があります。