I would make BlogEntry it's own Aggregate root, with it's own repository. You would get BlogEntry instances for a particular Blog by querying the BlogEntry repository for all BlogEntry's that have a given BlogID. I can't provide specifics about the repository beyond that since there are several different strategies for implementing repositories (one generic repository vs many, separate finder methods vs one that takes a complex specification object, etc). The finder method of the repository should support paging.
public class Blog
{
public int ID {get;set;}
// other stuff
}
public class BlogEntry
{
public int ID {get;set;}
public int BlogID {get;set;}
}
public class BlogEntryRepository
{
public IEnumerable<BlogEntry> FindByBlogID(
int blogID, int pageIndex, int pageSize)
{
// implementation
}
}
Alternatively, (also with BlogEntry modeled as an Aggregate root) you could add a collection of BlogEntryIDs to your Blog class. This would be better than having the BlogEntry instances themselves in the Blog class as you would have much less data to load when you want to get a Blog instance. With those IDs, you could select a subset of them and pass them into a BlogEntry repository method that accepts a collection of IDs. In other words there would be a little more logic in your domain to support the paging, and a more generic getter in the repository.
public class Blog
{
public int ID {get;set;}
public IEnumerable<int> BlogEntryIDs {get;set;}
// other stuff
}
public class BlogEntry
{
public int ID {get;set;}
public int BlogID {get;set;}
}
public class BlogEntryRepository
{
public IEnumerable<BlogEntry> Get(IEnumerable<int> blogEntryIDs)
{
// implementation
}
}
Usage for this approach would be like
// get the second page
var entries =
blogEntryRepo.Get(blog.BlogEntryIDs).Skip(1 * PAGE_SIZE).Take(PAGE_SIZE);
In the database, you would return multiple rows, one for each blog entry. (I also prefer to return multiple result sets to get all rows from all related tables in one database round trip. I also make use of SQL 2005's ROW_VERSION function to enable database paging.)
I generally prefer the second method, unless the typical usage shows prohibitive quantities of (e.g. more than a couple thousand) BlogEntry instances associated with a Blog. An array of too many int's would make me wary of performance and memory.