Introduction

I see a lot of questions around the internet like "can I do this?" or "is it ok if I...?"

You won't go to hell, if you call $this->validate() in a controller. :/ https://t.co/Vm3DazWdwR

— Laracasts (@laracasts) June 15, 2015

With the rise of the Laravel PHP Framework and the PHP language itself coming along in leaps and bounds, the PHP development community really has become reinvigorated. The language is getting more advanced, with new features, and the community is really doing more since groups like the PHP league and the PHP-FIG have become prominent.

Can I implement something like... ?

Of course you can - there is literally nothing stopping you except you. I feel this is invaluable for a new developer or a developer learning new skills to learn.

Programming can be overwhelming; there are many different ways to do things. Lots of people far smarter than me - with years of experience - have come up with some programming advice and best practices, but everything has its place.

Referring to the tweet above, you can see the following under Simple Controller Request Validation in the Laravel 5.1 Release Notes (emphasis added):

The Laravel 5 base controller now includes a ValidatesRequests trait. This trait provides a simple validate method to validate incoming requests. If FormRequests are a little too much for your application, check this out:

The framework is providing you the functionality to make your life easier. Will a controller method with a call to the validation service in it follow the single responsibility principle? No. But it will help you get up and running quickly.

If you're building a simple CRUD app, do you really need to extract validation to a form request or is it really going to be ok if you call he validate() method right there in your controller?

Who is maintaining the code you write?

If you're contributing to open source or working in a team, then you're probably going to have defined coding styles and patterns to follow to make sure anybody in the team can work in any part of the code. More often than not, however, the person going to be responsible for the code you write will be you.

This means writing code that you're comfortable with, understand, and can easily maintain. As you learn more and your skills get better, you'll naturally explore new ways of getting the results you want. Today you might call validate() directly in your controllers. In a few weeks, as your application grows, you might decide to refactor using form requests.

It is still you that decides when this is appropriate.

What about the "right way?"

For better or worse, there will always be a group of architectural purists that will say things like "your project is no good" or that it will be useless unless you follow a particular design pattern, or implement a certain architecture.

I don't agree with that way of thinking. What I do agree with, however, is using the tools and skills you have to the best of your ability. What matters most is what will help you or your team finish your project and -- most importantly -- release it.

Conclusion

It doesn't matter how you implement something, as long as you're satisfied with the code and it does what you expect it to do.

The kind of code you write to build your personal blog isn't going to scale well for an enterprise application; just remember, your blog isn't an enterprise application.

When you ask people for advice, the people you'll continue to seek advice from aren't those that push their ideas of getting things done on you.

The people that answer the question you ask, rather than telling you how should do something are the ones you'll get the most value from. From my experience, that type of person will share valuable knowledge with you and are generally the kind of people whom you can ask "is there a better way?" and get great advice from.