Skip to main content
Software Engineering

Return to Answer

added 849 characters in body
Source Link
Christophe
Christophe
  • 80.6k
  • 11
  • 132
  • 199

You are fully right on the principle. The MVCMVC should have the business logic and the data access layer in the Model. The Controller should manage user input and transforms it into commands either for the View or for the Model. There should be no buisnessbusiness logic herein an MVC controller.

But the code snippetcode snippet you show (from here?) from the controller does not seem to infringe this segregation of concerns:

  It‘s not business logic: its logic is to, but a query of the model to create a view. So typically the coordination things that an MWC controller does.

You may be confused to think that it accesses the DB directly. But it appears that (_context_context is not a db context, but an MvcContextbut an MvcMovieContext, i.e. an object to access the model)that is part of the model. It uses the result to create a View.

But it’s not completely classical MVC either. In the original MVC, the logic would be to create a view and passing it it the id, and let the view query the model (andfor the model notifyclarity of the view if data changes). The snippet‘s approach looks more like an MVP to me, where P istutorial we could indeed regret that the mediator between model and view.

  • MvcMovieContext inherits from a DbContext, a shortcut that might leak some implementation details outside the model.
  • The separation of concerns does not fully match the classical MVC. In the original MVC, the logic would be to create a view and passing it the id, and let the view query the model (and the model notify the view if data changes). In this regard, your snippet‘s approach looks more like an MVP to me, where P is the mediator between model and view.

You are fully right. The MVC should have the business logic and the data access layer in the Model. The Controller should manage user input and transforms it into commands either for the View or for the Model. There should be no buisness logic here.

But the code snippet you show (from here?) from the controller does not seem to infringe this segregation of concerns:

  It‘s not business logic: its logic is to query the model (_context is not a db context, but an MvcContext, i.e. an object to access the model). It uses the result to create a View.

But it’s not completely classical MVC either. In the original MVC, the logic would be to create a view and passing it it the id, and let the view query the model (and the model notify the view if data changes). The snippet‘s approach looks more like an MVP to me, where P is the mediator between model and view.

You are fully right on the principle. The MVC should have the business logic and the data access layer in the Model. The Controller should manage user input and transforms it into commands either for the View or for the Model. There should be no business logic in an MVC controller.

But the code snippet you show from the controller does not seem to infringe this segregation of concerns: It‘s not business logic, but a query of the model to create a view. So typically the coordination things that an MWC controller does.

You may be confused to think that it accesses the DB directly. But it appears that _context is not a db context, but an MvcMovieContext, i.e. an object that is part of the model. It uses the result to create a View.

But for the clarity of the tutorial we could indeed regret that the

  • MvcMovieContext inherits from a DbContext, a shortcut that might leak some implementation details outside the model.
  • The separation of concerns does not fully match the classical MVC. In the original MVC, the logic would be to create a view and passing it the id, and let the view query the model (and the model notify the view if data changes). In this regard, your snippet‘s approach looks more like an MVP to me, where P is the mediator between model and view.
Source Link
Christophe
Christophe
  • 80.6k
  • 11
  • 132
  • 199

You are fully right. The MVC should have the business logic and the data access layer in the Model. The Controller should manage user input and transforms it into commands either for the View or for the Model. There should be no buisness logic here.

But the code snippet you show (from here?) from the controller does not seem to infringe this segregation of concerns:

It‘s not business logic: its logic is to query the model (_context is not a db context, but an MvcContext, i.e. an object to access the model). It uses the result to create a View.

But it’s not completely classical MVC either. In the original MVC, the logic would be to create a view and passing it it the id, and let the view query the model (and the model notify the view if data changes). The snippet‘s approach looks more like an MVP to me, where P is the mediator between model and view.