Posted by David Haynes on 11/19/16 11:46

stathis gotsis wrote:
> "David Haynes" <david.haynes2@sympatico.ca> wrote in message
> news:o9b5g.4106$lJ6.1001@fe69.usenetserver.com...
>
>> It is more concise but suffers from marrying the view to the business
>> logic. If you want to update the view, say for supporting cell phones or
>> separating web page creation from the business logic, then it is easier
>> under MVC than in a monolithic form.
>
> Yes, that is true. If that is the case, i assume the controller will
> redirect to the appropriate view suited to the client's equipment (or rather
> browser), am i right?

Whatever is appropriate. My controllers know about cell phones, PDAs and
browsers and will redirect to the correct form as needed.

>> Both work. Which is best for you depends upon your needs.
>>
>> One thing I like about MVC is that the controllers and view all follow
>> the same general format which makes understanding a new page easier.
>>
>> Controllers condition their environment, handle any POST/GET data, set
>> the SESSION and redirect.
>
> In your original post you implied that the controller can also contain
> insert/update (into database) actions. Should the controller redirect to
> another page that handles this stuff? It does not really matter in the
> situation i am involved in right now, but i want to stick to correct
> guidelines.

I don't do another redirect. I encapsulate the database access into a
set of classes (all based upon a master database access object). My
class is sort of like Hibernate in that it treats the database as a
reliable object store albeit without the overhead of serialization.

I have other classes to assist the business logic that present more
complex database views.

In my case, let's say I have a table called ACCOUNT. I will have an
object that subclasses the master database object and implements an
Account object. The instance may then be used to access a single row or
to provide a set of rows from the ACCOUNT table. Additionally, the
getter and setter routines are implemented as $foo = $account->login;
and $account->login = 'foo'; which is a lot easier than writing all
those getLogin() and setLogin() methods.

>
>> Views bring in any SESSION data, set up for internationalization and
>> paint the form.
>>
>> Obviously, you can combine the controller and view into one page. I find
>> that the resulting pages can get to be quite large (lines of code) and
>> complex (lots of business logic) which gets in the way on understanding
>> how the page is being defined (i.e. the HTML)
>
> What i did was combine some of the controller's logic into the the form's
> page. If alla data is valid the user gets redirected to another page which
> handles database actions. I did this because i found passing around data
> through the SESSION variable a bit clumsy. However, i can see the advantages
> of the MVC model you suggest. Thank you again for the detailed explanation.

It can be a pain to load and unload the SESSION but if you are playing
in multiple interfaces - as I am - it can really save you a lot of time.
Also, think of the data passing from the controllers and views as your
API definition. You have a very well defined set of data that the
controller will accept and a well defined set of data that the view will
accept. This can make data verification/validation a lot easier.

Good luck with your project.

-david-

[Back to original message]