2

私はservicestackを使用しており、データアクセス層にormliteを使用することを計画しています。これらのテーブルがあります（SQL Server 2005）

Table ITEM
ID PK
...

Table SUBITEM1
ID PK FK -> ITEM(ID)
...

Table SUBITEM2
ID PK FK -> ITEM(ID)
...

Table POST
ID PK
...

Table COMMENT
ID PK
...

Table DOWNLOAD
ID PK
...

Table POST_COMMENT
ID PK
POST_ID FK -> POST(ID)
COMMENT_ID FK -> COMMENT(ID)

Table DOWNLOAD_COMMENT
ID PK
DOWNLOAD_ID FK -> DOWNLOAD(ID)
COMMENT_ID FK -> COMMENT(ID)

各テーブルのクラスを作成し、アノテーション（自動インクリメント、参照など）を使用してそれらをマップしました。

「エンティティ」（アイテム、投稿、コメント、ダウンロード）ごとにリポジトリを作成することにしました。各リポジトリには、基本的なCRUDロジックが含まれています。

例えば。1 CommentRepositoryには、db.Insert（コメント、関係）を実行するSave（コメントコメント、オブジェクト関係）があります。ここで、関係はPostCommentまたはDownloadCommentです。

例えば。2 PostRepositoryには、POSTへの挿入を実行するSave（Post p）があります。

リポジトリのインターフェースが異なり、ポリモーフィッククエリを実行できないため、このソリューションについてはよくわかりません。

DALを改善するためのアドバイスを教えてください。

ご清聴ありがとうございました。

4

1 に答える 1

10

私は強制的な人工抽象化のファンではないので、すべてのエンティティのリポジトリから始めるのは好きではありません。不必要なコード膨張につながるだけだからです。私は、すべてのデータアクセスをカプセル化するすべてのエンティティに対して1つのリポジトリから始めて、大きくなりすぎたときに自然にリファクタリングするのが好きです。

最適なRDBMSレイアウトが何であるかを知るのに十分なドメインを知りませんが、可能な限り不要なテーブルを作成することを避け、非集計ルートデータをブロブするようにします。親アイテムのコンテキスト外で意味がある場合は、いくつかのテーブルを保存してブロブします。例：

class Item {
   int Id; //PK, AutoIncr
   List<SubItem> SubItem;
}

個別のMany：Manyテーブルではなく、単一のCommentテーブルに保持します。例：

class Comment {
    int Id; //PK, AutoIncr
    string CommentType; //i.e. Post or Download
    int RefId;
    string Comment;
}

したがって、私のリポジトリは、Webリクエストを実行するために必要なデータアクセスパターンを模倣します。

class BlogRepository {
    void AddCommentToPost(int postId, Comment comment);
    void AddCommentToDownload(int downloadId, Comment comment);
}
于 2012-10-04T18:28:19.417 に答える