<nospam@geniegate.com> wrote in message
news:kIjlc.14506$TD4.1862112@attbi_s01...[color=blue]
> Tony Marston <tony@nospam.demon.co.uk> wrote:[color=green]
> > For those who you thought my method of implementing OO principles in PHP[/color][/color]
was[color=blue][color=green]
> > totally wrong - see[/color][/color]
http://www.tonymarston.co.uk/php-mys...d-bad-oop.html[color=blue][color=green]
> > for details, you can now read
> >
http://www.tonymarston.co.uk/php-mys...ontroller.html and[/color][/color]
tell[color=blue][color=green]
> > me why my implementation of the MVC design pattern is totally wrong.
> >
> > Go on, I dare you. Make my day.[/color]
>
> I don't see how anyone could write using anything BUT MVC. (at least in
> some form) :-)[/color]
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.
[color=blue]
> 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[/color]
me[color=blue]
> a headache.[/color]
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 
