MVC question

[Stephanie Stowe]

My collegues and I had a disagreement about what the "M" is. One (A)
described the M as the DATA model, corresponding to database tables in the
dbms. Another (B) and I have learned that it is the OBJECT model where the
data model is "just persistence." This impacts the role of the "C". A
beleives that "business processing" is the role of the controller. B and I
believe that the controller is simply responsible for traffic control
between the business processing, or object model, and the view. This
traffic control layer between the business and the view was the whole point
of struts as it was explained to me.

Who is right? If we cannot understand this simple thing about MVC as a team,
how on earth are we going to implement it properly?

THANKS!

S

 

[VisionSet]

My collegues and I had a disagreement about what the "M" is. One (A)
described the M as the DATA model, corresponding to database tables in the
dbms. Another (B) and I have learned that it is the OBJECT model where the
data model is "just persistence." This impacts the role of the "C". A
beleives that "business processing" is the role of the controller. B and I
believe that the controller is simply responsible for traffic control
between the business processing, or object model, and the view. This
traffic control layer between the business and the view was the whole point
of struts as it was explained to me.

Who is right? If we cannot understand this simple thing about MVC as a team,
how on earth are we going to implement it properly?

You & B are right on both counts.
The controller most certainly has nothing to do with 'business processing'.
The controller is a go between, between model & view it has references to
both view and model, probably typed as interface. It listens to events in
both model & view and makes calls on both in response.

 

[Oscar kind]

My collegues and I had a disagreement about what the "M" [in MVC] is.

[ Stance A: only the data; the controller does business logic.]
[ Stance B: data & business logic. ]

Although stance A is often implemented in real-life applications to some
extend, it is most certainly wrong: it makes for applications that become
extremely rigid and expensive in maintenance when they near completion.

Stance B (the correct one) ensures the modularity of the MVC pattern:
- the model contains all business logic
- the view contains all display logic
- the controller ties these things together

The controller should only contain boilerplate code, and may even be
implemented as a small set of classes that pass all commands of the user
to the model.

Also note that if the controller contains no significant logic, you can
use vanilla JUnit to do regression testing, while you only need to test
each page in the view only once (as a view contains no logic and thus
nearly no bugs).


kind regards,
Oscar

 

[Stephanie Stowe]

My collegues and I had a disagreement about what the "M" [in MVC] is.

[ Stance A: only the data; the controller does business logic.]
[ Stance B: data & business logic. ]

Although stance A is often implemented in real-life applications to some
extend, it is most certainly wrong: it makes for applications that become
extremely rigid and expensive in maintenance when they near completion.

Stance B (the correct one) ensures the modularity of the MVC pattern:
- the model contains all business logic
- the view contains all display logic
- the controller ties these things together

The controller should only contain boilerplate code, and may even be
implemented as a small set of classes that pass all commands of the user
to the model.

Collegue A has backed off the idea that the model is the data model. There
is such a one to one correspondence in this one app between the underlying
persistence and the objects in the model, that it made sense. There is still
some confusion about the role of the controller.

Here stems our confusion in discussion. I am going to give you a little info
about our app. We are creating an application, as in the ability to apply
for a loan. On one page, the user chooses to include a spouse's information.
The user is directed to a page to enter the spouse's information. OR the
user chooses not to include the spouse's information. Then the user is
directed to a different page.

The VIEW encompasses the 2 JSP pages which may accessed. The MODEL contains
the value object for Person, Spouse, Loan etc.. It is appropriate that the
CONTROLLER be aware of the different navigation paths that must be taken
given the choice in the request. As such, the contoller is responding to a
business rule in that it knows what to do for a spouse or no spouse.

Does this make sense? If not, no worries. I have only been charged with
classes that are definitely part of the Model up to this point. But I am
going to run over the apache and run through some of the tutorials so I am
not so ignorant. Perhaps it will become clear to me then.

Thanks for your help!

 

[Oscar kind]

[...] We are creating an application, as in the ability to apply
for a loan. On one page, the user chooses to include a spouse's information.
The user is directed to a page to enter the spouse's information. OR the
user chooses not to include the spouse's information. Then the user is
directed to a different page.

The VIEW encompasses the 2 JSP pages which may accessed. The MODEL contains
the value object for Person, Spouse, Loan etc.. It is appropriate that the
CONTROLLER be aware of the different navigation paths that must be taken
given the choice in the request. As such, the contoller is responding to a
business rule in that it knows what to do for a spouse or no spouse.

Does this make sense?

Yes, perfectly.

It occurred to me that I may have misrepresented the location of the
business logic a bit, given the way most people seem to understand it
(I'm also still learning).

Both the view and the controller cannot be unaware of the business logic:
- the view must know what information to request/represent and what
actions can be performed (so it can show a button for example).
- the controller must know how to validate the information and how to
navigate through the view (including login and errors).


kind regards,
Oscar