バックグラウンド
私たちは独自のビジネス オブジェクト アーキテクチャを持っています。これは、同様の使用法、検証、包括的な DAL などを備えた「CSLA」ビジネス オブジェクト フレームワークのはるかに軽量な (...大まかに基づいていますが、実際には使用していません...) バージョンです。すべてコードが生成されます (ストアド プロシージャとビジネス オブジェクトは CodeSmith を使用して作成されます)
ビジネス オブジェクトは、オブジェクトを取得する機能、オブジェクトおよび汎用リストを返すためのフィルター ソート パラメータを備えたリスト機能に関して非常に豊富です。
このアーキテクチャは、特定のアーキテクチャや一般的なアーキテクチャや純粋主義に同意していない可能性がありますが、私たちにとってはうまく機能し、多くの手動コーディングを削減しました。
特に他のシステム (サードパーティ、Flash、Silverlight など) と統合する場合に多く見られることの 1 つは、コンテキスト化された「基本オブジェクト」または特定の目的のために Web サービスなどで簡単にシリアル化して提供できるデータ コンテナーの要件です。
SO や Web を見回すと、DTO という用語がよく出てきます。これらの基本オブジェクトは、Dto 名前空間内に作成されています。これらのオブジェクトは、ビジネス オブジェクトの基本または特定のバージョンを表す基本オブジェクトですが、DataRow またはビジネス オブジェクトのいずれかを受け入れて「Dto」オブジェクトを設定するコンストラクター以外の機能はありません。
質問:
1)これを「DTO」オブジェクトと呼ぶのは正しいですか?
2)データを提供し、オブジェクトのプロパティを設定するコンストラクターを持つのではなく、この人口コードが別のクラス、ある種の「ヘルパー クラス」にある必要があります。
私がやろうとしていることの用語と命名規則に関するコメントはありますか?
ありがとう