私は、データのリポジトリを管理し、さまざまなメディアを通じてユーザーに配布するための、かなり大規模なシステムの設計に取り組んでいます。議論のために、これがウィジェットと注文の大きなカタログであるとしましょう。設計に関して私が不満に思っていることの 1 つは、システムのさまざまな部分に多数の並列ではあるが別個のオブジェクト モデルがあり、それらを管理および相互変換するためのコードが大量にあることです。
より具体的に言うと、これまでのところ、少なくとも次のことがわかっています。
Entity Frameworkドメイン モデル。これがすべての真実の源であり、データベースに保存されているものです。hereは
Widget、ウィジェットに関するすべてを知っています。これは Code First POCO モデルですが、EF は、モデルが適切に機能するために定義する必要があるプロパティに特定の制約を課します。(外部キー ID を除外しようとすると、IMO が苦しみます。)管理 Web アプリのビュー モデル。表示ビューのほとんどは、ドメイン オブジェクトをそのまま使用できます。ただし、すべてのプロパティを直接編集できるようにする必要はありません。一部のプロパティは、保存されているものとは異なる形式で編集できるようにする必要があります。
ネイティブ モバイル アプリのセットで使用される Web APIのDTOのセット。ここでの焦点は、a) アプリが必要とする情報 (のみ) を提供すること、および b) シリアル化プロセスから得られる JSON の形状を定義することです。出力は常にドメイン モデルと 1 対 1 であるとは限りません。
また、OEM が独自のウィジェットを表示および管理できるようにするための並列 Web API にも取り組んでいます。要件はモバイル指向 API や内部管理サイトと同じではないため、この API が公開する
Widget部品注文のデータ セットは 100% 一致しません。
移動されているのはすべて同じ概念エンティティですが、システムのさまざまな部分がそれらと異なる方法で相互作用したり、それらのさまざまな側面と相互作用したりします. 新しいフィールドを追加したり、検証ロジックを変更したり、さまざまな名前空間のさまざまなクラス全体に触れたりWidget、翻訳コードを調整したりする必要がある可能性があります。概念的に難しいわけではありませんが、面倒でエラーが発生しやすいです。
ビューのレンダリングとシリアライゼーションの管理に関連する属性でドメイン モデルを装飾することに美的な異議がなかったとしても、エンティティには複数のビュー セットまたは複数の API が存在することがよくあります。エンコードする命令のセット。
物事を体系化し、単純化することを要求する性質の人間として、率直に言って、これはすべて私を悩ませています. 臭いです。何かが欠けているに違いないという気持ちから逃れることはできません。これを処理するためのより良い/よりクリーンな方法があるはずです。
この拡散を軽減 (または自動化) するために、どのような戦略やツールを利用できますか? それとも、この種の重複は避けられないのでしょうか?
このシステムを組み立てる方法でフレームワークと戦っていますか?