http://docs.servicestack.net/physical-project-structure コード体系と移行などを行うために、ServiceStack内でOrmLiteを整理するのにどのような方法が最も適しているのかよく分かりませんでした。ServiceStack OrmLite - 物理的なプロジェクト構造
これに関するベストプラクティスは何ですか?
http://docs.servicestack.net/physical-project-structure コード体系と移行などを行うために、ServiceStack内でOrmLiteを整理するのにどのような方法が最も適しているのかよく分かりませんでした。ServiceStack OrmLite - 物理的なプロジェクト構造
これに関するベストプラクティスは何ですか?
OrmLiteは、依存性のないPOCO(Plain old C#Objects)で動作します。これは、ソリューションの複雑さに応じてどこでも維持できます。
この回答は、reuse your DTOs for your OrmLite modelsの最も簡単な方法について説明しています。あなたの必要性が発散し、DTOとデータモデルを分離する必要がある場合(例: RDBMSテーブルに返されるフィールド数より多くのフィールドが追加されたため、ServiceInterface
実装プロジェクトでフィールドを保持することができます。
ソリューションの複雑さが増し、サービスモデルとは別にデータモデルにアクセスする必要がある他のコンポーネントがある場合は、OrmLiteモデルを独自のDataModel
プロジェクトに移動することができます。注:あなたの "モデル"プロジェクトは、依存性が最小限でなければならず、すべてのロジックプロジェクトはそれらに依存していなければなりません。
たとえば、MyProject.ServiceInterface、MyProject.ServiceModel(DTOを表す)、OrmLiteモデルを表すMyProject.DataModel、ServiceInterfaceまたはDataModelプロジェクトとこの1つのIの間のいくつかのレイヤーに必要な場所DTO(ServiceModel)オブジェクトに変換できますか? – ShP
私は個人的にDataModelsフォルダ 'ServiceInterface'に保存しておき、必要なときに別のプロジェクトに移動するだけです。別々のDataModelとDTOがある場合は、[組み込みのAutoMapping](http://docs.servicestack.net/auto-mapping)を使用してそれらの間を簡単にマップしたいと思うことに注意してください。 – mythz
そして、これらの別々のDTOを同じプロジェクト(DTOのフォルダなどのServiceInterface)に保存することをお勧めしますか? – ShP