Jump to content

Should you pass models directly to view - Laravel


Drongo_III
 Share

Go to solution Solved by maxxd,

Recommended Posts

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • Solution

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.