I am confused about how model and view can interact
I was making a simple to do app with mvc pattern and I saw an article which said you shouldn't pass the model values directly to the view, which made the project more complex than I thought (I am relatively new to programming and this is the first time I am trying out a design pattern).
But then later on I talked to someone who said that that is not true and you can send the model data directly to view, he didn't even use classes or some kind of grouping to separate the function he just put them in separate files.
I was wondering if there is a guideline that I couldn't find or we can do whatever we want as long as they are kind of separated. I would love an article or a guide to read up on as well.
Since, I am not 100% sure the context in which you are trying to apply the MVC pattern, a good generic explanation of MVC can be found in GoF's 1995 book, Design Patterns: Elements of Reusable Object Oriented Software.
In the book, they state the following.
The Model is the application object, the View is its screen
presentation, and the Controller defines the way the user interface
reacts to user input.
A more robust explanation can be found from Martin Fowler where he also
makes the case for a variation of Model View Controller that uses a Presentation Model.
If you are referring to Spring MVC then there is some magic that blurs the lines a bit. But in general, you have a controller that represents some screen or an encapsulated piece of functionality that the user (web requests) interact with. The controller serves up responses that are derived from the domain, usually via a Spring Service (i.e. #Service). The domain (Model) doesn't know anything about the View and the View may or may not know anything about the domain.
Given that, the View should be derived from the Model. But that's not always the case since sometimes how we present things to a screen is not the best logical way to model things in our domain - not to mention, the domain should be presentation agnostic. This leads into Fowler's argument for a Presentation Model, which is a model that belongs to the Presentation.
I call this a Presentation Model because it's a model that is really
designed for and thus part of the presentation layer.
Microsoft took that idea and ran with it in a variant of MVC called MVVM (Model View ViewModel).
You can read more about that in Microsoft's documentation on ASP.Net Core.
So, back to your original question of "Should you pass the model directly to the view?" If you are using MVC then the controller is what provides the interaction. But if you're really asking, "Can you bind your view directly to the model?" If your model has all the stuff you need organized how your view needs it, then sure. And if it's simple enough, maybe that's the way to go. Otherwise, you could go with something like a Presentation Model or MVVM.
This question already has answers here:
Model View Controller vs Boundary Control Entity
(4 answers)
Closed 2 years ago.
I'm not sure if i got the right concept.
I was told by people that
Boundary = View
Entity = Model
Control = Controller
however based on my knowledge of MVC. (fat model, thin controller)
Isn't the Boundary = Controller, Control = Model (the busienss logic) and Entity = Model (The orm classes or similar entity classes which does only crud ).
I may be wrong, please guide me!
The two are very similar. The main difference is that MVC is typically used in user interface design whereas ECB is most often used in business logic. Here's a portion of a presentation by Adam Bien, who is known for promoting ECB, that helped me understand the difference between the two.
Actually your first definition is simply correct. The meaning of words is sometimes confusing. The following link confirms and summarizes both patterns (naming ECB a variant of MVC): The Entity-Control-Boundary Pattern
Your explanation is correct. But they are not similar. MVC is for user interaction. Business rules are not bound to users directly and even not I/O devices like the internet itself. The ECB pattern is used for separating business entities from the boundary (mvc framework, ORM's). Entities are business objects, they know nothing about databases, orm's. The control is not a controller like in MVC, it can be a Command which represents a use case. Only the Control may access the business entities. Business entities are a world of their own, completely isolated from the MVC layer. It can be a business framework with patterns, principles, types and separated layers of its own, that does not wish to interact with anything related to I/O.
We can combine MVC with ECB like this:
User <-> Controller [Boundary] <-> Control (use case) [Control] <-> Business entities [Entity] <-> Other business entities [Entity]
While using a custom MVC framework I found that the view can actually access data in the model. That was a bit of a surprise because I always thought the V must go through the C. It was something like
//this is completely made up but not far off
serverside foreach(var v in Model.GetSomeList()) {
<div>#v.name</div>
}
Do many MVC frameworks in any programming language allow the view to access anything in the model? When do i choose what should go through the controller and what is ok to access from the view?
Usually that "Model" is really like viewmodel, not the business layer Model object, although it could be the POCO version of the business object. Basically, the view is bound to some poco without any business logic.
Information flow in classical MVC.
Data in MVC should not go from model through controller to view. That is violation of the original concept.
If you read the original definition of MVC design pattern you will notice that Views are meant to request the data from Model. And views know when to do it, because they are observing Model for changes.
Modern interpretations.
In the original concept you were meant to have small MVC triad for each element in the application. In modern interpretation (as per Martin Fowler), the model is not anymore any single object or class. Model is a layer, which contains several groups of objects. Each with a different set of responsibilities.
Also, with the rise of Web there was another problem. You cannot use classical MVC for websites. Theoretically now you could achieve it by keeping an open socket and pushing a notification to the browser every time you changed something in the model layer.
But in practice even a site with 100 concurrent users will start having problems. And you would not use MVC for making just a blog. Using such an approach for even minor social network would be impossible.
And that was not the only divergence from the original concept.
MVC-inspired patterns
Currently, along with classical MVC (which is not even all so classical anymore). There are three major MVC inspired patterns:
Model2 MVC
This is basically same classical MVC patter, but there is not observer relationship between model later and view(s). This pattern is meant to me more web-oriented. Each time you receive a user request, you know that something is gonna change in model layer. Therefore each user request cause view instance to request information from the model layer.
MVP
This pattern, instead replaces controller with a presenter. The presenter request data from model layer and passes it to current view. You can find patterns definition here. It is actually a lot more complex, and I, honestly, do not fully understand it.
In this case the View is passive and will not request any data from model layer.
MVVM
This pattern is closer to MVP hen to classical MVC. In this case the controller-like structure (which actually would be more then a monolith class) request data from model layer and then alters it in such a way as it is expected by the (passive) view.
This pattern is mostly aimed at situation where developer does not have full controller over views or/and model layer. For example, when you are developing some application where model layer is SAP. Or when you have to work with an existing frontend infrastructure.
FYI: what is called "MVVM" in ASP.NET MVC is actually a good Model2 implementation .. what they call "viewmodels" are actually view instances and "views" are just templates that are used by views.
This is common. If you look at the Wikipedia page for MVC, this is what it says for the view:
A view requests from the model the information that it needs to generate an output representation.
MVC is an architectural style, so some people change it as they see fit. From the design intentions of the architecture this particular question is certainly not frowned upon.
I have a problem at the conceptual level, I read a lot but I'm not out yet.
I would like to model a system that plans to place orders and allows you to choose the products according to the selected location.
In the analysis phase it is right that is the user interface to request data to the classes product, location and orders?
In the design phase, can view access to multiple models and display the data or is more correct if the orderView access only to the order model and this takes all the data from the database (using different DAO for location, order and product)?
Thanks in advance, Vincenzo
An approach to solve this is to use a ViewModel (http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx), basically a composite model that groups several other models together so that they can be serviced to a view.
So if you have a Product model and a Location model and an Order model, all logically distinct models that you want to combine together on a single view (e.g. Monthly Sales Summary), you could create a SalesSummaryViewModel that contains products, orders, and locations to be returned to that view.
You should consider Model View ViewModel, have ViewModel objects created for serving your view needs, composing your business object.
There are no absolutes
In the design phase "is it right..." is the wrong thing to say. Design is an exercise in trade offs. At the end of my treatise I hope you conclude that we're splitting hairs on a sound design concept that you should be adhering to.
Separating UI from Data from Managing their interaction is a good design goal
Whether you use MVP, MVC, MVVM is largely an academic exercise in this forum because we don't have the overall design details.
For arguments sake, let's just call the basic idea MVC. MVP is a variation of that and MVVM (ViewModel) is a specialization of our MVP.
MVVM / ViewModel is .NET Specific
Model-View-ViewModel pattern was created by microsoft architects to take advantage of the capabilities of WCF, XAML, and Silverlight (vis-a-vis ASP.NET and Windows Forms). In the final analysis it's a variation of our basic concept, a variation that leverages .NET technologies to be sure.
Exposing Model to View
.. or not is a judgement call on how much coupling you want between your model view controller components.
MVC gives your view a reference to your model. This is handy for data binding. If you use .NET Binding architecture then this pattern is what you may end up using.
MVP - only the Presenter (a Controller w/ more power, if you will) sees the data model. You can still use .NET Binding architecture, for example, but the presenter is the middle man hooking it all up. Why? Because you made that informed decision based on your overall design.
MVP means the Presenter intimately knows about the View and Model so it can wire them together and handle UI inputs. It therefore follows that there is a Presenter for each View as they are customized pairs, (most likely) not interchangeable.
Development Tools can Influence Design Architecture
For example if you are developing in .NET WCF you absolutely have no choice but to use MVVM; that's the way that framework works.
Likewise, Mac OS X development IDE forces you to use MVC. So does Ruby On Rails and .NET MVC web development
If you are using some kind of Object Relational Mapper (ORM) - and .NET LINQ is one - then your design may not have a Data Access Layer per se.
If you need an example, this is done in the music store http://mvcmusicstore.codeplex.com/releases/view/64379#DownloadId=228002.
The details are around p95 of the associated PDF.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
NOTE:
This question has been updated to provide more detail and insight than the previously.
UPDATE:
I just want to say thank you to everyone who responded. I'm still pretty much in the dark on what design pattern would work best for the Widget. Perhaps one of the Factory or Builder patterns?
I am just getting started on a new project and need to use MVC, OO and design patterns.
Here's the idea: Imagine a page that displays a set of widgets. These widgets are (usually) charts that are based off of data contained in several separate tables in the database. I use a running example of page that reports on a student's performance.
High Level Requirements
a page that displays a set of (HTML only) widgets.
widget's data will be based off a database query.
the page can be used to view separate datasets containing similarly laid out data. For example, a single page will display widgets that report on various aspects of a single student's performance.
want to see another student's performance, pull up another page. Displaying different widgets for different students is not needed (though it may be nice to have later).
There may be many students, but data contained in the database is similarly laid out for all students.
the way a widget is displayed may be changed easily (say changing a widget from displaying as a pie chart to display as a bar chart).
widgets should be able to be created quickly.
Low Level Requirements
Currently data does not change so widgets will not need to automatically update themselves.
Widgets may represent a ratio of two things (eg. a ratio of failed tests to successful tests as a pie chart), a series of points, or sometimes a single numeric value.
Development of new widgets should be a breeze, existing code need not be modified.
Framework to be used: Zend Framework, based on MVC.
There are (minimally) three things to define a widget: the dataset to report on (in the example above, the student ID), the query that describes the metric being reported, and a render mode (barchart, timeseries etc).
Here is a pass at breaking down the responsibilities of each layer of the MVC:
View: Zend views are HTML templates with PHP injected. They will contain one of several types of widgets. Widgets are of various forms including: static JPEG images (loaded from a remote site ie: <img src="http://widgetssite.com?x=2&y=3"/>, JSON based javascript widgets, or charts of various kinds (piechart, bar chart etc.)
Controller: Creates the widgets, assigns them to the view afterwards. The set of widgets that is to be displayed on a page needs to be maintained somewhere. Since I can't think of a good way to do this in the view, I'll add this to the controllers responsibilities for now. If there's a better place for this please shout. The controller will also have to handle any other input parameters and passing them to the widget. For example, the data_set id which may be passed at the url line as http:/.../report/?student_id=42
Model: The model, in the Zend Framework, is responsible for pulling the data and as such will most likely contain a class for each widget for accessing the database.
Some points:
The model here, represents the data for a particular widget. So necessarily, it will need to know what the query is going to be, in order to pull together the tables necessary to fetch that data.
There's an additional processing step that will most likely be necessary before the widget can present the data. This is dependant upon which renderer will be used. Sometimes it may require forming a url out of the data returned. Other times, a JSON array. Other times perhaps creating some markup. This can go either in the model or the controller or the view. Unless anyone can think of a good reason to move it to the controller or view, it is probably best to let this live in the model and keep the view and controller thin.
Likewise, a widget will be made up of 3 things, its parameters, its data, and its renderer.
One big part of the question is: What's a good way to represent the widget in an Object Oriented design? I already asked this once, couldn't get an answer. Is there a design pattern that can be applied to the Widgets that makes the most sense for this project?
Here's a first pass at a rather simple class for the Widget:
class Widget{
//method called by the view
render() {//output the markup based on the widget Type and interleaved the processed data}
//methods called by the controller:
public function __construct() {//recieve arguments for widget type (query and renderer), call create()}
public function create() {//tell the widget to build the query, execute it, and filter the data}
public function process_data() {//transform into JSON, an html entity etc}
//methods called by the model:
public function build_query() {...};
public function execute_query() {...};
public function filter_data() {...};
}
Looking at it, I can already see some problems.
For example, it is straightforward to pass the widget that was created in the controller to the View to render.
But when it comes to implementing the model it seems not so straight forward. Table Gateway Pattern is simpler to implement than ORM. But since table gateway pattern has one class for each model/table it doesn't seem to fit the bill. I could create a model for a particular table, and then within that, instantiate any other models needed. But that doesn't seem so to fit the Table Gateway Pattern, but rather ORM pattern. Can Table Gateway Pattern be implemented with multiple tables? What alternatives are there? Does it make sense that the controller creates the widget and the widget creates the Model?
Another issue that arises is that this design does not enable ease of widget creation. ie. Say I wanted to create a PiechartWidget, how much code can be reused? Would it not make more sense to use some OO ideas such as an interface or abstract classes/methods and inheritance?
Let's say I abstract the Widget class so only the shared methods are defined concretely, and the rest are declared as abstract methods. Revising the Widget class to make it abstract (second pass):
abstract class Widget{
private $_type;
private $_renderer;
//methods called by the controller:
//receive arguments for widget type (query and renderer),
protected function __construct($type, $renderer) {
$this->_type = $type;
$this->_render = $renderer;
$this->create();
}
//tell the widget to build the query, execute it, and filter the data
private function create() {
$this->build_query();
$this->execute_query();
$this->filter_data();
}
//methods called by the model:
abstract protected function build_query();
protected function execute_query() {
//common method
}
abstract protected function filter_data();
//method called by controller to tranform data for view
//transform into JSON, an html entity etc
abstract protected function process_data();
//method called by the view
//output the markup based on the widget Type and interleave the processed data
abstract protected function render();
}
Is this a good design? How could it be improved?
I assume writing a new widget will require at least some new code to build the query, and maybe filter the data, but it should be able to use preexisting code for almost all of the rest of its functionality, including the renderers that already exist.
I am hoping anyone could provide at least some feedback on this design. Validate it?
Tear it apart. Call me an idiot. That's fine too. I could use any forward traction.
A few specific questions:
Q1. What's the best way to implement the renderers, as part of the Widget class or as a separate class? 1a. If separate, how would it interact with the widget class(es)?
Q2. How could I improve this design to simplify creation of new kinds of widgets?
Q3. And lastly, I feel like I am missing something here with regards to data encapsulation. How does data encapsulation relate to the requirements and play out in this scenario?
For #2, if you are using WPF on windows, or Silverlight in general, consider using MVVM pattern (Model-View-ViewModel), here is explanation with a WPF implementation:
MVVM at msdn
For #1 (comments not answer): For exact implementations (and minor variations) of MVC, it really depends on what language you are using.
Another alternative to MVC is MVP Model View Presenter
Remember the goal of OO is not to cram design patterns into your code, but to create maintainable code with less bugs/increased readability.
High Requirements
- a page that displays a set of widgets. widgets are based off of data contained in several separate tables in the database.
- widget's data will be based off a database query. widget display its data in a particular way.
- widgets should be able to be created quickly.
Low Level Requirements
- Data changes, multiple charts need to change, push model (from data to ui)
- Development of new widgets should be a breeze, existing code need not be modified
Advice from design patterns basics
- MVC supports one to many notification pattern, so yes, once your widget is initialized, created and connected to the web page, it should wait for notifications from the database.
- Strategy pattern, your entire code should develop to a interface. New widgets should be added to a parametrized LinkedList (or some other data structure). That way new widget developers just implement the interface and your framework picks up these notifications without change to existing code.
Siddharth
The purpose behind all of these ideas -- MVC, patterns, etc. -- is essentially the same: every class should do one thing, and every distinct responsibility in your application should be separated into distinct layers. Your views (page and widgets) should be thin and make few if any decisions other than to present data gathered from the models. The models should operate on a data layer agnostically, which is to say they should not know whether the source of their data is a specific kind of data source. The controllers should be thin as well, acting basically as a routing layer between the views and models. Controllers take input from the users and perform the relevant actions on the models. The application of this concept varies depending on your target environment -- web, rich client, etc.
The architecture of the model alone is no trivial problem. You have many patterns to choose from and many frameworks, and choosing the right one -- pattern or framework -- will depend entirely on the particulars of your domain, which we have far too few of here to give you more specific advice. Suffice it to say it is recommended you spend some time getting to know a few Object-Relational Mapping frameworks for your particular technology stack (be it Java, .NET, etc.) and the respective patterns they were built on.
Also make yourself familiar with the difference between MVP and MVC -- Martin Fowler's work is essential here.
As for design patterns, the application of most of the standard GOF patterns could easily come into play in some form or another, and it is recommended you spend time in Design Patterns or one of the many introductory texts on the subject. No one here can give specific answers as to how MVC applies to your domain -- that can only be answered by experienced engineers in cooperation with a Product Owner who has the authority to make workflow and UI decisions that will greatly affect such decisions in their particulars.
In short, the very nature of your question suggests you are in need of an experienced OOP architect or senior developer who has done this before. Alternatively give yourself a good deal of time in intensive study before moving forward. The scope of your project encompasses a vast amount of learning that many coders take years to fully grasp. This is not to say your project is doomed -- in fact you may be able to accomplish quite a lot if you choose the right technology stack, framework, etc., and assuming you are reasonably bright and focused on the task at hand. But getting concepts as broad as "MVC" or "OO" right is not something I think can be done on a first try and under time constraints.
EDIT: I just caught your edit re: Zend. Having a framework in place is good, that takes care of a lot of architectural decisions. I'm not familiar with Zend, but I would stick to its defaults. Much more depends here on your ultimate UI delivery -- are you in a RIA environment like Flash or Silverlight, or are you in a strict HTML/JavaScript environment? In either case the controllers should still be thin and operate as routers taking user requests from HTTP gets and posts, and immediately handing off to the models. The views should remain thin as well and make as few decisions as possible. The concept of MVC applied in a web environment has been pretty well established by Rails and the frameworks that followed, and I'm assuming Zend is similar to something like CakePHP in this regard: the application server has a routing system that maps HTTP calls to controller actions that respond with specific views. The request/response cycle is basically this:
User request posted through a URL
Router hands control to a controller class
Controller makes a call to a model with the given params
The model operates on the data, posts back to the controller
The framework maps the finished data into a view, with some kind of code-behind that puts the results of the request in the view's scope.
The framework creates html (or xml or whatever) and posts back to the caller.
It sounds like you want to use MVC and other patterns because they are the new buzz words. Splitting your design among model view and controller should tell you how to spread the functionality of your application. Although I totally agree that using MVC is the correct approach, I suggest you research the pattern and look at some source code that implements it. As a start to your question though, the widgets that will be displayed will be your views, that much should be obvious. Input from the user, such as changing a parameter of some widget or requesting other information will come into your application and should be handled by a controller. A concrete example of this is a Java-based HttpServlet. The controller servlet receives the user request and asks the lower layers of your app (Service, Persistence, etc) for an updated representation of your model. The model includes all of your domain-specific objects (i.e the data from your databases, etc). This data (the updated model) comes back to the controller, which in turn pushes out a new view for the user. Hopefully that is enough to get you started about designing your app.
As further help, you could consider using a framework to assist in the development of your app. I like Spring a lot, and it has a first class MVC implementation that really helps guide you to designing a correct MVC web app.
You may consider using Subject Observer Pattern
Have your class, named DataReader as single Subject. Your multiple widgets will act as Observers. Once your DataReader receives data from server, it (Subject) will inform multiple widgets (Observer).
Your individual widgets may have different presentation to present to same set of data from DataReader.
Update
In the message where subject notify observer, you may include the message type information as well. Widgets will only process message type, which is within their own interest, and ignore rest of the message.
NOTE: This is my new answer based on new the updated question.
Here is a proposed class diagram. I'm going to work on a sequence diagram.
My old answer is here:
Based on the requirements you describe, your model is your database or data warehouse and your views are your pie charts, bar graphs, etc. I don't see the need for a controller, because it sounds like you have a one page dashboard with widgets.
You need to spend your time on the database model. Since you're doing all selects and no updates, go for a de-normalized data model that makes these queries efficient. You should put the results of these queries in a table type object (e.g. 2-dimensional array) or 3-dimensional array based on the amount of dimensions. You are limited to 3 dimensions unless you use animation.