問題タブ [three-tier]

3 層アプリケーションを実装しようとしているときに、ファイルをコピーして貼り付け、以下のリンクの手順を 10 分で完了しました。

http://geekswithblogs.net/edison/archive/2009/04/05/a-simple-3-tier-layers-application-in-asp.net.aspx

ただし、「型または名前空間名 'Sclient' が見つかりませんでした」というエラーが表示され、クライアント、構成、およびジェネリックデータ クラスが App_Code フォルダーにあり、ClientList.ascx 行 6 でエラーが表示されます。

私のコードはリンクに示されているものとまったく同じですが、エラーの原因は何ですか?

以下はスクリーンショットです

3 層アーキテクチャと mvc の違いは何ですか?

それらは同じですか？

どちらにも、モデル、ビュー、コントローラーの 3 つのレイヤーがあります。

3層（階層ではなく、1台のマシンでプロジェクトを論理的に分離したいだけです）アーキテクチャを実装しようとしています。非常に多くの異なるアプローチを見つけたので、混乱しています。（もしあれば）最善の方法は何ですか？それはWinFormsアプリにあります。

今、私はプロジェクトに存在する必要がある3つのレイヤーについてのみ疑いを持っていません:

• UI (プレゼンテーション レイヤー)
• BLL (ビジネス ロジック層)
• DAL (データ アクセス層)

UIに、すべての WinForms を配置しました。オブジェクトにコントロールからのデータを入力し、それを BLL レイヤーに渡すためのロジックも必要です。

DALでは、次のように、ADO.NET を使用してデータ操作用のクラスとメソッドを配置したいと考えています。

問題は BLL にあり、レイヤー間でデータを渡すためにデータ転送オブジェクトを使用する必要がありますか、それともクラス全体を渡す必要がありますか?

DTOを使用する場合はOrder、UI、BLL、および DAL を参照 する追加の共通クラスを作成する必要があります。

ロジックを BLL に分割します。

このアプローチは、さまざまな名前で使用されますが、特に使用されます: hereまたはhere。
一方で、一部の「賢者」とその支持者 (ここのような) は、これを貧血ドメイン モデルと呼び、使用すべきではない悪い設計とアンチ パターンであると不満を漏らしています。

長所：

• DTO は設計上、データベース テーブルを簡単に表すことができます。
• 軽くて明確で、データベースに必要なフィールドのみが含まれています。
• DAL は BLL を参照する必要はありません。

短所：

• アンチパターン (怖いですね;P),
• OOP (メソッドから分離されたプロパティ) の違反、
• ロジックは異なるクラスにあるため、何かが変更されたときに維持するのがより困難になる場合があります。

したがって、反対のアプローチは、次のようにオブジェクト全体をレイヤー間で渡すことです。DTO はなく、BLL は次のようになります。

長所：

• これは、OOP ルールに従って、適切にカプセル化されたオブジェクトです (と思います ;))。
• ロジックとプロパティの両方が 1 か所にあるため、保守とデバッグが容易になります。

短所：

• オブジェクトを使用するには、DAL が BLL を参照する必要があります (これは、3 層レイヤーが行うべき方法ではありませんね)。
• クラスには、データベースで使用されていないフィールドが含まれている場合があり、データベースの一部のフィールド (Id など) は「実際の」オブジェクトを表していません。

だから、私が何を選んでも、いくつかのルールに違反するように見えます. では、どの方法を選択すればよいでしょうか。たぶん、私が見つけていない他のアプローチがありますか？

SpringSecurityが3層アーキテクチャでどのように機能するかを理解しようとしています。

システムが次のもので構成されていると仮定します：
WEB<-> APP<->DB

そして、ユーザーがDB層で定義されていること。

アプリケーションにどのように実装しますか？
私の理解から、私は次のことをすべきです：

1. 層に独自の認証プロバイダーを作成しますWEB。
2. 認証プロバイダーは、APP層のサービスを呼び出して、DBに対して実際に資格情報を検証します。
3. ユーザーが層のSpringSecurityモジュールを通過するWEBと、認証はなくなり、すべてのWEB->APP呼び出しは実際には認証されません。

最後の箇条書きは私には意味がないので、ドキュメントで何かを見逃したと思います。

私の質問-これは、3層のWebアプリにセキュリティを実装するためのSpringの方法ですか？それとももっと良い方法はありますか？

.resxファイルを使用して、一般的な文字列参照をビジネスレイヤークラスライブラリに格納することをお勧めしますか？私は通常、これらがプレゼンテーション層で使用されているのを見たことがあります。

私は c# の初心者で、3 層プログラミングを使用しています。データ グリッド ビューを介してレコードを更新または削除できません。以下は私のコードです。私を助けてください。

ダル

BLL

プレゼンテーション

ストアドプロシージャ自体でほとんどのコードを記述できるのに、なぜデータレイヤーが使用されるのですか？その長所と短所は何ですか？ Data layerはの重要なレイヤーで3 tier architectureあり、データベースに関連するすべてのタスクを処理します。私の質問は、ほとんどの場合、ストアドプロシージャ自体を使用してこれを実現できるかどうかということです。その場合、そのレイヤーを使用する主な利点は何ですか？

編集：

問題は、データ層とデータベースのストアドプロシージャの使用法について明確に理解することでした。私はその中で私を助けた以下の答えを持っています。

3 層にPL、 、BLおよびが含まれていることはわかっていDLます。
1 つに取り組んで、そのアプリケーションで私たちは

「値をパラメーターとして PL から BL に渡し、計算後に DB 操作を実行する DL に渡します。」

これは 3 層を実装する正しい方法ですか?

またはここCODEPROJECTで説明されているもの

編集 私が知っている「すべてに適合する」レイヤーモデルはありません。でもどっちがいいか知りたい

1. パラメータを渡す？

2. テーブルフィールドの設定値を取得しますか? (上記のcodeplex例のように)

私はDjangoを初めて使用し、すべてのプロジェクト構造を明確にして整理することに少し問題があります.. DjangoのMVCは、小さなプロジェクトを作成するときに非常に使いやすいです. ただし、views.py と models.py の間に新しいレイヤー (3 層アーキテクチャなどのアプリケーション ロジック) を取得しようとすると、問題が発生します。

私は次の構造を持っています：

• 私のサイト/
  • 管理.py
  • app1/
    • models.py
    • ビュー.py
    • 論理/
      • __init__.py
      • Class1.py
      • parser.py
  • ...

とviews.pyからのものにロードしたい。どうすればいいのですか？Class1.pyparser.py

次のいずれも機能しません。

from app1.logic import *

from app1.logic.Class1 import Class1

また、誰かが本当に巨大な django プロジェクトの例を挙げてくれると助かります。多くのクラスと .py ファイルがすべてのアプリ フォルダーにある必要があるか、すべてが models.py にあるように見えます。 Zend または Symfony で)。

そして、私は Python3 と Django 1.5b2 を使用しています。

ありがとう。

3 タイヤ アーキテクチャのアプリケーションがあります。そして、このコンテキストで例外を処理する方法がわかりません。いくつかの質問を集めました：

1. のような一般的な例外を作成し、PersistentExceptionすべての DAO クラス メソッドが 1 つのタイプの例外のみをスローする ようにする必要がありPersistentExceptionますか? つまり、すべての DAO メソッド (CRUD) 内では、次のようにします。

2. すべての EJB サービスに対して 1 つの例外クラスを作成しても問題ありません (EJB インターフェースごとに 1 つの例外)。

つまり、対応するとインターフェースを持つPersonManagementBean、のような EJB Bean があるとします。それらはクライアントに公開されます。つまり、実際にはセッション ファサードです (したがって、サービス層に配置されます)。では、すべての Bean ( 、、 )に対応する Exception クラスを作成することをお勧めします。OrganizationManagementBeanEmployeeManagementBean@local@remotePersonManagementExceptionOrganizationManagementExceptionEmployeeManagementException

それとも、ServiceException(DAO の場合のように) 例外を 1 つだけ呼び出す方がよいでしょうか?

3. サービス (忙しさ) レベル (一般的なケース) をスローする可能性のある例外の種類は? DAO ( PersistentException) 例外をクライアントに伝播できますか? すなわち

または、すべての例外 (一般的なケース) をサービス固有の例外として再スローする必要がありますか?

• 「一般的なケース」とは、場合によっては、一部のメソッドがいくつかの役立つ情報 (たとえばValidationException、どのオブジェクトが検証規則を通過しないかに関する情報) を含む追加の例外をスローできることを知っていることを意味します。