is it bad practice that controller call domain objects(entities) direclty instead of service?

Question

is it bad practice that controller call the methods of domain objects directly instead of service?

to explain more:

I figure out that in good design controllers call service and service use Domain objects(entities).

but sometimes in controller I don't have/need any logic and just need to fetch from db and pass it to view

and I can do it by just calling methods in Domain objects(entities) - no need to call service - is it bad practice?

as a example

Class Student{

public function getName(){//return the student name};
public function setName(){//setting the the student name};

}

access getName() method directly from controller

Answer 1

Original MVC architecture

In the original MVC architecture (Xerox PARC in 1979), the controller handles the user interaction. It interacts with the model and with one or several views. The split of responsibility requires that the controller doesn't intervene in the rendering which is of responsibility of the view.

In this architecture, there is no need for services : it's perfectly valid for a controller to access domain objects directly.

MVC descendents

This is different from a MVP architecture (initially introduced by Talligent in 1996), where the presenter (aka controller) acts as middleman between the view and the model. The idea is that in a client-server architecture, the presenter could be split between the the server where the domain model is maintained, and the client that takes care of the view.

This is why, in MVP, the controller is supposed to only access the model through "commands" and "selections". So here a service layer should be used.

Service layer or not ?

This article makes the difference between MVC, MVP and MVVM clear.

Unfortunately frameworks often have their own understanding of MVC (e.g. Apple or Google Chrome team). It's not clear which MVC framework you are using : if needed edit your question to clarify.

Nevertheless, regardless of MVC, a domain could be supposed to be used by several application via an API (or implemented as a microservice). Then a service layer could be required because of other architectural considerations, and not because of MVC.

Answer 2

I think @Christophe gives an excellent answer regarding the approach to services in the MV* patterns, I'll add an answer in case your question was pertaining to Domain Driven Design.

In a DDD approach, the answer to your question is more clearly "No, it's not wrong". You would typically start your design using only domain models, interacting directly with them and calling their methods directly. You only factor in services when you need them, usually because you need to coordinate behavior that's outside the scope of a single entity or to interface with a concern outside the application (e.g. Database or web service).