AntiPHPatterns

Comments

Comments are closed.

Very useful look at some common methodologies we all use every day.

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.

Great talk. Bound to cause arguments, but people will soon see that the German knows his stuff.

Great talk. Good amount of humour and descriptions with a smidgeon of opinions.

Enjoyed this talk, some good jokes, intelligent speaker, missing some solutions to the problems that he presented, but overall informative and well delivered.

Very good talk, plenty of useful examples and good jokes. Still eager to know what to use if not MVC :)

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.

Very good talk. Was kinda expecting to see eZ publish up there in the list as well.
Thanks for the good pointers.

@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.

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?

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?

Some interesting thoughts about things to avoid and why, presented by a very witty and good speaker.

That was very informative. There were some very interesting points made. Too bad you didn't get to finish the presentation...

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.

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.

@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

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

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 :)

I really enjoyed this, made me think a lot.

A good talk with lots of interesting points that I need to look up further.

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).

Is there a link to the slides?