This is an MVC design/refactoring question.

I am using a Controller and inside I do these tasks:

  1. I get Price of an object from a database, for which I use a repository pattern
  2. Create a LineItem object, which I initialize with the price and other data
  3. I Execute the "save to database" command, for which I use a SaveLineItem service. It's a simple service that just saves the LineItem

Currently all 3 of the above actions happen in the Controller

I am however wondering if I will do better by moving the actions 1 and 2 into the SaveLineItem service, thus assigning more responsibility to that service.

By doing so I will have a smaller controller, but I will also have a more bloated service. What used to be a service that just dealt with the LineItem object, will now deal with getting the price of the object, creating the LineItem object, and then saving it.

My question is, should I do this refactor? Is bloating the service and assigning more responsibility to it outweigh keeping the bloat inside the controller?

2 Answers 2


I believe it may be good to keep the SaveLineItem service simple (aka don't modify it), and instead create a separate service to create the LineItem, and move 1 and 2 into that service.

This gives best of both worlds - moves bloat from Controller into the new service, and keeps SaveLineItem service simple, and focused just on the line item.

The overall cost here is creating that new service


Indeed, grouping all of your three actions into the saveLineItem service would be a very bad idea, as you figured out in your own answer, because step 1 and 2 only relate to new items.

But the rationale for doing so is not related to the bloating of some layers more than others; it's about separation of concerns between the different layers. Let me explain more in detail.

In the original MVC architecture:

  • the model represents the "knowledge", that we would now call the domain logic. In your case, it's everything the system has to do with line items, independently of how the user will do it.
  • the controller is the link between the user and the system. It translates user actions into view and domain actions.

So the best way to approach your question is to have two domain services:

  • one for creating a new line item. Typically, if it's about line item in a business document, you'd need for example to assign a new chronological line item number, to keep the line items in the right order, and do others things that you don't need to do for existing lines.
  • one for modifying a line item. Typically, in a business document you would not renumber the item that you save (unless specific case of inserting a new item) and you would not ignore the price that the user just changed.

You'd also certainly need one for deleting line items.

I'm however not sure if step 1 should really go together with step 2 in the model layer: this packaging of actions seems to be more related to how the user performs the creation, rather than a neutral model related principle that must always be followed (i.e. the user types a material reference, and you'll search for him the default price, but what if the user already entered a discounted price ?). Up to you to make up your mind based on the requirements and the context.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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