Re: MVC Question

tailorma_de wrote:

Thank you both for your detailed explanations.

Ed,
I think it is still a little bit to sophisticated for me what you have
suggested. It is not clear for me what I can achieve with the interface
registration or why I should use this kind of abstraction. I'm not that
experienced yet.


Anyway, further (simple?) questions:

Consider those projects I have mentioned. Am I right that if I have
something like a ProjectView (with some text fields) that I must keep a
reference on the represented project object in the view?

Yes. Each view must be *given* a reference to the model and it should
keep it.

The model just "falls from the sky into the view's lap" as far as the
view is concerned.

Otherwise views would obviously have nothing to display or they would
have to know how to do all the model stuff themselves and that's a no
no.

Imagine a simple view to display numbers, would it know how to read
files, databases, XML? No that's all model work. The view can just say
model.getTheNumber()

Or an
'interfaced' object? So e.g. the view can call a method
projectObject.setName(String name). Sounds logically for me. Is it? But
otherwise I should imagine that I don't even have any UI. Where then do
I get the project instance from, if I want to set the project name?
Should I have something like this: Model.getProject(3).setName(String
name)?


1. At the *application* or some higher level create a model and views
then pass that model reference to the top level views. Don't use
statics.

2. The model can exist all by itself (without a UI) so it is able to
perform every necessary (model) operation.

3. there must be a way to handle inputs and events - the controller.
Once called they may well cause changes in the model.

To complete the cycle we also need a way to cause views to load
information but only when required. This is probably the juiciest bit,
more below.

Consider a user may create several projects. Think about the menu where
the user can see that three projects are currently in his workspace. Is
there (in the background) a list of projects in a variable within the
GUI that has to be maintained? Or is there always a call to the model
when the menu opens: Model.listProjects() or Model.listProjectNames() ?


Yes the model reference is ok, you should not do model.listProjects()
everytime the menu opens.

But how does this component know when to call model.listProject? Let's
say a new project was added.

The answer depends on your environment and architecture.

Classic MVC should be called MVCO, "O" for observer. At any rate the
Observer pattern between model and view *must* be understood. When the
model changes it notifies all views. Once notified views can fetch the
latest info at notification time.

Other environments might use listeners (Java). When something changes
the appropriate listener is triggered, it can then use its model
reference to fetch the latest.

Or controllers can propagate the change. They handle events and inputs
so they know exactly /when/ things happen, they have access to the
model and view so they can also ensure the view has the latest info.

In addition: Is it advisable to reduce references that reference
objects of the model in the UI? Okay, I guess this is advisable anyway.
But this is maybe critical for MVC.

So, maybe you see my confusion. Sometimes I keep references in my UI
objects, sometimes not.


I would expect all views to have and retain a reference as discussed
above.

And another question: I will use OpenGL in my program. Where do I have
to place that part? The calculations in particular. I would say this is
a view. However what happens there is very complex and has a lot of
code, so it should be placed in the model. Is it another MVC within my
'MVCed' application?


I'd put the OpenGL and GLUT stuff in its own view oriented package.

I'm not sure exactly what type of calcs you have in mind? But In
general ...

All graphics apps (games) I've worked with have had a separate math
package for matrix and vertices stuff.

The 3D graphics pipeline and view realm is no stranger to calcs. eg
view.applyMyFunkyTextureCalc() or view.applyBrightLights(10,20,10)

The model will have heaps of calcs too but different kinds it'll be
pure model structure and functionality related eg model.zoomBy(10) and
model.moveForward (150). No OpenGL or view stuff allowed.

You'll probably also need something inbetween the view and model (one
more level of indirection) this thing is allowed to know about about
OpenGL and your model guts eg blah.convertToDirectXFileFormat (myModel)


You may also have things like myModel=
ModelUtil.load3dStudioMaxFile("file.3ds")
....

OK you may not see much but again your model must be able to stand and
function fully without your UI.


Although there is no real need for me to change the UI of my program, I
think it is good practise to seperate the model from the UI. Or is
there an alternative to MVC?


Good question. Classic MVC has been a source of great confusion to many
people since its inception and it doesn't always map easily to all
environments.

There are many alternatives and especially variations.

All variations revolve around keeping the model and view separate but
they often do simpler things with the controller and or do away with
the observer pattern entirely.

Games (or at least ones I've worked with) separate the model, view and
controller but no observer.

Microsoft talk about "Document/View" which just separates the model and
view, the controller is stuffed into views. Sun do similar things with
Java's "delegates" and "listeners".

Web apps often do the opposite they elevate the controller to
application glory and use it to tie everything else together - more
like Model-View-Presenter (MVP).

Thank you,
Robert

Sorry this reply was long, I guess it's a big topic and there are so
many variations...

Hope that helps,
Cheers.

.

Relevant Pages

  • Re: Refactoring toward MVC
    ... > therefore didn't separate the controller aspects out of this object. ... > toward MVC? ... Find groups of event handler methods and extract one or more controller ... MVC should only be used in tookits like Swing. ...
    (comp.object)
  • Re: How does MVC relate to Swing Components and Swing Model?
    ... controller is actually a ROLE that objects can play in your system. ... I advise everybody to think of MVC as a design pattern, and, as whith ... such as "the view must be kept separate from the ...
    (comp.lang.java.gui)
  • Re: Question on MVC in .NET
    ... -> 1 - do we required to have a sepearate controller for each view. ... MainController and SaveController or we should have only one ... -> object reference of Main view, how other view can be handled. ... I recommend you to read article about MVC and MVP patterns: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: GUI in C#
    ... decouple "event-driven programming" from the MVC concept. ... > the controller code sits in the U/I layer, ... even though the pattern is described that way. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A few questions regarding MVC
    ... circa 1970 version or some modern variation? ... Using the classic MVC archticture as a guide to understanding modern ... controller can take the appropriate actions. ... views are observers <- model ...
    (comp.object)
Loading