Should you pass models directly to view - Laravel

[Drongo_III]

Hi there

I've recently been working on a Laravel project.  It's a project I've been drafted in to work on and I've not used Laravel before.

My question is one of what is considered good practice.  In this project the controllers pass whole models back to the view.  For instance, its the norm on the project to pass back a whole booking model just to get at a couple of attributes like booking->id and booking->name.  As these attributes represent database columns it feels a bit wrong to pass these around because you're effectively coupling the view to the structure of the database. I know behind the scenes Laravel is using a magic method to access the properties so you could argue they are wrapped in a method and therefore don't expose the direct database structure to views. 

So the question is, would you pass database models directly to views in this way? Or is it 'better' to map those models to an intermediary model that is dedicated to the view (a sort of dto)?

Thanks,

 

Drongo

[requinix]

There's going to be coupling somewhere, both regarding database structures and what you do in the view. And from a practical standpoint, the database really shouldn't be being revised so much that coupling is a problem.

If you don't like passing database models then create and use business models, which look a lot like database models but aren't tied directly to the database. Of course now your views are tied to those models, bringing us right back around to the "stop screwing around with your data structures" argument.

[maxxd]

Personally I like to refine and/or finesse the data as necessary in the controller before it reaches the view. This sets up basically very dumb views where any business logic is taken care of before the view is rendered. However, part of the system I'm currently working on does pretty much what you describe and passes raw data directly to the view where it decides what to display and how and it works just fine. As requinix points out, some degree of coupling is pretty much unavoidable so I guess it depends on what's easiest for you reason about.

[Drongo_III]

Thanks guys - it helps to get another perspective.  I quite like the idea of view-models/business-models/DTOs whatever you want to call them as I too subscribe to the idea that views should do as little thinking as possible - especially when the view is comprised of multiple components from different database models.  But I take your points that coupling has to happen somewhere and database change is likely to be infrequent.  I suppose it's a matter of consistency on the project too so for this project I'll stick to the current method.