Building Large Scale PHP Web Applications with Laravel 4


Published on

Learn how Laravel 4 can be leveraged to its fullest by making use of its powerful design patterns, specifically IoC Container and Dependency Injection.

Published in: Software, Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building Large Scale PHP Web Applications with Laravel 4

  1. 1. Building Large Scale Apps with Laravel 4 By Darwin Biler
  2. 2. What is a Large Scale App? A web application that has many features and complex functions, regularly updated to accomodate ever-changing business logic. Its usually used by many people concurrently and demands scalability and extensibility.
  3. 3. Challenges in Large Application  Hard to Maintain  Turns into spaghetti code  Prone to Security Issue  Hidden Bugs  Code collaboration experience is hell  Hard to test thoroughly
  4. 4. Hard to maintain A simple change in design requires learning backend codes, database and other non-frontend related things. This is usually caused by mixed html tags with PHP codes that performs database operations and other non front-end function. What makes it difficult is a simple change can cause another set of issues causing an infinite loop of bug fixing process.
  5. 5. Turns into spaghetti code With an application codes that is being modified often, specially being modified by multiple persons, its too common that different developers performs some quick and dirty methods of coding when the existing codes is un structured and nobody is enforcing a policy of the coding standards.
  6. 6. Prone to Security Issues Often times, quick and dirty codes leads to poor escaping of input, central data cleansing methods and secure way of exposing database data. This is the least valued process by most companies developing their own custom sofware thus making it susceptible to attacks.
  7. 7. Hidden Bugs 100% of QA tests the software in the frontend alone, which is completely wrong. Most of the bugs surfacing in the front-end is usually a problem in backend gone un noticed. In a very large codebase, inspection of the backend codes is more often not done.
  8. 8. Code Collaboration is hell Have you experienced getting your work overwritten by someone else? Even with Github, things could get awful if the application codes itself overlaps each other, making conflicts in the codes a common place.
  9. 9. Hard to test thoroughly When you have a complex application that links to many 3rd party API, calls various functions, handles many browser and user devices, if you do the all possible combination of those factors, you will figure out there is no way you can simulate all of those in a reasonable amount of time and interval.
  10. 10. How Laravel helps to avoid those issues Inversion Of Control ( IoC ) Namespacing Dependency Injection Repository Pattern Unit-Testing Modular SOLID Principle Facade
  11. 11. Inversion Of Control Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you" because its program logic is the reverse of abstractions such as callbacks.
  12. 12. Why "Inverted"? Its called like that because it reverses how many developers think of the way how a traditional applications were built
  13. 13. Traditional method Design > Database > logic Or Database > Logic > Design
  14. 14. Design > Database > Logic  A designer creates a layout in Photoshop  Frontend developer creates the html/css  Database tables will be created  PHP programmer will create the Controllers, Eloquent models etc  Layout and other features is coded by programmer
  15. 15. Database > Logic > Design  Database tables were created via ERD  Migration and Eloquent models were written to manipulate the data  Features and logic is applied  Design was made  Design is converted to HTML and Blade markup
  16. 16. IoC method Logic > Database > Design How is that possible if there is no database or layout yet?
  17. 17. Think of high level abstractions Entity - is any object in application that represents real world object, like Person, Car, Payment etc. Repository - is a place to save and retrieve Entities. Factory - is a thing that processes a raw data into an Entity
  18. 18. Entities  Many people knows it as Model in the MVC  Contains the data that is needed by the application  Should be passed to the Views and View Composers
  19. 19. Repository  A place to store Entities  Abstracts away the physical location of data  Contains the methods to get/retrieve data  Allows you to swap database or data source w/o affecting the rest of the application
  20. 20. Factory  Creates Entities  Makes sure Entities has valid data  Does the hard work of transforming raw data into Entity
  21. 21. Entity Example: interface EntityInterface { public function getID(); } class Member implements EntityInterface{ public $memberid; public $username; public $password; public $status; public $email; public $siteid; public function getID(){ return $this->memberid; } }
  22. 22. Repository Example: interface RepositoryInterface { public function get(Array $params); public function post(EntityInterface $e); public function put(EntityInterface $e); public function delete(EntityInterface $e); } class MySQLMemberRepository implements RepositoryInterface{ public function __construct(){ // Connect to database } public function get(Array $params){ // SELECT Queries in here // Use Eloquent, or any ORM } public function post(EntityInterface $member){ // SQL INSERT HERE } public function put(EntityInterface $member){ // SQL UPDATE HERE } public function delete(EntityInterface $member){ // SQL DELETE HERE } public function __destruct(){ //close connection } }
  23. 23. Factory Example: interface FactoryInterface { public function create(Array $params); } class MemberFactory implements FactoryInterface{ public function create(Array $data){ return new Member; } }
  24. 24. Namespacing Global use of variable in plain PHP script seems viable when the script is just short. But once its spans hundreds of lines you will ending up with many variable collisions. Causing unpredictable results. Namespaces allows you to organize your code so that your Entities, Factory and Repositories is not neatly organized
  25. 25. Example Namespaces: namespace VendorProjectNameEntitiesYourEntity; namespace VendorProjectNameFactoriesYourEntityFactory; namespace VendorProjectNameRepositoriesYourEntityRepository; This way, you can mix and match different Entities from multiple company, without worrying any conflict. For example, both Yahoo, Google and Microsoft needs a class for Member Entity var $m1 = new MicrosoftVisualStudioEntitiesMember; var $m2 = new GoogleDriveEntitiesMember; var $m3 = new YahooMailEntitiesMember;
  26. 26. That will be the first part of this Presentation Watch out for Part 2, which covers:  Dependency Injection  Repository Pattern  Unit-Testing  Modular  SOLID Principle  Facade Thank You! Darwin Biler