The form is shaping up to become a vitally important piece of our Symfony2 and FosRestBundle API project implementation. The problem is, as we saw in the first POST video, we have put all our business logic inside our controller. How naughty.
If we continued on this path we would get ourselves into a bit of a pickle quite quickly. For a start off, as we will see in future videos, the form logic is not just used by POST, but by PUT and PATCH as well. We might as well make use of the logic over and over (keeping our code DRY) so as to ensure we only ever have one place to test and maintain, hopefully guaranteeing our system works as expected.
Another reason to get rid of the logic out of our controller is that it really shouldn't live there. Think of the controller as being the Chief Executive Officer of our API. He doesn't need to know exactly how a process is done, just that it gets done the right way every time. Therefore he delegates the responsibility to a worker who diligently completes the task and returns the result. The CEO then takes all the credit.
By the end of this video we will have the foundations of a well tested Form Handler implementation for our REST API which we can then use for our other verbs like PUT and PATCH.
If you have found this video helpful, please consider sharing. I really appreciate it.
|3||GET Handled, thin Controllers and fun with Services||17:49|
|4||Automatic Route Generation||11:32|
|5||GETting a Collection||12:53|
|7||Acceptance Testing our POST Method||05:40|
|8||Unit Testing our Symfony Form||22:55|
|9||Implementing and Testing the Form Handler||03:01|
|10||POST Form Handler Implementation||11:12|