26.Feb.2010 at 11:57 by Henrik Bjørnskov
Type comment...
Stefan Priebsch (26.Feb.2010)
Talk at PHP UK Conference 2010 (English - UK)
It ain't right, just because others do it. Identified by reviewing the code of various well-known open source PHP applications, this session presents the most extensively used antipatterns -counterproductive design patterns- in the PHP world. You will learn what is wrong with each example, and why. We will analyse alternative solutions and discuss their advantages and disadvantages.
Quicklink: https://joind.in/1450
By clicking this button you are declaring that you are the speaker responsible for it and a claim request will be sent to the administrator of the event.
If the claim is approved you will be able to edit the information for this talk.
Are you sure?
26.Feb.2010 at 12:05 by Richard George
Good talk, covering some of the more problematic antipatterns rather than just the classic simple ones. DI is no magic bullet though. Pretty decent speaker if not the energy of the first.
26.Feb.2010 at 12:11 by Paul Serby
Great talk. Bound to cause arguments, but people will soon see that the German knows his stuff.
26.Feb.2010 at 12:23 by Kathryn Reeve
Great talk. Good amount of humour and descriptions with a smidgeon of opinions.
26.Feb.2010 at 12:50 by Marc Gear
Enjoyed this talk, some good jokes, intelligent speaker, missing some solutions to the problems that he presented, but overall informative and well delivered.
26.Feb.2010 at 16:26 by Sebastian Marek
Very good talk, plenty of useful examples and good jokes. Still eager to know what to use if not MVC :)
26.Feb.2010 at 20:24 by Andy Thompson
I was wondering if the speaker recognised the difference between configuration constants (the worse of the two) and fixed value ones which are more fair. ZF has the latter in the form of enum class constants that I doubt many would consider bad practice.
Also ORM and AR aren't that bad, it's whether you tie your domain logic to them.
Most of the other points were spot on.
26.Feb.2010 at 22:33 by Peter Halasz
Very good talk. Was kinda expecting to see eZ publish up there in the list as well.
Thanks for the good pointers.
27.Feb.2010 at 08:29 by Stefan Priebsch
@proofek
There's nothing wrong with using MVC. Just don't assume that it's going to be your overall application architecture, and make sure you are using it right by keeping data access out of the controller and model. Sorry if I did not get that point across in my talk.
@andytson
I had mentioned that I find class constants not really problematic. I suggest to avoid global constants whenever possible, though.
27.Feb.2010 at 12:28 by John Billings
This was excellent - I am very pleased that I already use a lot of the concepts involved.
But I had a gap in my notes where I wanted to write where you put data access if *not* in the model - does this just mean having a DB abstraction layer rather than your data access commands directly in the model code? If not what?
27.Feb.2010 at 12:45 by Tom Jowitt
Really enjoyed this talk even though there was a certain amount of crossover with Fabien Potencier's session. It's always nice to have the reasoning behind anti patterns explained and the subsequent discussion.
Very funny too. Who says the Germans don't have a sense of humor?
27.Feb.2010 at 16:32 by Bill Hau
Some interesting thoughts about things to avoid and why, presented by a very witty and good speaker.
27.Feb.2010 at 19:43 by Antonios Pavlakis
That was very informative. There were some very interesting points made. Too bad you didn't get to finish the presentation...
27.Feb.2010 at 22:17 by Daniel André Eikeland
Very much enjoyed the talk. Points were made with well backed up arguments and some not-so-easy-to-get german humor. Agree with some others that the point about MVC and class constants didn't really make it through, maybe something to improve for later.
28.Feb.2010 at 00:00 by Liam Wiltshire
Good talk, raised some good points, although I agree again with the above points about the MVC and constants stuff - I get the point Stefan was trying to make, but could have done with being clarified a little better.
28.Feb.2010 at 10:50 by Stefan Priebsch
@webmartjohn
It doesn't matter whether you use an abstraction layer. You should try to keep DB access code out of your model. Put all code that accesses the DB into a separate object that the model calls, and that is injected into the model. That way you can test the model without any data storage, by passing in a mock object. You might want to have a look at the data mapper pattern, for example:
http://martinfowler.com/eaaCatalog/dataMapper.html
28.Feb.2010 at 16:31 by Matt Roberts
Great talk. Learned some useful tips, spotted some pitfalls that I know I've done, and agree with the vast majority of what was said. Shame about the lightbulb joke... :D
28.Feb.2010 at 18:01 by Russell Flynn
Enjoyed the talk, lots of interesting points. Agree with some of the comments above that maybe calling ORMs "bad" without elaborating may put newbies off when really the audience should be told to research and use ORMs properly when they fit a certain need. It is still possible to keep your database logic away from your model with ORMs (although I agree that they tend to overlap a lot by default), and Doctrine 2.0 basically leads you in exactly that direction.
I much prefer talks that say "avoid this and do this instead because..." rather than "never do this". I feel that approach makes people less defensive and more willing to research alternatives. - a mon avis :)
01.Mar.2010 at 14:09 by Alex Luneburg
A good talk with lots of interesting points that I need to look up further.
01.Mar.2010 at 14:32 by Andrew Collington
I quite enjoyed this talk. Whereas I don't think I agreed with everything the speaker was saying at the time, it gave me a lot to think about and nudged me in to a better way of structuring pieces of code that allow of easier testing under different conditions (allow for mock objects, for example, and not so tied to a db).
26.Feb.2010 at 11:57 by Dan Field
Very useful look at some common methodologies we all use every day.