複数のプロジェクトを持つ単一のソリューションビジュアルスタジオWebアプリケーションがあります。プロジェクトの1つ(サービスプロジェクト)には、アプリクライアント(Android/Ios)用のAPIがあります。デスクトップとモバイルWebサイトを強化するMVCアプリケーション用の個別のプロジェクトがあります。要求/応答オブジェクト用のPOCOクラスを持つDTOのプロジェクトが1つあります。 1つのプロジェクトは、すべてのビジネスエンティティを持つエンティティ用です。 ViewModelクラスは、MVC/UIプロジェクト自体に保存されます。アダプタークラス(DTOをエンティティに、エンティティをDTOに変換するため)は、それぞれサービスプロジェクトとMVC/UIプロジェクトにあります。
Android/iOSの場合、リクエスト/レスポンスは次のようになります。リクエストパラメータはサービスプロジェクトに送られ、サービスのプロジェクトアダプタを通じてDTOとしてマッピングされます。このDTOはエンティティに変換され、BL、DAL、DB/MicroServicesに渡されます。応答はエンティティとしてサービスプロジェクトに返され、アダプタークラスを介してDTOにマップされます。このDTOは、クライアントへの応答として渡されます。
Webサイト(モバイルおよびデスクトップ)の場合、要求/応答は次のようになります。要求パラメーターはMVC/UIプロジェクトに送られ、MVC/UIプロジェクトアダプターを通じてDTOとしてマッピングされます。このDTOはエンティティに変換され、BL、DAL、DB /に渡されます。 MicroServices。応答はエンティティとしてMVC/UIプロジェクトに返され、アダプタークラスを介してViewModelにマップされます。このviewModelは、HTMLを生成してクライアントにHTMLを渡すビューに渡されます。
DTOとViewModelの主な違いは、DTOがフラットオブジェクトであるのに対し、ViewModelにはネストされたオブジェクトがある場合があることです。また、ViewModelには複合フィールド、つまりFullName(FirstNameとLastNameの組み合わせ)などのフィールドがある場合がありますが、DTOにはFirstName、LastNameなどの単純なプロパティしかありません。その理由は、アプリに柔軟性を与えたいということです。つまり、アプリはLastNameとは異なるフォントでFirstNameを表示したいと思うかもしれません。
上記のアーキテクチャに関するクエリはほとんどありませんか?
ビジネスロジックとWebサイトの間にサービスレイヤーがないようです。
ダイアグラム上で水平スライスを描くと、次のいずれかを選択できることがすぐにわかります。
既存の「サービスプロジェクト」をそのレイヤーに移動し、Webサイトとモバイルクライアントの両方がそれを使用するようにします。
または、スリム化された2つのWebSite/WebAPIプロジェクトが使用するBusiness Objectsのオーケストレーションで構成される新しいプロジェクトを作成します。
ビューに関連しないロジックをサービスレイヤーに移動した後のWebSite/WebApiの主な役割として、アダプター用のプロジェクトはこれ以上ありません。
クライアントからDTOのみを受け入れ、DTO/HTMLのみをクライアントに返すことは正しいですか?リクエストごとにDTOをエンティティに変換し、レスポンスごとに逆にする必要はありますか?
あなたには多くの選択肢がありません。エンティティのシリアル化は、DTOまたはViewModelである必要があります。
あなたの唯一の質問は、ViewModel/DTOがエンティティにどれほど似ているかです。通常、ViewModel/DTOは、フィールドを追加したり、データをフラット化したりすることで、View/Clientの作業を簡素化します。しかし、最も簡単な方法は、エンティティをそのままシリアル化することです。
MVC/UIプロジェクトはWebAPIを介して通信する必要があります。その後、モバイルアプリケーションとWebアプリケーションの両方でWebAPIを再利用できます。別のサービスレイヤーが必要になるまで、ビジネスレイヤーを単独で使用してWebおよびAPIと共有することはできません(これは必須ではありません)。APIとWebアプリケーションとしてソリューションを個別に展開する必要があります。