Put this logic into a Repository or a Service

Question

Should I put this method into my ISchoolclassCodeRepository or my ISchoolclassService?

/// <summary>
        /// The client passes newly created and existing schoolclass codes.
        /// The newly created schoolclass codes are returned.
        /// </summary>
        /// <param name="newAndExistingSchoolclassCodes">All schoolclass codes and the newly created by the user</param>
        /// <param name="schoolyearId">The related schoolyear for a schoolclass code</param>
        /// <returns>The newly created schoolclass codes</returns>
        public IEnumerable<SchoolclassCode> GetNewCreatedSchoolclassCode(IEnumerable<SchoolclassCode> newAndExistingSchoolclassCodes, int schoolyearId)
        {
            var existingSchoolclassCodes = _uniOfWork.SchoolclassCodeRepository.GetSchoolclassCodes(schoolyearId).ToList();
            var newSchoolclassCodes = existingSchoolclassCodes.Except(newAndExistingSchoolclassCodes,new SchoolclassCodeComparer());
            return newSchoolclassCodes;
        }

Answer 1

This seems to be more like application logic, in your case this would be implemented in your service. However, this often goes into an application layer. Here's some more information that explains the various layers, maybe you want to adopt some of these concepts.

Repositories only hold data access logic: this means CRUD-like operations.

Answer 2

My vote will be for ISchoolclassService, if you have one. I would't create one just for this purpose however.

It also depends on what SchoolclassCodeComparer does. If it has it's own data access, then it would be invoking the same repository to fetch school codes?

If there is a way one could pass the constraint imposed by SchoolclassCodeComparer to the query, then I would have this in the repository. Postprocessing of resultset using various rules could reside in the service.

I prefer to have the repository layer deal with DataAccess. Logic in Dataaccess would be limited to constructing parameters, and creating projections of result returned (if required).

Massaging/filtering the dataset based on any other business logic could be the service's job.