Loading ...
Sorry, an error occurred while loading the content.

The M is MVC or MVP _IS_ or _IS NOT_ a Domain Model Object

Expand Messages
  • agilista
    Bouncing out of the inappropriate hijacking of the Overuse and Resulting Backlash thread.. I was referring primarily to MVP, and specifically Passive-View:
    Message 1 of 23 , Dec 14, 2008
    View Source
    • 0 Attachment
      Bouncing out of the inappropriate hijacking of the "Overuse and
      Resulting Backlash" thread..

      I was referring primarily to MVP, and specifically Passive-View:
      http://martinfowler.com/eaaDev/PassiveScreen.html

      In every application instance, the M in MVP (or MVC) IS the M in
      Domain Model. In system software instances, the M might be a button,
      etc, and in that case, the Domain is GUI and a fairly restricted usage
      IMHO -- unless you are developing UI software.

      After many years of object-oriented analysis, design and programming,
      pattern aware development and more recently, DDD, I find the simplest
      patterns are the most effective and useful.

      I understand and used to revel in complexity; now I eschew it.

      "Do the simplest thing that could possibly work" is a mantra I live
      by, and to me, Vibhu's description of Smalltalk's MVC, and Ralph
      Johnson's discussion on C2.com illustrate exactly why I favour
      MVP/Passive-View instead.
    • Jimmy Bogard
      I heavily prefer IS NOT , as I don t want UI concerns leaking down into my domain layer. Form model objects, DTOs, or whatever you want to call them, often
      Message 2 of 23 , Dec 14, 2008
      View Source
      • 0 Attachment
        I heavily prefer "IS NOT", as I don't want UI concerns leaking down into my domain layer.  Form model objects, DTOs, or whatever you want to call them, often have to look a very certain way to jive with the MVC/P framework they reside in.  Also, many MVC frameworks have rich validation functionality, that you wouldn't want bleeding down into your domain object.  Personally, I like the messaging paradigm - using services to update entities, where the UI constructs a message and passes it down.  Something like "IUpdateCustomerAddress" message.  Sometimes, the MVC Model will actually implement the message interface.

        When the entity exposes an operation to change its state, as opposed to being changed by the UI itself, you can have far greater control over the entity's invariants.  Often, a screen will only look at a slice or projection of an entity, not its entire set of attributes.  I let the UI dictate the model object, rather than mold the domain object around what I see in the screen.  There are influences back and forth, but only in the design and modeling, not in the implementation details of MVC frameworks.

        HTH,

        Jimmy


        On Sun, Dec 14, 2008 at 9:04 PM, agilista <jdharley@...> wrote:

        Bouncing out of the inappropriate hijacking of the "Overuse and
        Resulting Backlash" thread..

        I was referring primarily to MVP, and specifically Passive-View:
        http://martinfowler.com/eaaDev/PassiveScreen.html

        In every application instance, the M in MVP (or MVC) IS the M in
        Domain Model. In system software instances, the M might be a button,
        etc, and in that case, the Domain is GUI and a fairly restricted usage
        IMHO -- unless you are developing UI software.

        After many years of object-oriented analysis, design and programming,
        pattern aware development and more recently, DDD, I find the simplest
        patterns are the most effective and useful.

        I understand and used to revel in complexity; now I eschew it.

        "Do the simplest thing that could possibly work" is a mantra I live
        by, and to me, Vibhu's description of Smalltalk's MVC, and Ralph
        Johnson's discussion on C2.com illustrate exactly why I favour
        MVP/Passive-View instead.


      • Kurt Häusler
        I think IS is definitely right, but IS_NOT may be right too depending on whether you are looking at a control or an entire application, and also depending on
        Message 3 of 23 , Dec 15, 2008
        View Source
        • 0 Attachment
          I think IS is definitely right, but IS_NOT may be right too depending
          on whether you are looking at a control or an entire application, and
          also depending on which implementation is being used. It is probably
          not the purist approach, but a lot of the times I have played around
          with MVC and MVP, the V and the C or P were concerned with the GUI,
          while the M was the domain model totally isolated from gui concerns.

          I have been looking around for references defining M as part of the
          presentation layer, concerned with the GUI, separate from the domain
          model, and haven't really found anything yet.

          I did find on Martin Fowler's site:

          "In MVC, the domain element is referred to as the model. Model objects
          are completely ignorant of the UI."

          That's from http://www.martinfowler.com/eaaDev/uiArchs.html and he
          goes on to write further comments that lend me towards the IS side of
          things.

          If the M is in fact a gui concern separate to the domain model, what
          role does it have?
        • Casey Charlton
          It depends on whether you consider MVC a UI pattern (where the M is a layer that communicates with the real application), or you consider MVC an
          Message 4 of 23 , Dec 15, 2008
          View Source
          • 0 Attachment
            It depends on whether you consider MVC a UI pattern (where the M is a layer that communicates with the "real" application), or you consider MVC an architectural pattern where the M is everything behind the UI, back to the persistence layer.
             
            I tend to see MVC as an archiectural pattern in this respect, and see the C and V as part of the UI, and the M is everything else.

            2008/12/15 Kurt Häusler <kurt.haeusler@...>

            I think IS is definitely right, but IS_NOT may be right too depending
            on whether you are looking at a control or an entire application, and
            also depending on which implementation is being used. It is probably
            not the purist approach, but a lot of the times I have played around
            with MVC and MVP, the V and the C or P were concerned with the GUI,
            while the M was the domain model totally isolated from gui concerns.

            I have been looking around for references defining M as part of the
            presentation layer, concerned with the GUI, separate from the domain
            model, and haven't really found anything yet.

            I did find on Martin Fowler's site:

            "In MVC, the domain element is referred to as the model. Model objects
            are completely ignorant of the UI."

            That's from http://www.martinfowler.com/eaaDev/uiArchs.html and he
            goes on to write further comments that lend me towards the IS side of
            things.

            If the M is in fact a gui concern separate to the domain model, what
            role does it have?


          • arturtv
            Hi, From my point of view is that MVC is very old pattern and what is for sure is that the pattern has had its evolution in time depending on demands and
            Message 5 of 23 , Dec 15, 2008
            View Source
            • 0 Attachment
              Hi,
              From my point of view is that MVC is very "old" pattern and what
              is for sure is that the pattern has had its evolution in time depending
              on demands and technology growth, so the triad remains the same and the
              main meaning too BUT there were a lot of interpretations of the specific
              roles for each letter (MVC). That leaded to lots of uncertainness for
              the pattern and its derivates.

              So from my point of view the pattern doesn't say (and shouldn't)
              what the M is exactly, and in different architectures the M has its own
              specific role. (Fully Domain Model from DDD point of view, Anemic Domain
              Model + Services, DTO etc…)



              Artur Trosin,


              --- In domaindrivendesign@yahoogroups.com, "agilista" <jdharley@...>
              wrote:
              >
              > Bouncing out of the inappropriate hijacking of the "Overuse and
              > Resulting Backlash" thread..
              >
              > I was referring primarily to MVP, and specifically Passive-View:
              > http://martinfowler.com/eaaDev/PassiveScreen.html
              >
              > In every application instance, the M in MVP (or MVC) IS the M in
              > Domain Model. In system software instances, the M might be a button,
              > etc, and in that case, the Domain is GUI and a fairly restricted usage
              > IMHO -- unless you are developing UI software.
              >
              > After many years of object-oriented analysis, design and programming,
              > pattern aware development and more recently, DDD, I find the simplest
              > patterns are the most effective and useful.
              >
              > I understand and used to revel in complexity; now I eschew it.
              >
              > "Do the simplest thing that could possibly work" is a mantra I live
              > by, and to me, Vibhu's description of Smalltalk's MVC, and Ralph
              > Johnson's discussion on C2.com illustrate exactly why I favour
              > MVP/Passive-View instead.
              >
            • rishikesh parkhe
              Design of a system using a modelling approach will result into many small models. If there is a user interface in consideration, the design will most likely
              Message 6 of 23 , Dec 15, 2008
              View Source
              • 0 Attachment
                Design of a system using a modelling approach will result into many small models. If there is a user interface in consideration, the design will most likely render a model which will be a model from the domain (and like Artur said it can be a mixture of things). There can be bits and pieces for housekeeping which may not be part of the model.



                --- On Mon, 15/12/08, arturtv <arturtv@...> wrote:
                From: arturtv <arturtv@...>
                Subject: [domaindrivendesign] Re: The M is MVC or MVP _IS_ or _IS NOT_ a Domain Model Object
                To: domaindrivendesign@yahoogroups.com
                Date: Monday, 15 December, 2008, 2:03 PM

                Hi,
                From my point of view is that MVC is very "old" pattern and what
                is for sure is that the pattern has had its evolution in time depending
                on demands and technology growth, so the triad remains the same and the
                main meaning too BUT there were a lot of interpretations of the specific
                roles for each letter (MVC). That leaded to lots of uncertainness for
                the pattern and its derivates.

                So from my point of view the pattern doesn't say (and shouldn't)
                what the M is exactly, and in different architectures the M has its own
                specific role. (Fully Domain Model from DDD point of view, Anemic Domain
                Model + Services, DTO etc…)

                Artur Trosin,

                --- In domaindrivendesign@ yahoogroups. com, "agilista" <jdharley@.. .>
                wrote:
                >
                > Bouncing out of the inappropriate hijacking of the "Overuse and
                > Resulting Backlash" thread..
                >
                > I was referring primarily to MVP, and specifically Passive-View:
                > http://martinfowler .com/eaaDev/ PassiveScreen. html
                >
                > In every application instance, the M in MVP (or MVC) IS the M in
                > Domain Model. In system software instances, the M might be a button,
                > etc, and in that case, the Domain is GUI and a fairly restricted usage
                > IMHO -- unless you are developing UI software.
                >
                > After many years of object-oriented analysis, design and programming,
                > pattern aware development and more recently, DDD, I find the simplest
                > patterns are the most effective and useful.
                >
                > I understand and used to revel in complexity; now I eschew it.
                >
                > "Do the simplest thing that could possibly work" is a mantra I live
                > by, and to me, Vibhu's description of Smalltalk's MVC, and Ralph
                > Johnson's discussion on C2.com illustrate exactly why I favour
                > MVP/Passive- View instead.
                >


              • Colin Jack
                ... usage ... Don t agree on this, its a model but not necessarily just the domain model.
                Message 7 of 23 , Dec 15, 2008
                View Source
                • 0 Attachment
                  > In every application instance, the M in MVP (or MVC) IS the M in
                  > Domain Model. In system software instances, the M might be a button,
                  > etc, and in that case, the Domain is GUI and a fairly restricted
                  usage
                  > IMHO -- unless you are developing UI software.

                  Don't agree on this, its a model but not necessarily just the domain
                  model.
                • Colin Jack
                  ... Presentation model is one approach: http://martinfowler.com/eaaDev/PresentationModel.html
                  Message 8 of 23 , Dec 15, 2008
                  View Source
                  • 0 Attachment
                    > I have been looking around for references defining M as part of the
                    > presentation layer, concerned with the GUI, separate from the domain
                    > model, and haven't really found anything yet.

                    Presentation model is one approach:

                    http://martinfowler.com/eaaDev/PresentationModel.html
                  • Colin Jack
                    ... To me thinking of M as everything behind the GUI is a good approach, however saying that the M *is* the domain model is very different and to me less
                    Message 9 of 23 , Dec 15, 2008
                    View Source
                    • 0 Attachment
                      > It depends on whether you consider MVC a UI pattern (where the M is a
                      > layer that communicates with the "real" application), or you consider
                      > MVC an architectural pattern where the M is everything behind the UI,
                      > back to the persistence layer.

                      To me thinking of M as everything behind the GUI is a good approach,
                      however saying that the M *is* the domain model is very different and
                      to me less appropriate.
                    • Colin Jack
                      ... Yeah thats what I m coming round to now too especially with MVC and because you can generate large amounts of the basic view model classes from the domain
                      Message 10 of 23 , Dec 15, 2008
                      View Source
                      • 0 Attachment
                        > I heavily prefer "IS NOT", as I don't want UI concerns leaking down
                        > into my domain layer.

                        Yeah thats what I'm coming round to now too especially with MVC and
                        because you can generate large amounts of the basic view model classes
                        from the domain (for example an Address value object can be used to
                        generate an Address view model DTO with all get/set properties).
                      • Casey Charlton
                        Indeed - I don;t think it would be possible to havethe M represent the domain model - the app servies also live in the M, so do specifications, etc... as the C
                        Message 11 of 23 , Dec 15, 2008
                        View Source
                        • 0 Attachment
                          Indeed - I don;t think it would be possible to havethe M represent the domain model - the app servies also live in the M, so do specifications, etc... as the C communicates with the M, the M must be more than just a domain model (possibly not if you were using AR, in which case you have a non-DDD style domain model) 

                          2008/12/15 Colin Jack <colinjack@...>

                          > It depends on whether you consider MVC a UI pattern (where the M is a
                          > layer that communicates with the "real" application), or you consider
                          > MVC an architectural pattern where the M is everything behind the UI,
                          > back to the persistence layer.

                          To me thinking of M as everything behind the GUI is a good approach,
                          however saying that the M *is* the domain model is very different and
                          to me less appropriate.


                        • Eben Roux
                          Hello, To me the M in MVC/P represents (in an abstract sense) what the View requires to render. This may be a very specific presentation model or something as
                          Message 12 of 23 , Dec 15, 2008
                          View Source
                          • 0 Attachment
                            Hello,

                            To me the M in MVC/P represents (in an abstract sense) what the View
                            requires to render. This may be a very specific presentation model or
                            something as simple as passing a domain object.

                            So the M is only used in the sense of MVC/P. The C/P (controller or
                            presenter) uses the domain either directly or through as a service.
                            But this interaction, to me (rightly or wrongly), does in no way refer
                            to the M in MVC/P.

                            Hopes it makes sense.

                            Regards,
                            Eben
                          • Sidar Ok
                            What I understand from M in MVC/P is the UI model. Its behavior is based on UI actions, and translated into Domain usually via application services or an anti
                            Message 13 of 23 , Dec 15, 2008
                            View Source
                            • 0 Attachment
                              What I understand from M in MVC/P is the UI model. Its behavior is based on UI actions, and translated into Domain usually via application services or an anti corruption layer.


                              On Mon, Dec 15, 2008 at 12:07 PM, Eben Roux <ebenroux@...> wrote:

                              Hello,

                              To me the M in MVC/P represents (in an abstract sense) what the View
                              requires to render. This may be a very specific presentation model or
                              something as simple as passing a domain object.

                              So the M is only used in the sense of MVC/P. The C/P (controller or
                              presenter) uses the domain either directly or through as a service.
                              But this interaction, to me (rightly or wrongly), does in no way refer
                              to the M in MVC/P.

                              Hopes it makes sense.

                              Regards,
                              Eben




                              --
                              Sidar Ok
                              http://www.sidarok.com
                            • Colin Jack
                              ... Yup that makes perfect sense and is my view on it too.
                              Message 14 of 23 , Dec 15, 2008
                              View Source
                              • 0 Attachment
                                > To me the M in MVC/P represents (in an abstract sense) what the View
                                > requires to render. This may be a very specific presentation model or
                                > something as simple as passing a domain object.

                                Yup that makes perfect sense and is my view on it too.
                              • Casey Charlton
                                The M can also take actions and initiate things that have no relation to the UI 2008/12/15 Colin Jack
                                Message 15 of 23 , Dec 15, 2008
                                View Source
                                • 0 Attachment
                                  The M can also take actions and initiate things that have no relation to the UI

                                  2008/12/15 Colin Jack <colinjack@...>

                                  > To me the M in MVC/P represents (in an abstract sense) what the View
                                  > requires to render. This may be a very specific presentation model or
                                  > something as simple as passing a domain object.

                                  Yup that makes perfect sense and is my view on it too.


                                • Colin Jack
                                  ... Do you have an example, I ve tended to keep my view or presentation model *relatively* GUI focussed and keep most of the behavior in the controller or
                                  Message 16 of 23 , Dec 15, 2008
                                  View Source
                                  • 0 Attachment
                                    > The M can also take actions and initiate things that have no relation
                                    > to the UI

                                    Do you have an example, I've tended to keep my view or presentation
                                    model *relatively* GUI focussed and keep most of the behavior in the
                                    controller or classes the controller directly uses (services for
                                    example).
                                  • Casey Charlton
                                    User clicks Send Email ... M gets a DTO with email, M deals with it, sends it, UI never renders anything from the M ... the controller will decide to change
                                    Message 17 of 23 , Dec 15, 2008
                                    View Source
                                    • 0 Attachment
                                      User clicks "Send Email" ... M gets a DTO with email, M deals with it, sends it, UI never renders anything from the M ... the controller will decide to change view ...

                                      2008/12/15 Colin Jack <colinjack@...>

                                      > The M can also take actions and initiate things that have no relation
                                      > to the UI

                                      Do you have an example, I've tended to keep my view or presentation
                                      model *relatively* GUI focussed and keep most of the behavior in the
                                      controller or classes the controller directly uses (services for
                                      example).


                                    • Randy Stafford
                                      Trygve Reenskaug is the father of MVC, and wrote the first publication about it in 1979 while working with the Smalltalk group at Xerox PARC. If you look at
                                      Message 18 of 23 , Dec 15, 2008
                                      View Source
                                      • 0 Attachment

                                        Trygve Reenskaug is the father of MVC, and wrote the first publication about it in 1979 while working with the Smalltalk group at Xerox PARC.  If you look at his example in that publication, which was a model of the domain of planning (e.g., networks of activities), and if you look at his subsequent work (e.g. the Mental Object Models and Model/Editor Separation patterns in his 2003 pattern language), it is quite clear that he intends “Model” to specifically mean “domain model”, not generally Presentation Model and/or everything “below” the View and Controller.  You can find Trygve’s MVC work here: http://folk.uio.no/trygver/themes/mvc/mvc-index.html

                                         

                                        The next most influential early publication about MVC is Glenn Krasner and Stephen Pope’s “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80”, published in the August/September 1988 issue of JOOP (the Journal of Object-Oriented Programming).  If you look at the example Models in that article, you can see that in two cases (Counter and FinancialHistory), they are “domain object” classes.  But in a third case, the “text Organizer”, the notion of a Presentation Model has started to creep in.  The Organizer class is a Presentation Model, and its underlying domain model is a Dictionary of Texts.  While the text of the JOOP article doesn’t appear to be available on the Web, this contemporary paper by the same authors is almost identical: http://www.create.ucsb.edu/~stp/PostScript/mvc.pdf.

                                         

                                        Recognizing this dichotomy, and hoping to reduce ambiguity in the use of the acronym MVC, I began using the acronym MMVC, and wrote the following page on Ward’s Wiki, some nine years ago: http://c2.com/cgi/wiki?ModelModelViewController.

                                         

                                        Regards,

                                        Randy

                                         


                                        From: Casey Charlton [mailto:casey@...]
                                        Sent: Monday, December 15, 2008 3:29 AM
                                        To: domaindrivendesign@yahoogroups.com
                                        Subject: Re: [domaindrivendesign] Re: The M is MVC or MVP _IS_ or _IS NOT_ a Domain Model Object

                                         

                                        Indeed - I don;t think it would be possible to havethe M represent the domain model - the app servies also live in the M, so do specifications, etc... as the C communicates with the M, the M must be more than just a domain model (possibly not if you were using AR, in which case you have a non-DDD style domain model) 

                                        2008/12/15 Colin Jack <colinjack@hotmail. com>

                                        > It depends on whether you consider MVC a UI pattern (where the M is a

                                        > layer that communicates with the "real" application) , or
                                        you consider
                                        > MVC an architectural pattern where the M is everything behind the UI,
                                        > back to the persistence layer.

                                        To me thinking of M as everything behind the GUI is a good approach,
                                        however saying that the M *is* the domain model is very different and
                                        to me less appropriate.

                                         

                                      • Colin Jack
                                        ... Superb as always, and you now have a forum entry to copy content from for the associated entry in the FAQ :)
                                        Message 19 of 23 , Dec 15, 2008
                                        View Source
                                        • 0 Attachment
                                          > Recognizing this dichotomy, and hoping to reduce ambiguity in the use
                                          > of the acronym MVC, I began using the acronym MMVC, and wrote the
                                          > following page on Ward's Wiki, some nine years ago:
                                          > http://c2.com/cgi/wiki?ModelModelViewController.

                                          Superb as always, and you now have a forum entry to copy content from
                                          for the associated entry in the FAQ :)
                                        • Peter Morris
                                          I haven t read the other threads on this because there were too many, but here is my opinion anyway :-) In the app I am currently writing we have Database
                                          Message 20 of 23 , Dec 15, 2008
                                          View Source
                                          • 0 Attachment
                                            I haven't read the other threads on this because there were too many, but
                                            here is my opinion anyway :-)

                                            In the app I am currently writing we have

                                            Database
                                            Persistence framework
                                            Domain
                                            App layer
                                            ============
                                            View model (DTO's for tasks, not domain model DTOs)
                                            ============
                                            Client

                                            In this case the client doesn't even know what the domain objects are. It
                                            is only concerned with "informaton to show", "information to capture", and
                                            "choices to make". Which is why we have a view model.


                                            Pete
                                            ====
                                            http://mrpmorris.blogspot.com
                                            http://www.capableobjects.com
                                          • daneel3001
                                            ... Colin Totally agree with you and I m glad there is such discussion here about the Model in the Presentation because I was too lazy not to answer your email
                                            Message 21 of 23 , Dec 16, 2008
                                            View Source
                                            • 0 Attachment
                                              --- In domaindrivendesign@yahoogroups.com, "Colin Jack"
                                              <colinjack@...> wrote:
                                              >
                                              > > It depends on whether you consider MVC a UI pattern (where the M is a
                                              > > layer that communicates with the "real" application), or you consider
                                              > > MVC an architectural pattern where the M is everything behind the UI,
                                              > > back to the persistence layer.
                                              >
                                              > To me thinking of M as everything behind the GUI is a good approach,
                                              > however saying that the M *is* the domain model is very different and
                                              > to me less appropriate.
                                              >
                                              Colin

                                              Totally agree with you and I'm glad there is such discussion here
                                              about the Model in the Presentation because I was too lazy not to
                                              answer your email re what to do to "protected" the Domain Model if
                                              it's meant to be such an important place in the life of a system.

                                              Daniel Fernandes
                                            • Colin Jack
                                              ... No-one is as lazy as me with e-mails, friends who e-mail learn to expect to wait at least 3 months for a reply :)
                                              Message 22 of 23 , Dec 17, 2008
                                              View Source
                                              • 0 Attachment
                                                > I was too lazy not to answer your email

                                                No-one is as lazy as me with e-mails, friends who e-mail learn to
                                                expect to wait at least 3 months for a reply :)
                                              • Dicky Arinal
                                                Talking about MVC, do you always abstract the MVC into suitable interfaces or abstract classes, so my application doesn t stick to one MVC framework (like
                                                Message 23 of 23 , Dec 17, 2008
                                                View Source
                                                • 0 Attachment
                                                  Talking about MVC, do you always abstract the MVC into suitable
                                                  interfaces or abstract classes, so my application doesn't stick to one
                                                  MVC framework (like SpingMVC, ASP.NET MVC)?

                                                  Abstract out to suitable interfaces is common practice for other
                                                  pattern, like repository pattern, so my application doesn't stick to
                                                  one data access layer technology like Hibernate, Entity Framework,
                                                  etc.

                                                  Thanks..

                                                  regards,

                                                  Dicky Arinal
                                                Your message has been successfully submitted and would be delivered to recipients shortly.