• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Model View Controller

 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ranchers,

I'm a little bit confused about the definition of the term model. I know, that the view is a JSP and the controller is a servlet (the Front-Controller), but what is the model? Some books wrote: The JavaBeans, used by the JSP to render the view, are the model. Another books wrote: The business-tier and the EJBs are the model. What is true?

Regards,
Oliver
 
Jan Cumps
Bartender
Posts: 2608
14
C++ Linux Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oliver,

they are both true.

The model is that part of your application that represents the business logic.

The javabeans used by the jsp will usually represent something of the business logic: a customer. a shopping cart.

Also ejb represent your business logic: again the customer, the shopping cart, ...

Regards, Jan
 
Oliver Rensen
Ranch Hand
Posts: 109
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan, thanks a lot for your clarification.
 
Pham Huy Anh
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

There is also business object (Classes with only getter/setter). I am wondering where it is on the picture MVC. Is that Model (== JavaBeans, used by the JSP to render the view)?

If I don't like EJB, then I use Spring framework instead for ex. I would have some kind of business classes (which contain business logic), usually named like CustomerManager, OrderManager... Are theses model in MVC too?

Thanks,
huyanh
[ April 15, 2007: Message edited by: Pham Huy Anh ]
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Model is simply something that holds state that your Controllers and Views communicate with. The focus of the pattern primarily a separation of concerns between components. In other words, it is not as helpful to say "X class is the model" so much as to say "there is no persistence code in my controllers or views".

There could be arguments made looking at the same architecture as to what classes are the Model. One could argue EJBs, another could argue Transfer Objects, still another might refer to the entire backend as the Model. But that's really not the point of the pattern.

The MVC identifies three types of code: Model, Controller, and View. Following this pattern is simply a matter of ensuring that no component contains more than one of these 3 types.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic