By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,495 Members | 1,321 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,495 IT Pros & Developers. It's quick & easy.

An implementation of the Model-View-Controller pattern in PHP

P: n/a
For those who you thought my method of implementing OO principles in PHP was
totally wrong - see http://www.tonymarston.co.uk/php-mys...d-bad-oop.html
for details, you can now read
http://www.tonymarston.co.uk/php-mys...ontroller.html and tell
me why my implementation of the MVC design pattern is totally wrong.

Go on, I dare you. Make my day.

--
Tony (a legend in his own lunchtime) Marston

http://www.tonymarston.net

Jul 17 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Tony Marston <to**@nospam.demon.co.uk> wrote:
For those who you thought my method of implementing OO principles in PHP was
totally wrong - see http://www.tonymarston.co.uk/php-mys...d-bad-oop.html
for details, you can now read
http://www.tonymarston.co.uk/php-mys...ontroller.html and tell
me why my implementation of the MVC design pattern is totally wrong.

Go on, I dare you. Make my day.


I don't see how anyone could write using anything BUT MVC. (at least in
some form) :-) I was using it before I knew the term for it, (except my
notion of a "view" in those days was kind of strange) Even in assembler
you'll sometimes see something akin to MVC, where you have a dispatch
table of addresses and a code jump to one of those entries via some
action. (User presses 'q') Variant of:

;; "controller". :-)
; dispatch is a table of proc entries.
; user presses a key.
code = dispatch[key]
jmp code
....

I like to use form variables as the trigger, but most folks perfer using
the actual URL) Once in awhile, it's nice if the model can send data
directly to the client, but generally I'll try to make a more
complicated "view" for those cases)

I don't like the model being an entire class. I kinda like them to be
methods within a "Controller" class, which perhaps uses other classes if
it's complex, but not if it's not required. These "model methods" don't
talk to a database, they use other modules for that, but, to keep it
simple (such as "this action simply checks a few form variables and
responds with a valid or invalid view") An entire class can kind of give me
a headache.

Does PHP have an AUTOLOAD some place the way Perl does? Thats how I used
to do "MVC" in perl. :-)

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

Jul 17 '05 #2

P: n/a

<no****@geniegate.com> wrote in message
news:kIjlc.14506$TD4.1862112@attbi_s01...
Tony Marston <to**@nospam.demon.co.uk> wrote:
For those who you thought my method of implementing OO principles in PHP was totally wrong - see http://www.tonymarston.co.uk/php-mys...d-bad-oop.html for details, you can now read
http://www.tonymarston.co.uk/php-mys...ontroller.html and tell me why my implementation of the MVC design pattern is totally wrong.

Go on, I dare you. Make my day.
I don't see how anyone could write using anything BUT MVC. (at least in
some form) :-)


Then that immediately shows a lack of experience. In the MVC pattern the
presentation layer is split into two - a view and a controller - whereas in
other implementations thay can be a single component.

My design is a mixture of MVC and the 3 tier architecture. This has separate
components for the presentation layer (user interface), the business layer
and the data access layer. If your business logic and data access logic
exist in a single component then you have a 2 tier architecture. If your
presentation logic, business logic and data access logic exist in a single
component then you have a 1 tier architecture.

The "traditional" way of developing web pages with PHP is to have a single
component which generates HTML, contains all business logic and accesses the
database. This is therefore single tier.
I was using it before I knew the term for it, (except my
notion of a "view" in those days was kind of strange) Even in assembler
you'll sometimes see something akin to MVC, where you have a dispatch
table of addresses and a code jump to one of those entries via some
action. (User presses 'q') Variant of:

;; "controller". :-)
; dispatch is a table of proc entries.
; user presses a key.
code = dispatch[key]
jmp code
...

I like to use form variables as the trigger, but most folks perfer using
the actual URL) Once in awhile, it's nice if the model can send data
directly to the client, but generally I'll try to make a more
complicated "view" for those cases)

I don't like the model being an entire class. I kinda like them to be
methods within a "Controller" class, which perhaps uses other classes if
it's complex, but not if it's not required. These "model methods" don't
talk to a database, they use other modules for that, but, to keep it
simple (such as "this action simply checks a few form variables and
responds with a valid or invalid view") An entire class can kind of give me a headache.


I have a separate class for each business entity, so what is wrong with
that? On top of that the generation of SQL statements has been hived off to
its own DML class. I do not like the idea of having too many classes as it
takes more time to instantiate those clases. I once worked on a system that
was comprised of multiple components such as you suggest, and it was a
technical disaster. I produced my own version with fewer components and it
reduced development times by 85%.

--
Tony Marston
http://www.tonymarston.net

Jul 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.