問題タブ [architectural-patterns]

Entity Framework を使用したデータ アクセス レイヤー (DAL) があり、Automapper を使用して上位レイヤーと通信したいと考えています。すべてのメソッドの最初の操作として、データ転送オブジェクト (DTO) をエンティティにマップし、入力を処理してから、エンティティから DTO へのマップに進む必要があります。このコードの記述をスキップするにはどうしますか?

例として、これを参照してください。

• 私の Web アプリケーションでは、スーパー ユーザーが他のユーザーになりすますことを許可したいと考えています。

私の質問：

これを実現するために使用できる一般的に受け入れられている設計パターンはありますか?

1. 一般的に言えば、セッション内で現在のユーザーと偽装されたユーザーを追跡する必要があると想像できます。

2. しかし、この変更に伴う複雑さを最小限に抑えたいと考えていることは理解できます。

3. ちなみに、私のアプリケーションは ASP.NET MVC 2 アプリケーションなので、既存のインフラストラクチャを活用できれば最高です。

編集:フォーム認証を使用しています。

編集:スーパーユーザーが別のユーザーに代わって行動しているという事実も追跡する必要があります。これを行う必要がある理由は 2 つあります。

1. ロギングは、スーパー ユーザーが別のユーザーに代わって行動したという事実をログに記録する必要があります。
2. スーパー ユーザーが偽装画面に戻って「コンテキストを切り替え」、別のユーザーになりすますことも考えられます。

編集: @Jordão は、ほとんど実行可能な解決策を提案しました。私の唯一の懸念は次のとおりです-スーパーユーザー（別のユーザーになりすましている間）がホーム画面に移動し、画面の上部に「Hello [User]」と表示されている場合、「Hello [Impersonated User]」として「こんにちは[スーパーユーザー]」とは反対です。そして、@ Jordãoのソリューションにより、この画面や同様の要件を持つ他の画面の実装がより複雑になるのではないかと心配しています。

たとえば、次のアセンブリに分離された単純な ASP.NET MVC ソリューションなど、疎結合レイヤーを実装し、IoC コンテナーなどを実装することで、SoC の原則に準拠することになっているコード プロジェクトがあるとします。

• アプリケーションアセンブリ + 名前空間
• モデルアセンブリ + 名前空間 (DB データにアクセスするための具体的なリポジトリが含まれています)

また、モデルアセンブリの具体的なリポジトリが共通のインターフェイスを実装する必要IMyBusinessRepositoryがある場合、そのインターフェイスをどのアセンブリに配置しますか?

1) そのインターフェイスをモデルアセンブリに配置すると、アプリケーションアセンブリのコードを変更せずに、そのアセンブリを別のアセンブリに置き換えることは不可能になる可能性があります (少なくとも名前空間が異なる場合) 。また、別のアセンブリに存在する代替 IMyBusinessRepository実装は、元のアセンブリを参照する必要があります (うわあ!)

2) アプリケーション アセンブリに配置すると、アプリケーションアセンブリを参照せずに他のプロジェクトでモデルアセンブリを使用することはできなくなります(うわぁ!)

3) または、そのインターフェイス専用の共通アセンブリを個別に作成しますか?さらに言えば、共通インターフェイスまたはインターフェイスのセットごとに個別の共通アセンブリを作成しますか? （うーん？）

要約すると、Xアセンブリは、アプリケーションAで(参照を変更するだけで) 簡単に置き換え可能であり、アプリケーションB、C、Dで再利用できる必要があります。

ある種の Web サービスを使用して N 個の外部システムと対話する必要があるバックエンドがあるとします。

私がしていることは次のとおりです。別のプロジェクトを作成し、そこにプロキシ クラスを生成します (WCF サービス リファレンス ダイアログでサービスの WSDL を使用)。

プロジェクト名の接尾辞について:

私は最初にXxAdapterを使いました。しかし、その後、CircuitBreakers のような追加のロジックを含むクラスの作成を開始したため、(ServiceAgent からの) XxAgent に行き着きました。

そのようなプロジェクトの名前の「正しい」接尾辞は何ですか。

Factory と Command Pattern を実装することで、いくつかの設計上の問題を解決できます。それで、パフォーマンスによると、どちらがより良いですか？

同じモデル/オブジェクトを共有/同期したいクライアントとサーバーがあるとします。モデルはお互いを指しており、クライアントとサーバーの間で送信/シリアル化された後も同じオブジェクトを指し続ける必要があります。私の現在のソリューションは、おおよそ次のようになります。

しかし、私はこのソリューションにあまり満足していません。フィールドは整数などです。これもかなり一般的な問題です。ここで探しているのは、この問題の名前、パターン、一般的な解決策、またはライブラリ/フレームワークです。

私は長い間MVCを使用していて、「サービス」レイヤー（たとえば、Java Webプロジェクト）について聞いていましたが、多くの情報が見つからないため、それが実際のアーキテクチャパターンであるかどうか疑問に思っていました。それ。

MVCSの考え方は、コントローラーとモデルの間にサービスレイヤーを配置して、コントローラー内に存在する可能性のあるすべてのビジネスロジックをカプセル化することです。そうすれば、コントローラーは実行を転送および制御するためだけに存在します。また、コードを複製することなく、多くのコントローラー（WebサイトやWebサービスなど）でサービスを呼び出すことができます。

MVPでビューはどのように作成されますか？プレゼンターは常にそれらを作成しますか（サブビューの場合はビューに加えて）？それとも、別のサードパーティコンポーネントまたはアプリ、あるいはそれらを作成するものですか？

また、おそらくDojo Toolkit / ExtJS（つまりJavaScript）でこれを実行することを追加しましょう。

だから、私はこれらのコード行を持っています：

両方の行を正確にどこに配置する必要がありますか？プレゼンターはビューをインスタンス化しますか、またはその逆ですか？そして、何が最初のインスタンスをインスタンス化しますか？

ActiveRecord を使用すると、次のようなクラスを定義できます。

これは素晴らしくシンプルですが、ロジックが大きく混ざり合っているため、クラスが非常に肥大化していることがわかりました。

階層化/ドメイン設計を使用すると、次のような同じクラスを定義できます。

Active Record => レイヤード デザインからどのように移行されましたか?

• Name セッターでのエンティティ レベルの検証 => そのまま (DataAnnotation 経由で可能)
• ビジネス ロジック/ルールの検証 (一意の名前) => エンティティから新しい別の ContactValidator に移動
• 保存ロジック => 別のリポジトリ パターン クラスに移動 (UnitOfWork も使用)
• ロード ロジック => 別のリポジトリに移動
• リポジトリとの対話は、新しい ContactService を介して行われます (これにより、ContactValidator、ContactRepository、UnitOfWork などの使用が強制されます。発信者が ContactRepository を解放するのとは対照的です!)。

この階層化されたデザインのピア承認/提案を探しています - 通常、アクティブ レコード タイプ以外のデザインはしません! コメントをいただければ幸いです。

注意 - この例は意図的に単純化されています (UnitOfWork は実際には使用されず、Repository/Validator の新規作成は別の方法で処理されます)。

ここには独特の問題/状況があります。できるだけシンプルにしようとしています。私は、基本クラス (Parent など) と、基本クラス (Parent) から直接派生する一連の派生クラス (Child1、Child2 ..ChildN など) を持っています。基本クラスを変更し、「AVeryPrivilegedMethod」を追加します。これは、Child2 と Child3 にのみアクセスでき、他の子にはアクセスできません (または、将来、Child5 も将来的に最小限の変更で使用できるように構成可能にします)。この法案に適合するデザイン パターン/アーキテクチャ パターンはどれですか?

使用言語 - C#。

PS: InternalVisibleToを使用することを考えていましたが、これがアセンブリ レベルで適用されることに気付きました