Some problems with Accessor Laravel

Tram Ho

Introduce

  • For Laravel framework users, the accessor and mutator are not too difficult to understand and sometimes used in practice. Even I myself use Accessor and Mutator in real projects. However, like most other modes and mechanisms. Accessor and Mutator will seem a bit magic to new or unfamiliar Laravel frameworks. Referring to “magic”, I recall the days I started programming with the “magic” of ruby ​​on rails. It is impossible to really understand how the inner mechanism “it” handles, I don’t understand why in some weird way “it” works, and the fact is that when there is an error, it is also impossible to do the job. debug to understand why it fails. For beginners like me back then, it was hard to understand because the word “magic” was repeated many times.
  • However, with increasing experience, or as it becomes more familiar, the concepts of accessor, mutator will be easier to understand, especially when they have actually used it. With laravel, the accessor and mutator are still in the document on the homepage, so through examples, explanations of the document, and actual usage, the acessor and mutator are no longer “magic” as before. However, taking a look around for a “problematic” article when using “accessor”, I found it interesting to decide to translate it. In this article, only the issue of “accessor” alone, mutator will be mentioned in another content.
  • The original article you can read here . This article I only translated according to the understanding from the original article. Nothing is sublime.

content

What is accessor?

  • On viblo, there are many articles about accessor and mutator in laravel. Because the accessor and mutator are bidirectional to retrieve / store data into the database, they are often written together. If you do not have any idea about accessor and mutator, you can refer to this article Laravel Accessor and Mutator
  • Understanding na accessor will pass a simple example as follows. A User has 2 fields last_name and first_name and I want to display the full_name of a user. Thus, if we do not use accessor on the .blade file we can use the following:

If using accessor, we need to perform on the user model as follows:

So on .blade we can use the following:

Accessor issues

Problem 1: What is this full_name field?

  • For new people, or those who are not familiar with Laravel, or have never used accessor (although they may have read it in the document but haven’t used it yet, they should forget it), the original thought is that this full_name field is a column in the user table in the database. This is an initial thought often thought of first. But when checking in the database, there is no such column in the database. They will not be able to quickly guess this code related to the accessor in the model. If an error occurs, they will probably take hours to figure out where the full_name field value is full_name retrieved. Because full_name will be interpreted as a “magic”, and sometimes, they can no longer find, and it is impossible to understand why having a user has the value of full_name . Even now, sometimes when reading code, if I can’t remember the accessor, I still have to debug every line to understand the logic and logic of the error code. With a big project, it’s difficult to understand the whole project, you will only be able to understand a part, and until an error occurs in the unknown part, the only way to fix the error is you. I have to debug each line to understand what this code is doing, why I write like that, and what the idea is. It is not possible to quickly detect “the most likely error” while you are unable to accurately grasp the flow of internal processing.

Problem 2: It is possible to hide the bug if the accessor handles too much logic.

  • This can occur in cases where the accessor has a large amount of logical processing, and that process itself has bugs that are difficult to detect.
  • When performing logic handling in the accessor, it is just as risky as other common logic processors, the more complex the logic, the more confusing it is, the higher the risk of having a bug. Writing logic in the accessor I do not encourage, however, in fact, to “convenience” or effortless, sometimes we aim to indiscriminate.
  • As mentioned above, finding error due to accessor has been a long time ago, the logical code in complex accessor will lead to reading comprehension will take much longer than what the creator The accessor might have expected it. It does not bring the “readable / readable” (readable) “of the code as expected but quite the opposite. Thus, when using the accessor, we need to consider this problem, should use only simple logic.

Problem 3: N + 1 query

  • This issue was not mentioned in the original article, however, this problem was actually encountered by me, and it was a quite painful one, so I decided to write more.
  • The problem is to add a status attribute whenever getting information of 1 $ user, which status information is taken from another table, via relationship. If no accessor is used, then we can use with when querying in the Eloquent query and then logic. However, sometimes junior has the thought, why not add status as an accessor, an attribute of each user, when taking out the user, it has the status already. That’s not wrong thinking, but in fact, it will cause n + 1 queries. At each time a $ user is retrieved, it will default to the query to get status information inserted each time the value of 1 $ user is returned. The number of queries will increase slightly depending on how to get the status and the complexity of getting the status . However, the number of queries in the database may increase sharply. This is also not easy to realize why there are so many queries increased during refactor, performance.

Solution

  • The solution is to use and only use the Getter method .
  • Instead of using the accessor as above and using {{$ user-> full_name}} , use {{$ user-> getFullName ()}} .
  • Using getter, you will understand that it is a method in the model, and more specifically it is “clickable” on IDEs such as phpStorm. (clicking on it will jump to the method settings), this will reduce the time to learn more.

Summary

  • When using accessor we need to pay attention to some tips as follows:
    • Only use accessor with simple logic
    • Do not query the accessor’s data to another table, because sooner or later it will cause performance issues.
    • Try to use the Getter method instead of accessor
Share the news now

Source : Viblo