Laravel: De Aprendiz a Arteso (BrazilianPortuguese)Taylor Otwell and Pedro BorgesThis book is for sale at http://leanpub.com/laravel-pt-br

This version was published on 2013-10-01

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishingprocess. Lean Publishing is the act of publishing an in-progress ebook using lightweight toolsand many iterations to get reader feedback, pivot until you have the right book and buildtraction once you do.

2013 Taylor Otwell and Pedro Borges

Tweet This Book!Please help Taylor Otwell and Pedro Borges by spreading the word about this book on Twitter!The suggested tweet for this book is:Acabei de comprar o livro Laravel: De Aprendiz a Arteso por @taylorotwell.Find out what other people are saying about the book by clicking on this link to search for thishashtag on Twitter:https://twitter.com/search/#

Contedo

Injeo de Dependncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1O Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Construa um Contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Indo Alm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4No muito Java? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Injeo de DependnciaO ProblemaA fundao do framework Laravel seu poderoso container de inverso de controle (inversionof control ou IoC, em ingls). Para compreender o framework de verdade, necessrio terum bom entendimento sobre o funcionamento do container. Entretanto, ns devemos notarque o container IoC simplesmente um mecanismo conveniente para se alcanar o padro dedesenvolvimento de programas injeo de dependncia (dependency injection, em ingls). O usodo container no obrigatrio para se injetar dependncias, ele apenas facilita esta tarefa.Em primeiro lugar, vamos explorar porque a injeo de dependncia vantajosa. Considere aseguinte classe e mtodo:

1 class UserController extends BaseController {23 public function getIndex()4 {5 $users = User::all();67 return View::make('users.index', compact('users'));8 }910 }

Mesmo sendo um cdigo conciso, no podemos test-lo sem acessar um banco de dados. Emoutras palavras, o ORM Eloquent est fortemente acoplado ao nosso controlador. No podemos,de forma alguma, usar ou testar este controlador sem usar tambm todo o Eloquent, incluindo anecessidade de um banco de dados. Este cdigo tambm viola um princpio de desenvolvimentode programas conhecido como separao de conceitos (separation of concerns ou SoC, em ingls).Em outras palavras: nosso controlador sabe mais do que deveria. Controladores no precisamsaber de onde os dados vm, mas somente como acess-los. O controlador no precisa saber queos dados esto disponveis em MySQL, apenas que eles existem em algum lugar.

Separao de conceitosToda classe deve ter apenas uma responsabilidade e esta responsabilidade deve sercompletamente encapsulada pela classe.

Sendo assim, melhor desacoplar completamente nossa camada web (controlador) da nossacamada de acesso aos dados. Isso permitir migrar mais facilmente nossa implementao de

Injeo de Dependncia 2

armazenamento de dados e tornar o nosso cdigo mais fcil de ser testado. Pense na webapenas como uma camada de transporte para a sua aplicao real.Imagine que sua aplicao um monitor com portas para diversos cabos. Voc pode acessar asfuncionalidades do monitor via HDMI, VGA ou DVI. Pense na internet como sendo apenas umcabo conectado sua aplicao. O monitor funciona independente do cabo utilizado. O cabo apenas um meio de transporte, assim como HTTP um meio de transporte que leva suaaplicao. Assim sendo, ns no queremos entupir nosso meio de transporte (o controlador) coma parte lgica da aplicao. Isso permitir que qualquer camada de transporte, tais como umaAPI ou aplicao mvel, acessem a lgica da nossa aplicao.Por isso, ao invs de acoplar o controlador ao Eloquent, vamos injetar uma classe repositria.

Construa um ContratoEm primeiro lugar, vamos definir uma interface e uma implementao correspondente:

1 interface UserRepositoryInterface {23 public function all();45 }67 class DbUserRepository implements UserRepositoryInterface {89 public function all()10 {11 return User::all()->toArray();12 }1314 }

Injeo de Dependncia 3

Em seguida, vamos injetar uma implementao desta interface em nosso controlador:

1 class UserController extends BaseController {23 public function __construct(UserRepositoryInterface $users)4 {5 $this->users = $users;6 }78 public function getIndex()9 {10 $users = $this->users->all();1112 return View::make('users.index', compact('users'));13 }1415 }

Nosso controlador completamente ignorante quanto ao local onde os dados esto sendoarmazenados. Neste caso, esta ignorncia benfica! Os dados podem estar em um banco dedados MySQL, MongoDB ou Redis. Nosso controlador no reconhece a diferena, isso no sua responsabilidade. Fazendo essa pequena mudana, ns podemos testar nossa camadaweb separadamente da nossa camada de dados, alm de podermos facilmente alternar nossaimplementao de armazenamento de dados.

Respeite os limitesLembre-se de respeitar os limites da responsabilidade. Controladores e rotas servemcomo mediadores entre HTTP e sua aplicao. Ao escrever uma aplicao de grandeporte, no polua-os com lgica de domnio.

Para solidificar nossa compreenso, vamos escrever uma teste rpido. Em primeiro lugar, vamossimular (mock, em ingls) o repositrio vinculando-o ao container IoC da aplicao. Em seguida,nos certificaremos de que o controlador invoca o repositrio devidamente:

Injeo de Dependncia 4

1 public function testIndexActionBindsUsersFromRepository()2 {3 // Preparar...4 $repository = Mockery::mock('UserRepositoryInterface');5 $repository->shouldReceive('all')->once()->andReturn(array('foo'));6 App::instance('UserRepositoryInterface', $repository);78 // Agir...9 $response = $this->action('GET', 'UserController@getIndex');1011 // Conferir...12 $this->assertResponseOk();13 $this->assertViewHas('users', array('foo'));14 }

Faa de contaNeste exemplo, ns usamos uma biblioteca chamada Mockery. Esta biblioteca ofereceuma interface limpa e expressiva para fazer os mocks das suas classes. Mockery podeser facilmente instalado via Composer.

Indo AlmVamos considerar um outro exemplo para solidificar nossa compreenso. Suponha que nsqueremos notificar nossos clientes sobre as cobranas realizadas em suas contas. Para isso, vamosdefinir duas interfaces, ou contratos. Estes contratos nos daro flexibilidade para mudar suasimplementaes no futuro.

1 interface BillerInterface {2 public function bill(array $user, $amount);3 }45 interface BillingNotifierInterface {6 public function notify(array $user, $amount);7 }

Injeo de Dependncia 5

Continuando, vamos construir uma implementao do nosso contrato chamado BillerInterface:1 class StripeBiller implements BillerInterface {23 public function __construct(BillingNotifierInterface $notifier)4 {5 $this->notifier = $notifier;6 }78 public function bill(array $user, $amount)9 {10 // Cobrar o usurio via Stripe...1112 $this->notifier->notify($user, $amount);13 }1415 }

Porque separamos a responsabilidade de cada classe, agora ns podemos facilmente injetarvrias implementaes de notificao em nossa classe de cobrana. Por exemplo, ns poderamosinjetar um SmsNotifier ou um EmailNotifier. A cobrana no est mais preocupado com aimplementao da notificao, somente com o contrato. Enquanto uma classe estiver de acordocom o contrato (interface), a cobrana ir aceit-la. Alm do mais, ns no apenas adicionamosflexibilidade, mas tambm a possibilidade de testarmos a nossa cobrana separadamente dosnotificadores apenas injetando um mock BillingNotifierInterface.

Use interfacesEscrever interfaces pode parecer muito trabalho extra, mas na verdade, elas tornam oseu desenvolvimento mais rpido. Use interfaces para simular e testar todo o back-endda sua aplicao antes de escrever uma nica linha de implementao!

Ento, como ns podemos injetar uma dependncia? simples assim:1 $biller = new StripeBiller(new SmsNotifier);

Isso injeo de dependncia. Ao invs da cobrana se preocupar em notificar os usurios,ns simplesmente lhe passamos um notificador. Uma mudana simples como esta pode fazermaravilhas sua aplicao. Seu cdigo instantaneamente se torna mais fcil de manter, porque asresponsabilidades de cada classe foram claramente definidas. A testabilidade de suas aplicaesaumentar consideravelmente porque agora voc pode injetarmocks de dependncias para isolaro cdigo em teste.Mas, e quanto aos containers IoC? Eles no so necessrios na injeo de dependncia? Claroque no! Conforme veremos nos prximos captulos, containers tornam a injeo de dependnciamais fcil de gerenciar, mas o seu uso no obrigatrio. Seguindo os princpios deste captulo,voc j pode praticar injeo de dependncia em qualquer projeto, mesmo que voc ainda notenha um container sua disposio.

Injeo de Dependncia 6

No muito Java?Uma crtica muito comum do uso de interfaces em PHP que elas tornam o seu cdigo muitoparecido com o Java. Em outras palavras, o cdigo se torna muito verbal. Voc precisa definiruma interface e uma implementao; isso exigir algumas tecladas a mais.Para aplicaes simples e menores, esta crtica pode at ser vlida. Muitas vezes, as interfacesno so necessrias nestas aplicaes e perfeitamente ok no us-las. Se voc tem certeza quea implementao no mudar, voc no precisa criar uma interface.J para aplicaes maiores, as interfaces sero muito teis. As tecladas extras no sero nada emcomparao com a flexibilidade e testabilidade que voc ganhar. Poder mudar rapidamente aimplementao de uma contrato arrancar um uau do seu chefe, alm de permitir que vocescreva um cdigo que facilmente se adapta a mudanas.Para concluir, tenha em mente que este livro apresenta uma arquitetura muito pura. Caso vocprecise reduz-la para uma aplicao menor, no sinta-se culpado. Lembre-se, voc est tentandoprogramar com alegria. Se voc no gosta do que faz ou est programando por culpa, pare umpouco e faa uma reavaliao.

ndice analticoInjeo de DependnciaO ProblemaConstrua um ContratoIndo AlmNo muito Java?