Interaction between Action Methods and Repository classes inside asp.net mvc

Question

I am working on asp.net mvc5 web application and I am using entity Framework as the data access layer. Whenever I start implementing new requirement , I always get stuck on how I should design the interaction between action methods and repository classes. . for example let say I have the following Post Create action method:-

Public ActionResult CreateStudent (Student student)
{
repository.AddStudent(student);
repository.Save();
return RedirectToAction(“Index”);
}

And here is the repository

Public class Repository {
Public Void AddStudent (Student student)
{
// + Initiate a pending Audit Object
//+ Create new Person object and retrieve its ID
SaveChanges();
//+ create new Student and assign it to the created Person
// + Complete Audit object
}

This is how I currently implement the interactions, less calls from action method to repository, and i have somehow large repository methods.

But as another approach I can have more calls to the repository methods, and have smaller repository methods comparing to the first approach such as:-

Public ActionResult CreateStudent (Student student)
{
var audit = repository.IntiateAudit(student);
var person = repository.AddPerson(student);
repository.Save();
var student2 = repository.AddStudent(person);
repository.CompleteAudit(audit);
repository.Save();
return RedirectToAction(“Index”);
}

And here is the repository

Public class Repository {
Public Audit IntiateAudit(Student student)
{
//implementation goes here…
Return Audit;
}
Public Person AddPerson (Student student)
{//implementation goes here…
Return Person
}
Public Student AddStudent (Person person)
{//implementation goes here…
Return student;
}

so generally speaking which approach is considered better;either having smaller repository methods and multiple calls , OR large repository methods with less calls to the repository methods ?

Answer 1

I wouldn't put those individual repository calls in the controller as you generally shouldn't really be responsible for the implementation details of creating a student there.

I would have the controller implement a Student Service and have a CreateStudent method on the service. The service would implement the repository(s) or context(s) it needs to deal with orchestrating the logic needed.

If you have a service you can encapsulate logic which spans repositories and hide the details from the controller which should not act as the model. Services are easily reusable - e.g. maybe later you'll add an API layer to your app which can also create students. You don't want to replicate code to do that. Accessors. You could also create a data accessor layer which would hide the repositories and UoW.

Answer 2

Actually I went through building an MVC 4 portal where I put everything inside the MVC application, for example my business logic in the controllers, my data access in the model, and my presentation layer in the view.

This approach would be suitable for small projects where you don't have that much business logic and a small data model, using this pattern you would put all the calls inside the controller and areas section, you would have helper classes to do some business logic, the model will hold only data definitions, and the view will list the data.

A new approach which I love more and I work toward in my new systems is to deal with the MVC application as a presentation layer, where the controller will do the needed preparation and format to send the data(model) to the view to be presented.

In this case you need a new BLL (class library or a service) which will hold all your business, and DAL (class library or service) to hold all your data access work.

In this case the MVC application will do minimal calls to the BLL to get whatever data/logic processing, and the BLL will do the same if it needs to get some data from the DAL.