0

I currently have a service class RoutineService.cs that contains methods that each perform one thing, call the repository and return that exact same object.

  1. With how simple it is, is my service layer necessary?
  2. I feel like it is better to inject the RoutineRepository Service into the controller and skip the service layer. But of course, there may be future extensions that I have not considered. What are some possible reasons (or whataboutisms) to keep the service layer?
  3. More questions below code:
using System;
using System.Threading.Tasks;
using Project.Services.Models;
using Project.Services.Interfaces.Services;
using Project.Services.Interfaces.Repositories;
using ProjectContracts.Models.Responses;

namespace Project.Services.Services
{
    public class RoutineService : IRoutineService
    {
        public IRoutineRepository _routineRepository { get; }

        public RoutineService(IRoutineRepository routineRepository)
        {
            
            _routineRepository = routineRepository;
        }

        public async Task<Routine> CreateRoutineAsync(int groupId, Routine routine)
        {
            return await _routineRepository.CreateRoutineAsync(routine, groupId: groupId);
        }
    }
}

I am currently consuming this service in my controller like so:

namespace Project.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class GroupsController : ControllerBase
    {
        public IRoutineService _routineService { get; }

        public GroupsController(IRoutineService routineService)
        {
            _routineService = routineService;
        }

        // POST api/<GroupsController>/{id}/Routine
        [HttpPost("{groupId}/Routine")]
        public async Task<ActionResult<RoutineResponse>> Post(int groupId, RoutineRequest request)
        {
            var routine = new Routine
            {
                Name = request.RoutineName
            };

            var routineCreated = await _routineService.CreateRoutineAsync(groupId, routine);

            return routineCreated == null ? Conflict() : Ok(new RoutineResponse
            {
                RoutineName = routineCreated.Name,
                RoutineId = routineCreated.RoutineId
            });
        }
    }
}

I have Routine, RoutineResponse and RoutineRequest objects. The Routine object is mapped to a RoutineResponse object in the controller.

  1. Should the RoutineService return a Routine object or RoutineResponse object? I've been reading this for hours but it's hard to understand what people are saying without the actual code. For instance, this comment describes the different kinds of objects (DTO, Domain Entities, etc) but does not post code:
  2. Is the Routine object considered a "Domain Model"?
  3. Is it appropriate to call the RoutineResponse and RoutineRequest objects as "Data contract models"? Would a better name be "presentation models"? Or is there already a name of them and please say what the categories are.
public class Routine {
    public int Id { get; set; }
    public string Name { get; set; }
    public string HideFromDataContract { get; set; }
}

public class RoutineResponse {
    public int RoutineId { get; set; }
    public string RoutineName { get; set; }
}

public class RoutineRequest {
    public string RoutineName { get; set; }
}
0
  1. Each layer has certain responsibility associated with it. Keeping the concerns separated through layers would make it easier to identify the right place to put the right code.

  2. Service layer would be a right place to keep any business logic over more CRUDish looking repository methods.

  3. Other answers -

  4. Service layers should return domain model. Transforming it into a form suited for consumers is a controller layer concern

  5. Routine can be considered as domain model.

  6. I would just call these (RoutineReuquest and RoutineResponse) as DTOs.

| improve this answer | |
  • >Service layer would be a right place to keep any business logic over more CRUDish looking repository methods. ----- What is an example of a business logic that would fit this example? I guess it's still not clear to me. I appreciate the other answers too! – John Nov 22 at 18:23
  • One example could be orchestration of multiple repository method calls. For e.g. imagine you have to make two repo calls for account creation - one for creating account in LDAP repo and another to persist account in DB. Another simpler example could be enriching information from data fetched from repository by grouping or ordering. – Vaibhaw K Nov 23 at 0:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.