MVC vs Enterprise Pattern PHP

[eldan88]

Hey Guys. I am learning about the Enterprise pattern, and to me it seems like its the same as the MVC pattern (which I learned about)

Do they work the same??

 

For those who know Martin Fowler's Patterns of Enterprise Application Structure, that is what I am referring to as the enterprise pattern

Edited October 13, 2014 by eldan88

[Strider64]

From a book I read by Larry Ullman that MVC isn't really a true "pattern"  (He said it, I didn't so I don't want people coming down on me  ), so I guess the Enterprise Pattern could be MVC though I haven't gotten that far in another book that I'm reading about OOP. But I'm sure some guru here will answer this question better. 

[KevinM1]

There is no singular enterprise pattern. I mean, really, it says so right in the title of the book: Enterprise Patterns.

 

And, despite what Larry Ullman says, MVC is most definitely a pattern. It's a bit looser in the world of web development than application UI development, which is where it originated from, but, yes, it's a pattern.

 

The thing about patterns is that they're not mutually exclusive. It's not a matter of MVC OR something from Fowler's book. And, yes, patterns often have some overlap, or are otherwise similar in their execution. That's part of the point of patterns - they're generalized, and often can be used as the springboard to other patterns. They're also used in conjunction (MVC where the models are based on the Active Record pattern? What madness is this? ).

[eldan88]

KevinM1. Oh okay I see what you are saying. I was reading about  enterprise patterns in the book you actually recommeded me to read... (PHP Objetcs, Patterns, and Practice by Matt Zandstra) and the layout just looked very similar to your typical MVC structure..

[KevinM1]

Most books that talk about design patterns lift the format that was used in the original Gang of Four book, where they describe the problem, show the pattern that addresses it, and any related patterns and/or things to keep in mind. Regarding the code, what you're seeing are SOLID principles at work (look up what SOLID means in the context of OOP). The code will look similar because the separation of concerns and favoring composition over inheritance, among other things, are OOP staples.

 

So, combine the two, and you'll find that design pattern books are very samey. It doesn't mean that the patterns are necessarily the same or similar (although a lot of them do follow the same themes and build off one another), just that while you're learning about individual patterns you're actually also learning about how professionals attack problems in a larger, more meta sense.