Question

Say you have these two classes.

public class Author
{
public int ID {get; set;}
public string Name{get; set;}
public virtual ICollection<Book> Books { get; set;}
}

public class Book
{
public int ID {get; set;}
public string Name{get; set;}
public int AuthorId {get; set;}
public virtual Author Author{ get; set;}
}

If I have a BooksController that has all its actions receive a AuthorId

I go to this address:

/Authors/1/Books

Does it make sense to just use a current AuthorRepository?

public ActionResult Index(int AuthorId)
    {
    return View(_AuthorRepository.GetById(AuthorId).Books)
    }

Or for the sake of keeping data access inside repositories I should create a BookRepository?

public ActionResult Index(int AuthorId)
    {
    return View(_BookRepository.GetByAuthorId(AuthorId))
    }

same thing happens with Create action. I have a hard time deciding which one makes more sense.

[HttpPost]
public ActionResult Create(int AuthorId, BookViewModel book)
{
if(ModelState.IsValid)
{
Book b= new Book();
b= AutomapperMagicMethodThatGivesMeABookFromA(book); //
_AuthorRepository.FindById(AuthorId).Books.Add(b);
_AuthorRepository.SaveChanges();
return RedirectToAction("Index");
}
return View(book)
}

Or this approach.

[HttpPost]
public ActionResult Create(int AuthorId, BookViewModel book)
{
if(ModelState.IsValid)
{
Book b= new Book();
b= AutomapperMagicMethodThatGivesMeABookFromA(book); //
b.AuthorId = AuthorId;
_BookRepository.Add(b);
_BookRepository.SaveChanges();
return RedirectToAction("Index");
}
return View(book)
}

I would appreciate some advice on handling scenarios like this.
Feel free to criticize my code as much as you want.

Please help thanks in advance.

ps. Im using EF, if it makes any difference.

Answer 1

The general rule of thumb is to create one repository per aggregate root.

Where an aggregate root can be thought of as like a “parent”, and a “child” cannot exist without a parent.

In your example, the Author is the aggregate root, because a Book cannot exist without an Author. (the FK proves this).

Therefore, you should just have a LibraryRepository, that is capable of working with both authors and books, with a single Entity Framework objectset.

We actually enforce these aggregate boundaries in our Repository by typing the ObjectSet to the generic type on the Repository.

So you might have:

public class LibraryRepository : IRepository<Author>, GenericRepository<Author>
{
   public Author FindById(int id)
   {
      return _context.SingleOrDefault(x => x.AuthorId == id);
   }

   public Book FindById(int bookId)
   {
      return _context
         .Where(x => x.Books.Any(y => y.BookId == bookId))
         .Select(x => x.Books.SingleOrDefault(x => x.BookId == bookId))
         .SingleOrDefault();
   }
}

In the above example, _context is a protected property in the generic repository, which is typed to ObjectSet<Author> (which is T on the Generic Repository).

However, see how it’s kind of messy to find a book. If you find yourself needing to find a “child” on it’s own (e.g without retrieving the parent first), then you should consider creating a book repository as well.

So it comes down to two things:

1. Enforcing aggregate boundaries
2. Creating repositories that serve your application

Think about the user interface, what information does each screen need, what information does it have at hand to identify that piece of info (e.g URL).