Return to Answer

As the name suggests, a controller is the component that controls how a request is handled, what components do what tasks, and what response is sent back. That's its job. Querying the DB, processing raw resultsets and deleting data from certain tables is not part of a controllers' job description.

Interacting with the database is the job of the Model (note: capital M), as you can see here:

Laravel architecture

The routing component determines what controller should handle the request, the controller then pours the request data into model (note: lower case m) objects, initializes services and other components that belong to the Model layer, calls a couple of methods and passes the results to the View, which takes care of the end-user representation of the requested data.

That's how you write clean MVC code, regardless of the framework you use: Stick to the SOLID principles, the most important of all, IMHO, being the Single Responsibility principle: a class should have only one task. The controller should process the request. End of. Accessing the DB is beyond its responsibilities, it's that simple.

That's all nice in theory

Yes, I realize that Laravel's docs contain some code snippets where DB::table is used inside a controller. And it would seem that it's a rather common thing to do in the laravel community. But seeing as you're building an eCommerce application, you'll soon find yourself scrolling through endless action methods. All eCommerce platforms already out there offer some degree of modularity (some more than others), enabling/disabling certain components, the possibility to add custom components and what have you. If you start putting DB-related code in your controllers, you'll end up with something that is, by definition a lot less modular.

If it doesn't, then how can it be improved?

Even though, at this stage, it may seem tedious and silly, I'd strongly recommend you start working on a Model layer: create data models that can be extended (depending on the needs of the user), add services that perform certain queries, and make it so that these services are portable and can be configured as much as possible (using config, service container, middleware or whatever...).
The aim should be to end up with controller actions that are as small/elegant as possible. My rule of thumb is simple: If I have to scroll to read the full method (any method, not just controller actions), it's too big. If I can't see the docblock and the code of an action in a single screen, I'm doing something wrong.

After looking at your code, I suggest you create a Category model, and a Category service, and refactor your controller to look something like this:

public function index()
{
 $service = $this->getCategoryService();//<-- how you implement this is up to you
 return view(
 'admin.categories.index',
 $service->getCategories(true)//assume public function getCategories($withParant = false) returning an array
 );
}
public function edit($id)
{
 $model = new CategoryModel();
 //set the data the service needs to query
 $model->setName($id)
 ->setDisplay('Enabled');
 $service = $this->getCategoryService();
 return view(
 'admin.categories.edit',
 [
 'category' => $service->getCategory($model),
 'catList' => $service->getCategoryList($model),
 ]
 );
}

Do the same for the other actions, and you're there. A clean controller, and DB interactions in a service that can be used by other controllers, too (making the platform a hell of a lot more flexible, and yielding a codebase with a lot less copy-pasting of queries).

###Other comments:

When you Ask about your code matching the standards, it's important to note that there are standards (more like conventions) that you're recommended to follow. In case of Laravel, You can see what the coding style standards are here: PSR-0 and PSR-1, with 1 notable exception, you seem to be folling them:

Functions and control structures must use Allman style braces

Allman-style means your methods and if's are not written according to the Laravel standards:

public function destroy( $id, Request $request ) {
 $category = Category::findOrFail( $id );
 if ( $request->ajax() ) {
 $category->delete( $request->all() );
 return response(['msg' => 'Category has been successfully deleted.', 'status' => 'success']);
 }
 return response(['msg' => 'Failed deleting the category', 'status' => 'failed']);
}

Should be written like this:

public function destroy( $id, Request $request )
{//<--next line
 $category = Category::findOrFail( $id );
 if ( $request->ajax() )
 {//<--new line, too
 $category->delete( $request->all() );
 return response(['msg' => 'Category has been successfully deleted.', 'status' => 'success']);
 }
 return response(['msg' => 'Failed deleting the category', 'status' => 'failed']);
}

Lastly: I'm not a huge fan of compact, but that may be a personal thing. However, getting back to reusability and modularity: if you pass all local variables using compact to the view, you should be extremely careful: maintaining, debugging and refactoring your code is a potential minefield (rename a variable, and you're in trouble)... I'd strongly advise you to write the arrays manually. It's not that much work anyway...

lang-php