問題タブ [multi-tier]

会社の OpenVMS ディレクトリ構造にデプロイするGradle 用のプラグインを作成しましdeployDevた。アプリケーションとは別に構成をデプロイできるように、すべての環境の構成ファイルを別のプロジェクトに抽出しました。deployTestdeployProd

これらのカスタム タスクはアプリケーション プラグインのタスクに依存してdistZipおり、呼び出されたタスクに基づいて適切な構成ファイルを zip に入れる良い方法が見つかりませんでした (たとえば、開発構成が含まれていますdeployDev)。

構成フェーズ中に deploy* タスクで構成ファイルをコピーしようとしました。

すべてのタスクで構成フェーズが実行されているため、これは機能しません。そのため、 を実行してもdeployDev、テスト構成が開発リソースにコピーされています。

私も試しました：

ただし、この提案では、distZipタスクは常に最新です。これを行う正しい方法はありますか？

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、どのオブジェクトが検証規則を通過しないかに関する情報) を含む追加の例外をスローできることを知っていることを意味します。

C# でインターフェイスを適切に管理する方法がわかりません。私の目標は、さまざまな DAL リポジトリ メソッドを呼び出すいくつかの一般的なメソッド (Save()、Dispose() など) を持つビジネス レイヤー サービスの抽象クラスを作成することです。すべてのサービスで次のようなことを繰り返さないようにしたい:

私はそれに似たシナリオを持っています:

インターフェース

ダル

BL

私もこれを試しました：

使用したいすべてのメソッドをインターフェイスで定義できることはわかっていますが、ジェネリック型に関する多くの問題を管理する必要があります。私の質問から理解できるはずですが、私は C# の初心者であり、少なくとも私がより専門的になるまでは、複雑さを避けたいと思います:)

アプリケーションの各層（つまり、など）に例外を設けることをお勧めPresentationExceptionしますServiceException。PersistenceExceptionしかし、サービスレイヤーが追加の操作なしでDAOメソッド（永続レイヤーのメソッド）を直接呼び出すとどうなりますか。

このような：

このDAOメソッドの呼び出しをtry-catchブロックでラップし、可能な例外を次のように再スローする必要がありServiceExceptionますか？各DAOメソッドはスローする必要がありPersistenceExceptionますか？

MySQL を永続化に使用する多層パターンを実装するアプリケーションを開発しています。データへのアクセスを提供し、DTO を提供する WCF サービスがあります。

さらに、次のパターンを実装する予定です: - DTO - MVP (パッシブ ビューまたは監視コントローラーかどうかはまだわかりません) - 適用可能なインターフェイスに対するコード

現在、私は生のまま次のプロジェクト構造を持っています:

外側のボックスは、Visual Studio のプロジェクト フォルダーです。内側のボックスは C# プロジェクトです

コーディングを続けて実際の実装に時間を費やす前に、自分のプロジェクトの構造やアーキテクチャについてフィードバックをもらいたいと思っています。

私は次の質問に頭を悩ませています：

1. 上記の構造は「ベストプラクティス」に準拠していますか? 例えば。インターフェイスの場所、DTO
2. 2 つのビジネス レイヤーを使用したり、ビジネス レイヤーをクライアントとサーバーに分割したりしても問題ありませんか? サーバー BLL はセッション管理やセキュリティなどの一般的な機能を提供し、クライアント BLL はサービス アクセスを提供します。プレゼンターによるビューも制御します。
3. サーバー側は現在、ドメイン オブジェクトについて認識していません。ここでも使った方が良いでしょうか？これにより、エンティティがドメイン オブジェクトにマッピングされ、次に DTO にマッピングされます。
4. WCF サービスから DTO を受け取るのは一般的ですか、それともドメイン オブジェクトを使用する必要がありますか (ここでよく議論されていることは知っていますが、私が理解していることから、ドメイン オブジェクトがそれほど複雑ではなく、マッピングとコーディングを節約できる場合に適用できます)ドメイン オブジェクトとデータベースを変更するときの労力) これにより、エンティティ<->ドメイン オブジェクト<->DTO<->ドメイン オブジェクトのような通信チェーンを維持するのが非常に難しくなりませんか?
5. バリデーションはどこに置く？主な検証はドメインオブジェクトに行われますが、基本的な検証をビューまたはプレゼンター (たとえば、書式設定、null/not null 値など) に入れることを考えました...?
6. データベースに新しいレコードを作成するとき、たとえば新しいユーザーの場合、クライアントも新しい DTO をサーバーに渡す必要がありますか、それとも string や int などの単純なデータ型を受け入れるサービス メソッドを作成する方がよいでしょうか?

この長い投稿で申し訳ありませんが、私の質問を 1 つの投稿にまとめて、プロジェクトの構造を提供する方がよいと思います。

どんな種類の答えでも前もって感謝します。

よろしく

実行時に別のユニットからリモート データ モジュール (RDM) のインスタンスにアクセスするにはどうすればよいですか? (RDM は単一インスタンスです)。通常のデータ モジュールの子孫を作成すると、Delphi は同じユニットに変数を作成します (例: MyDM: TMyDM) が、RDM の子孫を作成すると、変数はありません。

別のユニットで実行時に作成された TClientDataSet のプロバイダを RDM の TDataSetProvider に設定しようとしていますが、RDM のインスタンスへの参照が見つかりません。

私も設計時にそれを試みましたが、TSQLQuery の接続プロパティを同じユニットからその RDM の TSQLConnection に設定するのに問題はありませんでしたが、TClientDataSet のプロバイダーを設定できませんでした。 RDM は、TClientDataSet のプロバイダー リストに表示されます。

asp.net-identity の使用に関する他のさまざまな質問を読んできましたが、プロジェクトが階層で開発されている場合、既存のデータベースでの使用に関して具体的なことは何もわかりません。議論のために、次のことが正しいとします。

• 解決
  • WebUI
  • サービス
    • ユーザーサービス
  • データ
    • MyDbContext
  • 芯
    • ユーザー

User(Coreプロジェクトから)IUserStore新しい ID プロバイダーを指定するにはどうすればよいですか? それとも、Web サイトとメンバーシップ データベースが常に同じプロジェクトに存在することを前提としていますか (またはMicrosoft.AspNet.Identity.*、モデルが存在するライブラリへの厳密な参照があります)。

認証のためだけに WebUI レイヤーで DbContext を設定する (そしてそれをサービスで "MyDbContext" に結び付ける) ことは、ハックに思えます。何か足りないのでしょうか、それともチームはこれを単純なアプリケーションでのみ使用することを計画していたのですか?

フィードバックをいただければ幸いです。

詳しくは

言及する価値がある場合：

• これはまったく新しいソリューションです。心配する古い/既存のテーブルはありません。私は、他のさまざまなカスタム ソリューションを採用し、それらを 1 つの堅実なソリューションに結び付けようとしているので、多くのオプションを受け入れることができます。ただし、レイヤーごとに分けておきたいと思います（可能な場合）。aspnet_*webpages_*

Tomcat でモノリシック Java アプリケーション (フロントエンド/サービス) を実行しています。私は、アプリケーションのすべての部分を個々の層として (1 つ以上の) Akka アクター システムにゆっくりと移行できるような設計を考え出そうとしています。最初の再設計として、Tomcat でクライアントに面したフロントエンドを維持し、Akka で中間層ロジックの一部を書き直したいと考えています。

この再設計の進め方についていくつか質問があります。

• フロントエンドが Akka と通信する最も効率的な方法は何ですか? REST を検討していましたが、もっと速いものはないかと考えていました。
• 既存の JPA/hybernate エンティティ モデルを Akka 内から再利用するのはどれくらい難しいですか? ドキュメント/落とし穴を探しています。

ありがとう

DTOオブジェクトをサービスレイヤーに渡すのは悪い習慣ではありませんか?

今のところ、私のサービス レイヤー メソッドは次のようになります。

DTO からビジネス エンティティ (MyEntity) への値のマッピングは、プレゼンテーション層で行われます

しかし、メソッドの署名をこれに変更したい:

その後、DTO からビジネス エンティティへのマッピングがサービス層で行われます。

編集： DTOからビジネスオブジェクトにマッピングするときに休止状態のセッションを開く必要があるため、エンティティのすべての変更が自動的にフラッシュされるため、それが必要です。