What is the proper way to use the Model in Laravel? - php

Can you help me with this? I am currently studying Laravel on my own and I followed the tutorials in the Laracasts and it is awesome. Before Laravel I am using CodeIgniter and Opencart in my projects and I started to study Laravel because I want to learn a new framework.
In CI and Opencart all your database queries are in the model. But in Laravel you can perform and queries in Controller?. Is it a proper way to the queries in Laravel?
I have this kind of code in the Controller:
<?php namespace App\Http\Controllers;
use App\Http\Requests;
use App\Http\Controllers\Controller;
use App\Article;
use Illuminate\Http\Request;
class ArticlesController extends Controller {
public function index() {
$articles = Article::all();
return view('articles.index')->with('articles', $articles);
}
}

Yes, this is perfectly fine for small applications.
For large-scale apps however, i'd recommend using repositories as they decouple your models from the controller - which makes them more readable and testable.
Your ArticlesController would translate to something like this:
<?php namespace App\Http\Controllers;
use App\Repositories\Articles\ArticleRepositoryInterface;
class ArticlesController extends Controller {
private $articles;
public function __construct(ArticleRepositoryInterface $articles)
{
$this->articles = $articles;
}
public function index()
{
return view('articles.index')
->with('articles', $this->articles->all());
}
}
Have a look at Laravels Service Container to understand the automatic resolution of the ArticleRepositoryInterface. Laracasts has some good videos on repositories.

Repositories is a smart decision to you. But why?
Basically, repositories is a 'gateway' between your application and your storage.
With repositories, you'll find your 'database queries' in a single place.
Let's think about the model Articles.
Instead of use a static instance of Articles all the times that you need to use it (Articles::find(), Articles::all(), etc), just create a repository of Articles.
Inject this repo in your controller (e.g.), and use 'features' storaged in your ArticleRepository.
What do you mean?
Let's consider a repository of Articles. What I'll use many times in my app of Articles model? I need select all, select by id, insert, update, delete. Basically these 'stuffs'. So, if I have all this stuffs in a place?
class ArticleRepository {
public function all(){}
public function getById($id){}
public function insert($data){}
public function update($data){}
public function delete($id){}
}
Inject this ArticleRepository in your controller. To do this, read a about IoC Container here: http://laravel.com/docs/5.0/container
The construct in your controller will be like this:
public function __construct(ArticleRepository $articles)
{
$this->articles = $articles;
}
Once all, when you need get all Articles in your controller, just do:
public function index()
{
$articles = $this->articles->all();
return View::make('articles.index')->with(['articles' => $articles]);
}
With this practice, you have a clean application with testables controllers and a beautiful organization and design. ;)
Look, I tried to be as didactic as possible to you understand the concept. The use of repositories is not only a way to do. So I let the links in the comments. And let other references here as well.
I'm sure you will understand quickly.
Success in learning! :)
https://laracasts.com/search?q=repositories&q-where=lessons
http://ryantablada.com/post/the-repository-pattern-in-action
http://culttt.com/2014/03/17/eloquent-tricks-better-repositories/
http://culttt.com/2013/07/15/how-to-structure-testable-controllers-in-laravel-4/

Related

Avoid Laravel facade on controller

I'm using Laravel 5.5 and trying to get used to code by psr-2 standard (just started learning). I analyze all my code with Quafoo QA and go step by step fixing the errors and record them.
By using facades i get this error "Avoid using static access to class". Because of it i'm trying to avoid using them.
On my controller i have this code:
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Events\FileLoaded;
use Illuminate\Support\Facades\Input;
use Illuminate\Auth\Middleware\Authenticate;
use PhpOffice\PhpSpreadsheet\Shared\StringHelper;
use \Illuminate\Contracts\View\Factory as ViewFactory;
class LoadDataController extends Controller
{
public function index()
{
$viewfactory = app(ViewFactory::class);
return $viewfactory->make('LoadData/index');
}
//more code
}
Besides the View Facade i also use DB, Input, Validator and Storage
Is this the correct way, are there others?
You don't need to avoid Facades - they are a key part of the framework. But if you want to, you can use dependency injection to include the classes you need as arguments in the controller methods:
class LoadDataController extends Controller
{
public function index(ViewFactory $viewFactory)
{
return $viewfactory->make('LoadData/index');
}
//more code
}
Or if you need that in all the controller methods:
class LoadDataController extends Controller
{
private $viewFactory;
public function __construct(ViewFactory $viewFactory)
{
$this->viewFactory = $viewFactory;
}
public function index()
{
return $this->viewFactory->make('LoadData/index');
}
//more code
}
Of course, this doesn't actually change the functionality of the code you've written, it just rearranges it. I wouldn't take the word of the code analyzer you mentioned as something you are doing wrong. These are standard patterns to use in Laravel.

Gateway and repository pattern PHP Laravel

I wanna ask about design pattern.
Why should I use dependency injection in constructor, not import it ('use statement')?
For example:
in my controller:
class AuthController extends Controller {
public function __construct(UserGateway $userGateway)
{
$this->userGateway = $userGateway;
}
public function doSomething()
{
$this->userGateway->foo();
}
}
Why don't use just like this instead?
use Acme\UserGateway;
class AuthController extends Controller {
public function doSomething()
{
UserGateway::foo();
}
}
Many thanks.
Assuming UserGateway is not laravel facade: here's the biggest advantage of injecting stuff this way: in the future, you might redefine what UserGateway actually is, and supply some other class (most often, it's subclass) instead of it like this:
$this->app->bind(UserGateway::class, function ($app) {
return new NewUserGateway();
});
This is extremely useful for overriding some parts of your code, especially if you're using same packages across multiple projects. And it does not require you to change the AuthController's code.
If UserGateway is a Facade, the only benefit you'll get is a better code navigation with you IDE, since it will know what class exactly are you referencing (assuming that you didn't re-bound it).

Laravel error interface class does not exist

I am very new to "Advanced Laravel" so to speak, however I do know most of the basics and I am trying to understand what namespacing, interfaces and repositories is all about, since I came across it not so long ago.
However, I am getting the following error, and I have no idea what I am doing wrong:
Class app\models\Interfaces\CategoriesInterface does not exist
Below is my code:
Routes.php
App::bind('App\Models\Interfaces\BaseInterface', 'App\Models\Repositories\BaseRepository');
CategoriesController.php
<?php
use app\models\Interfaces\CategoriesInterface;
class CategoriesController extends BaseController
{
protected $categories;
public function __construct(CategoriesInterface $categories)
{
$this->categories = $categories;
}
BaseInterface.php
<?php
interface BaseInterface
{
public function all();
}
CategoriesInterface.php
<?php namespace App\Models\Interfaces;
interface CategoriesInterface extends BaseInterface { }
CategoriesRepository.php
<?php namespace app\models\Repositories;
use App\Models\Interfaces\CategoriesInterface;
use Categories;
class CategoriesRepository implements CategoriesInterface
{
public function all()
{
$categories = $this->categories->all();
return $categories;
}
}
EloquentCategoriesRepository.php
<?php namespace app\models\Repositories;
use App\Models\Interfaces\CategoriesInterface;
class EloquentCategoriesRepository implements CategoriesInterface {
public function all()
{
return Categories::all();
}
Try name spacing the classes/interfaces properly. EloquentCategoriesRepository.php and CategoriesRepository are having app instead of App in the namespace. And CategoriesController too needs to use App\.. not app\...
I see you are trying to implement the repository pattern, which at first it might seem a bit 'advanced' but it's actually pretty simple.
So the basic idea is to abstract the data layer of your application with the database to make your transitions from one DBS to another(ex. Mysql to Mongo).
In other words your are trying to make the business logic of your application independent to the data layer (Where you query your collections/instances), so when you reach a point that you might want to change your database you can just implement another repository. The Interfaces are there to provide a contract between your application and the data layer.
Laravel implementation of the repository pattern it's pretty straight forward.
Create your interface
Create your interface's repository (actual implementation)
Bind the repository using a service provider class (Or in your case App::bind)
Instantiate the dependency in to your controller using the repository
Don't forget to auto load your namespaces using psr-04.
In your case I think the problem is you are not autoloading the namespace.
Also CategoriesRepository.php & EloquentCategoriesRepository.php are both Eloquent repositories and will return Eloquent collections. To return an array of stdClass (standar PDO) you will have to use the \DB facade.
If my answer does not cover you please take a look here

Laravel 4: How to correctly work with Models in Repositories

Read books From Apprentice To Artisan and Implementing Laravel by Chris Fidao and now i don't know how to correctly work with Models in Repositories.
In Implementing laravel book author is working with models in this way:
Example #1
<?php
use MyApp\Interfaces\UserInterface;
use Illuminate\Database\Eloquent\Model;
class UserRepository implements UserInterface
{
protected $user;
public function __construct(Model $user)
{
$this->user = $user;
}
public function find($userId)
{
return $this->user->find($userId);
}
}
But that can by done in other way, not injecting Model as a dependency, like this:
Example #2
Built example using tutorial http://culttt.com/2013/07/08/creating-flexible-controllers-in-laravel-4-using-repositories/
<?php
use MyApp\Interfaces\UserInterface;
use MyApp\Models\User\User;
class UserRepository implements UserInterface
{
public function find($userId)
{
return User::with('profile')->find($userId);
}
}
Why in first example Model is injected, why not use directly Model like in example two?
Which way is correct and why ?
Also which way will be more testable with integrated to laravel UnitTest package ?
The example 2 is bad because it's coupling your repository to a particular implementation of the User model.
Every time you use your repository it'll need to instantiate Univemba\Models\User\User. The whole idea of Dependency Injection is to inject (send) in to your object whatever dependencies it has. If your object needs a Model to work with you can send it a Laravel Eloquent Model, but any of your co-workers could also need to send to it a Doctrine Model. But if you couple your class to Eloquent, this isn't possible.
So in the first example, there is no instantiation happening on your code and it's not using a concrete class directly as in the second:
return User::with('profile')->find($userId);
It is receiving an implementation in the process of its instantiation:
public function __construct(Model $user)
{
$this->user = $user;
}
There are better ways to do that, because it is still expecting a concrete class while it should be expecting an implementation of an interface
public function __construct(ModelInterface $user)
{
$this->user = $user;
}
In this case you just need to pass to your object something that implements ModelInterface, which could be
Univemba\Models\EloquentModel
Or
Univemba\Models\DoctrineModel
Because both would be implementing
Univemba\Models\ModelInterface
I think if a Repository is intended to be the Eloquent implementation of a RepositoryInterface it isn't a bad idea to use the EloquentModel directly.

Laravel 4: Using views in a package

I've created a very basic app in Laravel 4, it's something I'll be reusing a lot in various projects so it made sense to convert it to a package before i got too far, but I'm struggling to make the changes to get it working, which I think is largely due to figuring out how to access the various objects that are normally available in an app, eg View::make
I had the following code working in an app:
class PageController extends BaseController {
public function showPage($id)
{
//do stuff
return View::make('page/showPage')
->with('id', $id)
->with('page', $page);
}
for the package I have the following:
use Illuminate\Routing\Controllers\Controller;
use Illuminate\Support\Facades\View;
class PageController extends Controller {
public function showPage($id)
{
//do stuff
return View::make('page/showPage')
->with('id', $id)
->with('page', $page);
}
However this does not load the blade template which is located at:
workbench/packagenamespace/package/src/views/page/showPage.blade.php
nor does this work:
return View::make('packagenamespace/package/src/page/showPage')
Also, I am wondering if what i have done with the use statements where I use the facade object correct, to me it seems like there should be a neater way to access things like the View object?
You should read the docs: http://four.laravel.com/docs/packages
Specifically the part explaining loading views from packages ;)
return View::make('package::view.name');
If you don' want to use:
use Illuminate\Support\Facades\View;
Just do:
use View;
Or even without the use statement:
\View::make('package::view.name');
// Serviceprovider.php
$this->loadViewsFrom(__DIR__.'/resources/views', 'laratour');
// Controller
<?php
namespace Mprince\Laratour\Controllers;
use Illuminate\Http\Request;
use Illuminate\Routing\Controller;
class LaratourController extends Controller
{
public function index()
{
return view('laratour::index');
// return view('packageName::bladeFile');
}
//END
}

Categories