Note that while I agree that the layered scheme is interesting for a lot of scenarios - this is often called "mediator pattern" - it's a common misunderstanding that MVC implies it.

In MVC the View must have access to the model objects, and must call the model API directly.

The cause of that misunderstanding is related to the fact that when using the "mediator pattern", the business logic is implemented in the controller, and the model acts just as a "data access object". But in MVC, the business logic resides in the model, which might, in turn, use "data access objects", such as DBIx::Class, to perform its actions.

The following diagram explains how working with the "mediator pattern" works.

  V          C        M
  I   ---\   T  ---\  O
  E   ---/   R  ---/  D
  W          L        L

In this scenario, the controller "encapsulates" the model, implementing the business logic.

If we were to translate that to MVC, the View in "mediator" is implemented by both the View and the Controller in "mvc", the Controller in "mediator" is the Model in "mvc" and the model in "mediator" is just the "data access object" in "mvc".

That means: when you work with MVC you probably have a set of Model classes that are not the DBIC objects, implementing the access to them.