CODEWITHSUNDEEP
linqazurerepositoryrepository-patternodata
makerofthings7
makerofthings7

Reputation: 61463

OK to have Views or ViewModels returned by the Repository vs Service Layer? Which should be cached?

I'm using Azure AppFabric for caching with a brand new repository. My repository looks something like this:

public interface IMyRepository
{
  public IEnumerable<K> Select(IQueryable<T> someQuery) 
  public IEnumerable<T> SelectAllStudents()  // should I replace T with Children in my repository?
}

My intent is to expose and cache OData requests from the client, hence the IQueryable. I also have a secondary need to frequently return data that looks like this

public class Children
{
  public string Name {get;set;}

  public int CountOfToys {get;set;}

  public List<Toys> {get;set;}
}

However my database is a 1..many of Children to toys.

The current ASP.NET application is using Navigation properties of EF directly in the aspx page to populate the ViewModel above, however I don't know the most efficient route port this functionality to a repository.

Due to AppFabric caching my constraints for the IEnumerable results are:

  1. How do I implement the IMyRepository to support caching OData queries?
  2. Is it OK for a repository to emit not only model classes, but the "children" aggregate class? What is the proper term for this?
  3. Assuming that the step above is Okay, should I use navigation properties to populate this extra class?

Upvotes: 1

Views: 168

Answers (1)

Shaun Xu
Shaun Xu

Reputation: 4656

Caching the repository entities will be more easy to control, which means you have a in memory database in your system, but less performance and flexibility. Caching domain objects gives your more performance as it is more close to what you actually want to cache. But you need to think of the synchronization between the cache items. I would like to cache on service layer, by introducing a separated cache manager component.

Upvotes: 0

Related Questions