Your SlideShare is downloading. ×
Building Large Scale PHP Web Applications with Laravel 4
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Building Large Scale PHP Web Applications with Laravel 4

7,554

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.

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
2 Comments
25 Likes
Statistics
Notes
No Downloads
Views
Total Views
7,554
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
2
Likes
25
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Building Large Scale Apps with Laravel 4 By Darwin Biler
  • 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. 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. 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. 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. 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. 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. 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. 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. How Laravel helps to avoid those issues Inversion Of Control ( IoC ) Namespacing Dependency Injection Repository Pattern Unit-Testing Modular SOLID Principle Facade
  • 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. Why "Inverted"? Its called like that because it reverses how many developers think of the way how a traditional applications were built
  • 13. Traditional method Design > Database > logic Or Database > Logic > Design
  • 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. 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. IoC method Logic > Database > Design How is that possible if there is no database or layout yet?
  • 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. 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. 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. Factory  Creates Entities  Makes sure Entities has valid data  Does the hard work of transforming raw data into Entity
  • 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. 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. Factory Example: interface FactoryInterface { public function create(Array $params); } class MemberFactory implements FactoryInterface{ public function create(Array $data){ return new Member; } }
  • 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. 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. 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

×