Repository Pattern - Summary Information

Question

I have the following entities in Entity Framework:

public class School {
    public int Id { get; set; }
    public string SchoolName { get; set; }

    public virtual ICollection<Course> Courses { get; set; }
}

public class Course {
    public int Id { get; set; }
    public int SchoolId { get; set; }
    public string CourseName { get; set; }

    public virtual ICollection<Student> Students { get; set; }
    public virtual School School { get; set; }
}

public class Student {
    public int Id { get; set; }
    public string FullName { get; set; }

    public int Grade { get; set; }

    public int CourseId { get; set; }
    public virtual Course Course { get; set; }
}

Each school has many courses
Each course only belongs to one school
Each course has many students
Each student only belongs to one course

I have a specific page in my application that needs to summarize some information which you can see in this jsfiddle: http://jsfiddle.net/Jsf3f/

Basically I need to display the data in a table that rolls up the information. I need to show each school in its own line, which has the total number of students in all courses and the highest grade in all of those courses. I also need to display each course individually that also summarizes the information with the number of students enrolled in it and the highest grade of all students in the course.

In order to do this I am pretty sure I need to create new Domain classes that can summarize this information.

My questions:

To properly summarize this information would I create a repository that deals with returning a SchoolSummary object. Would SchoolSummary be considered an aggregate root in Domain Driven Design?

Do I instead try and create a different domain model and have the summary be only a view model that can easily translate the domain objects into summaries.

I think I am having trouble trying to visualize the domain layer vs just my database layer (Entity Framework) and presentation layer (MVC).

score 3 · Accepted Answer · answered Mar 10 '12 at 06:37

Truth be told you can apply DDD in the rest of the app, but in this case you're dealing only with queryies and reports. If you're using CQRS (Command Query Responsability Separation) then basically you can create a simplified query model (parts of the view model itself) and a query repository which will serve them.

So no need for AR, just a repository tailored for the reporting usage. About DDD, IMO is suitable just for commands (create and update model), but an app has both reads and writes so what is not a 'write' can be handled in a more simplistic way. In the end we apply a mindset where it's needed in an app, we shouldn't force an app to fit in a mindset.

score 1 · Answer 2 · edited May 23 '17 at 11:48

You are having trouble visualizing the domain layer because you don't have any domain logic. You should only use DDD when you need it. From what you have posted, it seems you have a few anaemic entities. Keep things simple and resist the temptation to use DDD unless you have complex business logic. You will be much happier.

As for the SchoolSummary, this sounds like a message (DTO, ViewModel, etc) that you want to compose from a query and then sling up to the view. Nice and simple.

Hope this helps.

Repository Pattern - Summary Information

2 Answers2