News Feed
Jobs Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

MaltBlue.com:
Are TableGateways Worth it in Zend Framework 2?
November 27, 2013 @ 11:34:28

On his MaltBlue.com blog Matthew Setter shares his opinion on TableGateways in Zend Framework v2 and wonders if they're "worth it" (as they're not the easiest thing to implement).

Are TableGateways too hard to implement in Zend Framework 2? Are they too hard to justify the effort? That's what I was asked recently during a Twitter conversation. For me, they're not. For me, they're well worth the effort. So I've written this post to show why they're not, and how they bring great flexibility, when implemented correctly. In [this post] I'll set out why they can be a good solution, as well as why not.

He starts from the origins of PHP scripts, back when they were "a collection of files" and not structured under much of a framework. Complexity added the need for this structure, though, including things like design patterns for common tasks. The TableGateway was one of these. He talks briefly about implementing them in Zend Framework v2 (with some gist examples) and some questions to ask helping you determine if they're "too much" for you app.

0 comments voice your opinion now!
tablegateway designpattern zendframework2 implement difficulty

Link: http://www.maltblue.com/patterns/why-tablegateways

NetTuts.com:
The Repository Design Pattern
November 26, 2013 @ 11:53:16

While design patterns are a wider topic than just PHP, the NetTuts.com site has posted a new tutorial looking at the Repository Pattern and uses PHP and PHPUnit to illustrate how the pattern works. They looks at the structure of the pattern at a high level and provide a more "real world" example too.

The Repository Design Pattern, defined by Eric Evens in his Domain Driven Design book, is one of the most useful and most widely applicable design patterns ever invented. Any application has to work with persistence and with some kind of list of items. These can be users, products, networks, disks, or whatever your application is about. If you have a blog for example, you have to deal with lists of blog posts and lists of comments. The problem that all of these list management logics have in common is how to connect business logic, factories and persistence.

They start with an overview of the pattern and some of the problems that it can help to solve. They also briefly mention the Gateway pattern that will be used in the examples to pull information into the Repository. After covering some of the basic concepts, they get into the code (going the TDD route) showing how to manage comments, like from a blog, inside a repository. It implements a "Comment" class, a persistence mechanism (the Gateway) and a Factory class that takes in the comment data and returns a correctly formatted object. Finally, they make the repository class and show how to add and retrieve comments from its internal data set.

0 comments voice your opinion now!
designpattern repository gateway factory persistence tutorial

Link: http://net.tutsplus.com/tutorials/php/the-repository-design-pattern/

David Adams:
Is ORM abstraction a pipe dream?
October 23, 2013 @ 09:59:21

David Adams has published a recent post that wonders if ORM abstraction is a "pipe dream" when it comes to abstraction. ORM stands for "object relational mapper" and is commonly used as a layer between the application and a dta source to work with the data as objects, not directly with it. He instead investigates replacing the ORM layer with multiple instances of repository pattern-structured code to abstract thing even more.

I was recently introduced to the repository pattern, a type of abstraction and organizational technique. The idea being, create a repository for each of your models to retrieve and persist to and from. A supposed benefit of the repository pattern is the ability to abstract your ORM and create different implementations for Eloquent, Doctrine, Propel, etc. This abstraction intrigued me. I set off to put this idea into practice and see what it took. Here are my findings.

He looks into how Doctrine handles its entities and tries to mimic some of the logic, including the calls to "save" and "flush". He also looks at how to handle a few other common ORM-ish topics like relationships, validation and observers. Unfortunately, he hit a wall with his solution and wasn't able to figure out a good Repository-based solution.

0 comments voice your opinion now!
repository designpattern proofofconcept orm object mapper doctrine entity

Link: http://programmingarehard.com/2013/10/21/is-orm-abstraction-a-pipe-dream.html

Brandon Savage:
The value of design patterns
October 21, 2013 @ 12:48:37

Brandon Savage has a new post today talking about the value of design patterns with his response to another post. He tries to put the emphasis back on making good OOP code instead of worrying too much about the actual design pattern.

Anthony [Ferrara] makes some great points in his article, and I highly encourage you to read it. But I want to address the perspective that he puts forward, which is that worrying about design patterns is less important than worrying about writing great object oriented code.

He relates design patterns to the sentence structures you learn when learning a new (spoken) language. He suggests that, while they're a good way for developers to communicate, they shouldn't be the only emphasis. When a developer becomes more fluent in a language, the patterns should become less important but are still a good structure for good development practices.

0 comments voice your opinion now!
oop designpattern value opinion fluent language

Link: http://www.brandonsavage.net/the-value-of-design-patterns/

Russell Walker:
Active Record vs Data Mapper for Persistence
October 18, 2013 @ 10:19:13

Russell Walker has a new post today comparing two popular methods for abstracting out database access and working with your data - the Active Record and Data Mapper patterns for data persistence.

These two design patterns are explained in Martin Fowler's book 'Patterns of Enterprise Application Architecture', and represent ways of handling data persistence in object oriented programming.

He gives simple code examples of both - one showing a basic "save" call with Active Record and the other showing the saving of a "Foo" entity using similar logic. Along with these examples, he also includes a few points about the major advantages and disadvantages related to the pattern. He also talks some about "service objects", the go-between that the data mapper pattern uses to combine business logic and the mapper object. He ends the post by making some suggestions about which to use, depending on the need of course.

0 comments voice your opinion now!
activerecord datamapper persistence database interface designpattern

Link: http://russellscottwalker.blogspot.co.uk/2013/10/active-record-vs-data-mapper.html

Brandon Savage:
The myth of the untestable controller
September 23, 2013 @ 11:35:04

In this new post to his site Brandon Savage looks at the "myth of the untestable controller" and gives some tips to help resolve it.

It's a persistent statement: controllers should have as little code as possible because they're difficult, nay impossible, to test. Developers should force most of their code into the models instead, where business, validation and other logic can take place. [...] But this is not true. Controllers are no more or less testable than any other kind of code. What's more, the fact that people believe controllers are largely untestable is an excuse for writing untestable code, not a valid design decision.

He talks briefly about where the myth might have come from (Zend Framework v1, with it's difficult to test controllers) and a note that, really, controllers are as testable as you want them to be. He give three things that could help make them easier to test:

  • Using dependency injection/inversion methods
  • Refactoring to use the Abstract Factory design pattern
  • Using anonymous functions/closures over plain configuration settings
0 comments voice your opinion now!
untestable unittest controller solutions abstractfactory designpattern

Link: http://www.brandonsavage.net/the-myth-of-the-untestable-controller/

Anthony Ferrara:
Beyond Design Patterns
September 19, 2013 @ 10:43:11

Anthony Ferrara has written up a new post that looks beyond design patterns. He suggests that more emphasis should be put on learning proper methods for abstraction and communication between objects and structures.

Many people teach design patterns as a fundamental step to Object Oriented Programming. They are so universally seen as important that almost every single conference that I have been to has had at least one talk about them. They are quite often used as interview questions to test a candidate's OOP knowledge. However, just like inheritance, they are not needed for OOP. And just like inheritance, they are a distraction rather than a foundation. Instead of focusing on patterns, I suggest focusing on learning about abstraction and communication.

He briefly covers the three types of patterns most people are introduced to - creational, structural and behavioral - and his suggestions of other patterns that answer more of the "what the problem is" question:

  • Shim patterns (Flyweight, Iterator, etc)
  • Compositional patterns (Adapter, Builder, Facade, etc)
  • Decompositional patterns (Bridge, Command, Mediator, etc)

He spends some time later in the post looking a bit more closely at four specific patterns, Adapter, Bridge, Facade and Proxy. He points out that they (essentially) do the same kind of thing and boils it down to a more refined set of implementation patterns and the problems they help solve.

0 comments voice your opinion now!
designpattern communication abstraction implementation problem

Link: http://blog.ircmaxell.com/2013/09/beyond-design-patterns.html

Inviqa techPortal:
PHP Test Doubles Patterns with Prophecy
July 23, 2013 @ 12:31:08

The Inviqa techPortal has a new post today from Marcello Duarte about using Prophecy in unit testing to work with mocks and doubles.

Test doubles are a way of replacing all classes in our tests other than the one we are testing. They give us control on direct and indirect outputs that would have been generated by those classes. Understanding the role of the test double helps us to write better tests, and thus better code. [...] When writing unit tests we are focusing on describing one unit of behaviour at a time, and how objects communicate in order to achieve that behaviour. We instantiate the object under test, call a method of the object and observe if the outcome is as expected.

In his examples he uses Prophecy to mock out different kinds of objects - a dummy object, a "fake" (with listeners for other object calls), a stub that mocks other internal method calls and a more familiar mock object. He also talks about two guidelines to follow when thinking about writing tests and code complexity - the Law of Demeter and "Don't Mock What You Don't Own." He gives an example of working around this last one by using the Adapter design pattern.

0 comments voice your opinion now!
prophecy unittest designpattern doubles mock stub dummy fake

Link: http://techportal.inviqa.com/2013/07/23/php-test-doubles-patterns-with-prophecy

PHPMaster.com:
Manage Complexity with the Facade Pattern
June 11, 2013 @ 11:54:25

On PHPMaster.com today a new tutorial has been posted about using the Facade design pattern to help reduce the complexity of your application. It can help interface between other pieces of code an make using them simpler (a "facade" on top of them).

Design patterns are built to standardize solutions for common problems faced in software development. [...] Facade is a design pattern used in almost every web application, but often without knowing. The term "design pattern" creates a mental image of something complex and difficult to understand. Even though this can be true sometimes, the Facade pattern is simple to implementation. Let's see what Facade is and what it does to help us write good code.

A simple example is given to help make the concept of a facade clearer - the process behind borrowing a book. As borrowing and returning a book could involve multiple library types, they use a facade to provide a common interface to all of them. With the concrete example in place, they then move on to the official definition of the pattern and two more "real world" examples: authentication against multiple social networks and working with WordPress meta functions.

0 comments voice your opinion now!
designpattern facade tutorial social network interface

Link: http://phpmaster.com/manage-complexity-with-the-facade-pattern

PHPMaster.com:
Practical Aspects of the Adapter Pattern
March 14, 2013 @ 09:08:02

On PHPMaster.com today there's a new post about using a design pattern in your application, specifically the usefulness of the Adapter pattern. This pattern makes it simpler to work with existing tools by providing a layer that allows unified access to the libraries from one interface.

Software development is improved every day by new concepts, methodologies, and high quality libraries and frameworks. But even with all these improvements, we cannot prevent change in software development. You may think that your system is designed perfectly to cater to all of its requirements, but there will always be a change request that ruins your perfect design. We have to be prepared for all possible changes as developers. The Adapter pattern is a design pattern which is commonly used to manage changes in development. Throughout this article we'll be looking at the usage and benefits of the patterns using real world applications.

He uses an illustration of email access via a mobile device and using it as an "interface" (via a SMS message) to the web to send an email. He then looks at a more practical code-based example, a set of adapters that let you subscribe/unsubscribe from various email services. He shows a wrong way to implement it as well as a good way - using it to work with Twitter to send tweets via a similar interface.

0 comments voice your opinion now!
designpattern adapter tutorial introduction email



Community Events











Don't see your event here?
Let us know!


symfony2 hack database podcast install performance release security hhvm series composer component framework unittest language package facebook opinion application introduction

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework