Model View Controller - please clarify

Discussion in 'C++' started by hugo.elias@virgin.net, Jan 28, 2005.

  1. Guest

    Hi all,
    I hope nobody minds me posting this question to this group, but I
    couldn't find any group closer to the Subject.

    Can anyone clear up where you draw the lines when dividing up an
    application into Model, View and Controller parts?

    For example: I have some classes:

    class FlatWorld;
    class Shape;
    class BlobbyShape; // inherits from Shape
    class StringyShape; // inherits from Shape
    class GassyShape; // inherits from Shape


    And my application is split thus:

    Model:
    The Shapes. And Flatworld which contains a vector<Shape>

    View:
    Class which gets information from Flatworld, and renders the Shapes.

    Controller:
    Class which interprets mouse clicks/drags and tells the Shapes to
    move or change shape.


    The other important thing I have learned is to do things Once And Only
    Once (OAOO). The problem is that the MVC concept seems to break the
    OAOO principle, because two classes (perhaps written by two different
    people) need to know enough about the Shapes to be able to render them.
    For example the GassyShape is rendered in a totally different way to
    the StringyShape. Also, there are totally different methods for
    manipulating the Shapes.

    What happens when someone writes a new kind of Shape? The author of
    the View has to be contacted and taught how to read the information and
    render the shape, and he must edit his code. Ditto the Controller.

    Wouldn't it be better to integrate the Controller and View into the
    Model?

    For example:
    class Shape
    {
    virtual void Render(Surface *S);
    virtual void Click(Point P);
    virtual void Drag(Point P);
    virtual void Release(Point P);
    };

    Now, new Shapes can be written at any time, and they take care of
    themselves, simply being told when/where to render, and any mouse
    actions that come their way.


    I have Googled for this a lot, and read the C2 Wiki, but I still can't
    find a decent resolution to this. Can anyone offer any advice?
    Many thanks in advance.

    Hugo Elias
     
    , Jan 28, 2005
    #1
    1. Advertising

  2. wrote:
    > Hi all,
    > I hope nobody minds me posting this question to this group, but I
    > couldn't find any group closer to the Subject.
    >
    > Can anyone clear up where you draw the lines when dividing up an
    > application into Model, View and Controller parts?
    > [...]


    I actually consider news:comp.object to be closer in topic to this
    instead of any language newsgroup. But that's just MO.
     
    Victor Bazarov, Jan 28, 2005
    #2
    1. Advertising

  3. Rolf Magnus Guest

    wrote:

    > Hi all,
    > I hope nobody minds me posting this question to this group, but I
    > couldn't find any group closer to the Subject.


    comp.object would be my guess. It's more a gerneal problem of object
    oriented programming rather than specific to C++.

    > The other important thing I have learned is to do things Once And Only
    > Once (OAOO). The problem is that the MVC concept seems to break the
    > OAOO principle, because two classes (perhaps written by two different
    > people) need to know enough about the Shapes to be able to render them.
    > For example the GassyShape is rendered in a totally different way to
    > the StringyShape. Also, there are totally different methods for
    > manipulating the Shapes.
    >
    > What happens when someone writes a new kind of Shape? The author of
    > the View has to be contacted and taught how to read the information and
    > render the shape, and he must edit his code. Ditto the Controller.
    >
    > Wouldn't it be better to integrate the Controller and View into the
    > Model?


    I think you missed the whole point of the MVC concept. The idea is that you
    can vary the view and the controller independant of the model and even have
    multiple views at the same time fore one model. So you can have one view
    that shows you a graphical representation and another one that shows you a
    textual list of the object names and properties. Or just simply two
    graphical views of the same type, but each showing a different part of the
    model.
     
    Rolf Magnus, Jan 28, 2005
    #3
  4. Adios Guest

    Victor Bazarov wrote:

    > wrote:
    >> Hi all,
    >> I hope nobody minds me posting this question to this group, but I
    >> couldn't find any group closer to the Subject.
    >>
    >> Can anyone clear up where you draw the lines when dividing up an
    >> application into Model, View and Controller parts?
    >> [...]

    >
    > I actually consider news:comp.object to be closer in topic to this
    > instead of any language newsgroup. But that's just MO.


    Well there's a surprise, Dull Vic moans again...
     
    Adios, Jan 28, 2005
    #4
  5. Guest

    Re: Model View Controller - please clarify

    Yes, I do realise that that's one of the benefits of MVC, so, for
    example, I could print the shapes to paper, rather than rendering them
    to the screen.

    But even in this case, I think the same question applies. Surely, if
    the application is divided this way, then changes to the model have to
    affect the view and the controller also?

    Integrating the rendering code into the model still lets me have
    multiple views of the model at the same time. For example I could just
    tell my models to render themselves to different places:

    Shape.Render(dc1, RenderSettings1);
    Shape.Render(dc2, RenderSettings2);


    It seems to me that MVC depends how much is likely to change. If the
    model (code) changes often, and new Shapes appear and require different
    access functions, requiring constant updates to the view (code), then
    it hardly seems worth having separate M,V,C.

    But if you can have a totally consistent set of member functions for
    all the Shapes, then no changes are ever needed to the view, and the
    MVC concept does help.


    I can see both sides of the argument. Two sensible ways of dividing
    the application are pulling in different directions. Is there anyone
    who has encountered a problem like this, and can shed any light?

    Many thanks again, and sorry for the slightly OT posting. I'll aim
    for comp.object next time.

    Hugo Elias
     
    , Jan 28, 2005
    #5
  6. Howard Guest

    [somewhat OT] Re: Model View Controller - please clarify

    <> wrote in message
    news:...
    > Yes, I do realise that that's one of the benefits of MVC, so, for
    > example, I could print the shapes to paper, rather than rendering them
    > to the screen.
    >
    > But even in this case, I think the same question applies. Surely, if
    > the application is divided this way, then changes to the model have to
    > affect the view and the controller also?
    >
    > Integrating the rendering code into the model still lets me have
    > multiple views of the model at the same time. For example I could just
    > tell my models to render themselves to different places:
    >
    > Shape.Render(dc1, RenderSettings1);
    > Shape.Render(dc2, RenderSettings2);
    >
    >
    > It seems to me that MVC depends how much is likely to change. If the
    > model (code) changes often, and new Shapes appear and require different
    > access functions, requiring constant updates to the view (code), then
    > it hardly seems worth having separate M,V,C.
    >
    > But if you can have a totally consistent set of member functions for
    > all the Shapes, then no changes are ever needed to the view, and the
    > MVC concept does help.
    >
    >
    > I can see both sides of the argument. Two sensible ways of dividing
    > the application are pulling in different directions. Is there anyone
    > who has encountered a problem like this, and can shed any light?
    >
    > Many thanks again, and sorry for the slightly OT posting. I'll aim
    > for comp.object next time.
    >
    > Hugo Elias
    >


    I find that hard-and-fast rules tend to be so inflexible as to render them
    useless in many practical applications.

    I do a lot of work in both the Mac and Windows environment, and the handling
    of mouse events and keyboard entry and files are different between the two.
    But in both platforms, my mouse events and my drawing itself need to be
    handled by a class that's appropriate to the platform.

    For example, on Windows, I've got a window class that's handling all mouse
    events, and it passes on ones that are of interest to what I guess you'd
    call a controller class. That controller class uses a pointer to the window
    that called it (and the "device context" for that window) in order to place
    the graphical objects where I want them. I pass that "graphical context"
    information down to the individual graphical objects (shapes), and let them
    draw themselves. (I pass this info in a small class of my own design whose
    sole purpose is to hide the details of that graphical context information,
    making my interfaces consistent across platforms.)

    My "controller" class certainly knows about each of the types of objects
    that it might contain, although that's really only needed because it has to
    create them (and store them as a pointer to the base class type). My
    "view", or window class, doesn't know about the shapes at all; it only knows
    about the controller class. And my shapes simply use virtual functions to
    draw, copy, hide, move or whatever, using the "graphical context"
    information. (This same type of information is passed to different
    functions for streaming internal info, or for rendering to a "printer"
    context.

    Using this type of design, I can write a different view class to support
    each platform and different (but similar) shape classes to support each
    platform, and the controller really only needs minor adjustments to handle
    passing different types of handles or pointers to the view, based on what
    the platform requires (e.g., an HDC, HANDLE, WIndowPtr, etc.).

    -Howard
     
    Howard, Jan 28, 2005
    #6
  7. Vince Guest

    Re: [somewhat OT] Re: Model View Controller - please clarify

    Howard a écrit :
    > <> wrote in message
    > news:...
    >
    >>Yes, I do realise that that's one of the benefits of MVC, so, for
    >>example, I could print the shapes to paper, rather than rendering them
    >>to the screen.
    >>
    >>But even in this case, I think the same question applies. Surely, if
    >>the application is divided this way, then changes to the model have to
    >>affect the view and the controller also?
    >>
    >>Integrating the rendering code into the model still lets me have
    >>multiple views of the model at the same time. For example I could just
    >>tell my models to render themselves to different places:
    >>
    >>Shape.Render(dc1, RenderSettings1);
    >>Shape.Render(dc2, RenderSettings2);
    >>
    >>
    >>It seems to me that MVC depends how much is likely to change. If the
    >>model (code) changes often, and new Shapes appear and require different
    >>access functions, requiring constant updates to the view (code), then
    >>it hardly seems worth having separate M,V,C.
    >>
    >>But if you can have a totally consistent set of member functions for
    >>all the Shapes, then no changes are ever needed to the view, and the
    >>MVC concept does help.
    >>
    >>
    >>I can see both sides of the argument. Two sensible ways of dividing
    >>the application are pulling in different directions. Is there anyone
    >>who has encountered a problem like this, and can shed any light?
    >>
    >>Many thanks again, and sorry for the slightly OT posting. I'll aim
    >>for comp.object next time.
    >>
    >> Hugo Elias
    >>

    >
    >
    > I find that hard-and-fast rules tend to be so inflexible as to render them
    > useless in many practical applications.
    >
    > I do a lot of work in both the Mac and Windows environment, and the handling
    > of mouse events and keyboard entry and files are different between the two.
    > But in both platforms, my mouse events and my drawing itself need to be
    > handled by a class that's appropriate to the platform.
    >
    > For example, on Windows, I've got a window class that's handling all mouse
    > events, and it passes on ones that are of interest to what I guess you'd
    > call a controller class. That controller class uses a pointer to the window
    > that called it (and the "device context" for that window) in order to place
    > the graphical objects where I want them. I pass that "graphical context"
    > information down to the individual graphical objects (shapes), and let them
    > draw themselves. (I pass this info in a small class of my own design whose
    > sole purpose is to hide the details of that graphical context information,
    > making my interfaces consistent across platforms.)
    >
    > My "controller" class certainly knows about each of the types of objects
    > that it might contain, although that's really only needed because it has to
    > create them (and store them as a pointer to the base class type). My
    > "view", or window class, doesn't know about the shapes at all; it only knows
    > about the controller class. And my shapes simply use virtual functions to
    > draw, copy, hide, move or whatever, using the "graphical context"
    > information. (This same type of information is passed to different
    > functions for streaming internal info, or for rendering to a "printer"
    > context.
    >
    > Using this type of design, I can write a different view class to support
    > each platform and different (but similar) shape classes to support each
    > platform, and the controller really only needs minor adjustments to handle
    > passing different types of handles or pointers to the view, based on what
    > the platform requires (e.g., an HDC, HANDLE, WIndowPtr, etc.).
    >
    > -Howard
    >
    >
    >
    >

    www.wxwindows.org
     
    Vince, Jan 29, 2005
    #7
  8. wrote:
    > Hi all,
    > I hope nobody minds me posting this question to this group, but I
    > couldn't find any group closer to the Subject.
    >
    > Can anyone clear up where you draw the lines when dividing up an
    > application into Model, View and Controller parts?
    >
    > For example: I have some classes:
    >
    > class FlatWorld;
    > class Shape;
    > class BlobbyShape; // inherits from Shape
    > class StringyShape; // inherits from Shape
    > class GassyShape; // inherits from Shape
    >
    >
    > And my application is split thus:
    >
    > Model:
    > The Shapes. And Flatworld which contains a vector<Shape>
    >
    > View:
    > Class which gets information from Flatworld, and renders the Shapes.
    >
    > Controller:
    > Class which interprets mouse clicks/drags and tells the Shapes to
    > move or change shape.
    >
    >
    > The other important thing I have learned is to do things Once And Only
    > Once (OAOO). The problem is that the MVC concept seems to break the
    > OAOO principle, because two classes (perhaps written by two different
    > people) need to know enough about the Shapes to be able to render them.
    > For example the GassyShape is rendered in a totally different way to
    > the StringyShape. Also, there are totally different methods for
    > manipulating the Shapes.
    >
    > What happens when someone writes a new kind of Shape? The author of
    > the View has to be contacted and taught how to read the information and
    > render the shape, and he must edit his code. Ditto the Controller.
    >
    > Wouldn't it be better to integrate the Controller and View into the
    > Model?
    >
    > For example:
    > class Shape
    > {
    > virtual void Render(Surface *S);
    > virtual void Click(Point P);
    > virtual void Drag(Point P);
    > virtual void Release(Point P);
    > };
    >
    > Now, new Shapes can be written at any time, and they take care of
    > themselves, simply being told when/where to render, and any mouse
    > actions that come their way.
    >
    >
    > I have Googled for this a lot, and read the C2 Wiki, but I still can't
    > find a decent resolution to this. Can anyone offer any advice?
    > Many thanks in advance.
    >
    > Hugo Elias
    >


    I think you cannot find a decent solution, because you want to do a two
    way dispatching inheritance scheme. This is not impossible to do in C++,
    but you can do it numerous different ways - each with its own advantages
    and disadvantages.

    Maybe you would like to look at the different patterns that exist (e.g.
    in Gamma's pattern book). But I think the problem you are having is far
    too generic to propose a good solution...

    Good Luck,

    Tom
     
    Thomas Maier-Komor, Jan 31, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stan
    Replies:
    2
    Views:
    547
  2. Ralf Müller

    Model-View-Controller Pattern in ASP.NET

    Ralf Müller, Dec 28, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    938
    Ralf Müller
    Dec 29, 2004
  3. Griff
    Replies:
    4
    Views:
    658
    Griff
    Jan 26, 2006
  4. Fritz Bosch
    Replies:
    0
    Views:
    428
    Fritz Bosch
    Sep 15, 2004
  5. Replies:
    1
    Views:
    512
Loading...

Share This Page