Some facts/assumptions:
It is said that Ruby on Rails follows MVC architectural pattern.
The MVVM (Model View ViewModel), which derives from MVC, offers an abstraction layer, where all the buttons, labels and links (View) are separated from the way models expose data (ViewModel).
Some Javascript frameworks, that excel in building Single Page Apps, leverage MVVM pattern (for instance Knockout.js).
If we check Ruby toolbox, we will see a several presenter solutions like Draper and Apotomo that work just as a ViewModel thing.
Assuming there is no bs in my 'facts' section, there is one thing that bothers me:
Can we call Rails with Draper, Apotomo (or other presenter/decorator) a MVVM solution?
Can we say we are following MVVM pattern with Rails, if we encapsulate the data from the model in a form of decorator/presenter container with Draper?
Or is there something missing and we can't call it a MVVM, like Knockout.js?
Thank you for your insights.
Not in my opinion.... I think of MVVM as creating specific view objects that are disconnected from the underlying data/domain object.
With the Rails presenter pattern, these presenters will typically wrap around the active record object and add methods to it that pertain to the presentation.
Related
So, I've read a bit about .net and MVC. I remember reading something that suggested using ViewModels in MVC. This would help lessen the desire to have the view messing with data that should be controlled by the controller.
I thought this is what is referred to by the MVVM pattern. Evidently after looking at that, the implementation actually does away with controllers altogether. Not exactly what I want to do.
Is it still legit to use a ViewModel in my case? Is it better practice or just unnecessary work? Where would you put your ViewModels directory/namespace at? Under the Models directory?
Is it legit for Models to know about ViewModels? For example, you have a Model Return a ViewModel to the controller?
ViewModels are not by default in MVC projects. It is something you need to add if you feel it benefits you to couple View to a Model "easier"
http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.net-mvc-applications
The concept of the ViewModel isn't just for ASP.NET MVC, as you'll see references to ViewModels throughout the web in articles and blog posts about the MVC, MVP, and MVVM patterns. Those posts and articles can center around any number of technologies such as ASP.NET, Silverlight, WPF, or MVC... This post will investigate ViewModels as they apply to the world of ASP.NET MVC.
http://msdn.microsoft.com/en-us/magazine/ff798279.aspx
Models and ViewModels are different. Don't confuse the ViewModel with the MVVM pattern.
The use of a view model can make the interaction between model and view more simple. A model can sometimes be over complicated having other model objects as members, which could have model objects as member etc..
By using a view model you have a good way to simplify what the view deals with. This will also filter down what can be seen in intellisense, so if you have different people developing the models than those working on the views, creating a simple view model can make it much easier for those just dealing with the UI.
Design patterns in my opinion are not rigid concepts, but rather guidelines that help you architect your application better. The Model-View-ViewModel(MVVM) design pattern stems from WPF, where there is a very robust Bata Binding framework that facilitated the pattern. The idea is that you have business data in your model, but since there are often view specific data(i.e the currently selected item in a tree control) that didn't belong in the model, you created view model objects that wraps your model, but the view models also contained view specific state data. So your views can bind to the view models instead of the model objects directly, thus keeping the models clean(easy to test, maintain etc).
Asp.net MVC is different in that the databinding in the Views is nowhere near as powerful as it is in WPF. In WPF you could actually implement much of your GUI and model data interaction through databinding, which made the view models useful. But in Asp.net MVC your controllers are designed to handle this, and since the databinding is close to non existant I just don't see the value of having view model wrappers around your model objects in Asp.net MVC.
There is all sorts of talk lately in the Ruby on Rails community about decorators and presenters.
What is the essential difference between the two? If there is, what are the clues that tell me which one to use over the other? Or perhaps to use the two in conjunction?
A decorator is more of a "let's add some functionality to this entity". A presenter is more of a "let's build a bridge between the model/backend and view". The presenter pattern has several interpretations.
Decorators are generic/general purpose. Presenters have a narrower range of responsibilities/uses. Decorators are used across domains, presenters are almost always related to view-like functionality.
Draper site
RailsCasts Draper Episode
I suggest you to check this - Exhibit vs Presenter.
Decorator is a design pattern that is used to extend the functionality of a specific object by wrapping it, without effecting other instances of that object. In general, the decorator pattern is an example of the open/close principle (the class is closed for modifications, but available for extensions).
Both the exhibit and presenter patterns are a kind of the decorator pattern.
I am a bit confused on what to write where in Rails.
Ideally, I will be having a view, a controller, a model. Model should be having all the business logic. But in most of the Rails applications I've seen, I've seen most of the business logic written in the Controller files.
Should we call them as controller? And what about View-models. I am talking about the datamodels that are associated for a view. I am having JSF and Swing in my mind when I say this. There every view has a datamodel associated with it, usually a bean. But here, we don't have anything like that or I am ignorant? And what about service layers, How do I implement them in my Rails code.
To summarize my questions
Why are business logic being
written in Controllers in most of
Rails code? Is this a good practice?
How to incorporate the view-model in
rails, ie, data-models for view?
Where to put service layers in a Rails app?
Thanks
To summarize my answers:
The new standard for Ruby on Rails is to place business logic in the model. This is also known as fat model skinny controller.
Rails doesn't enforce this approach of one data model but you can implement it if you choose. The basic scaffolding does something similar.
The service layers will most likely be stored within rack middleware. This allows for general filtering of requests and responses.
Is there a name for the software design pattern that involves MVC with domain models and view models? It's the pattern used when a tool like AutoMapper is employed.
I was attempting to explain the advantages of such a design to some fellow programmers and was calling it MVVM but I'm now of the opinion that's not right and the MVVM pattern is where the view stage is refining the model for its own purposes rather than changing what's passed between the Controller and the View.
Of course it all gets confusing with the number of M's and V's and rather than getting tied up in more knots I thought I'd ask the experts.
Its called MVC. No, seriously. Your website's models just happen to be called ViewModels.
MVC doesn't say what the model is supposed to be, just how its supposed to interact with M and C.
As you might have read or experienced that Automapper is used to map objects. When it comes to MVC, the V (View) and C (Controller) are pretty clear. What confuses many people is the M (Model). MVC doesn't lay strong emphasis on how model should be contructed. You can construct your models by running a direct SQL query or using an ORM tool like NHibernate or LINQ2SQL or Entity Framework of your choice.
If you really want to separate the concerns you can go a step ahead and do what most people do. You can introduce repository pattern to handle model data which can be retrieved using a service. This is the situation where Automapper would come into the picture where you need to map entities and Dto's.
I don't think there is any need to abbriviate this method of building models from service layer. The normal MVC stands valid in this case as well :)
The "Related" questions provided me with the best answer I think I'm going to get.
The design pattern is defined fairly well in the article How we do MVC – View models and the appropriate monica seems to be MVC-ViewModels or MVC-VM.
Could someone please explain MVC to me in Ruby on Rails, in layman terms. I am especially interested in understanding the Model in MVC (can't get my head around the model).
Some background, MVC is a (compound) design pattern and was developed in 1979 by Trygve Reenskaug (Smalltalk).
True MVC was primarily planned for use in n-tier (non web) systems and it splits a system into 3 distinct parts, a Model, View and Controller
The Model
Contains data for the application (often linked to a database)
Contains state of the application (e.g. what orders a customer has)
Contains all business logic
Notifies the View of state changes (** not true of ROR, see below)
No knowledge of user interfaces, so it can be reused
The View
Generates the user interface which presents data to the user
Passive, i.e. doesn’t do any processing
Views work is done once the data is displayed to the user.
Many views can access the same model for different reasons
The Controller
Receive events from the outside world (usually through views)
Interact with the model
Displays the appropriate view to the user
** Classic MVC is not suited to web applications, as the model cannot send all changes to the view in an observer fashion (the view is a web page). The Model2 was introduced to overcome the changing infrastructure by JSP team in 90s . MVC Web frameworks are really not MVC, but Model2 (this is true of Ruby on Rails).
Here is a description of GUI patterns including MVC from the master, Martin Fowler
GUI Architectures
The best book I have found so far is Agile Web Development with Rails. It begins by assuming no knowledge, and is quite comprehensive.
Hope this helps to shed some light for you!
MVC basically indicates Model-View-Controller. And MVC used by many languages like PHP, Perl, Python etc. Generally MVC works like this:
Request first comes to the controller, controller finds and appropriate view and interacts with model, model interacts with your database and send the response to controller then controller based on the response give the output parameter to view.
Your Model is the data structure that your program uses.
The View is the part that interacts with the screen or the next level up.
The Controller generally processes data between the model and view
MVC structures are often nested, so a "Model" or "View" may contain its own MVC (Think of a component on the screen. You may just fill it with a string, but behind the scenes the code of the component draws its own little view, has it's own little model (the string you pass in) and has a little controller drawing the data onto the view.
In Rails, the roles of the model, view and controller are well-defined by the framework, any tutorial will point out the three components as it walks you through the files it created.
In other systems, those pieces may be harder to identify. Also, MVC is not "Perfect", just keep in mind that there are valid alternatives, but it's a good way to start organizing.
The Model View Controller principle divides the work of an application into 3 separate but closely cooperative subsystems.
Model (ActiveRecord ):
It maintains the relationship between the objects and the database and handles validation, association, transactions, and more.
This subsystem is implemented in ActiveRecord library, which provides an interface and binding between the tables in a relational database and the Ruby program code that manipulates database records. Ruby method names are automatically generated from the field names of database tables.
View ( ActionView ):
It is a presentation of data in a particular format, triggered by a controller's decision to present the data. They are script-based template systems like JSP, ASP, PHP, and very easy to integrate with AJAX technology.
This subsystem is implemented in ActionView library, which is an Embedded Ruby (ERb) based system for defining presentation templates for data presentation. Every Web connection to a Rails application results in the displaying of a view.
Controller ( ActionController ):
The facility within the application that directs traffic, on the one hand, querying the models for specific data, and on the other hand, organizing that data (searching, sorting, messaging it) into a form that fits the needs of a given view.
This subsystem is implemented in ActionController, which is a data broker sitting between ActiveRecord (the database interface) and ActionView (the presentation engine).
Check the links below for clear understanding of mvc in rails:
http://www.bogotobogo.com/RubyOnRails/RubyOnRails_Model_View_Controller_MVC.php
https://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
I think the best way to wrap your head around MVC is by example. Try coding up a simple Rails app using MVC. There are many tutorials online, such as the blog example at "Getting Started with Rails".
If chose to learn by coding an example, check out the answers to Where can I find clear examples of MVC?
MVC isn't specifically just for Ruby on Rails. It was actually created awhile before Ruby on Rails ever came around. It's mainly just a way of organizing your code so that you have some code that's responsible for your models (the Class version of a database table), some code that's responsible for your views (what's visually being displayed to the user) and code that's responsible for your controllers (what ties the views to the models and performs the bulk of your logic.
That's the non-framework-specific description. Each framework that uses MVC has a different way of implementing it. For Ruby on Rails each model represents a database table as a class that can communicate directly in code with other objects without needing to write any SQL. All the SQL is being taken care of in the background and you just have to think of it as though it were a normal class (well almost, it's not seamless yet). The view is mostly HTML and represents what will be sent to the browser. The controller is just the code that communicates the models and views together.
All in all, MVC isn't specific just to Ruby on Rails...that's just the most popular.
Ruby on Rails does not implement the MVC design pattern. Ruby on Rails has folders called controllers, models, and views. The views folder has HTML files. The controllers and models folder have ruby files. The controllers map to a URL and a method in the controller gets executed upon requesting that URL, the associated view (HTML file) gets loaded and the model (data structure) for it is used to populate the view. Thats the extent of it's likeness to the MVC design pattern. It's a shame that people say it's MVC because it's caused a generation of confusion and misunderstanding of the MVC design pattern.
In Rails, the model is a data structure.
Here's a brief overview at a high level on how the MVC Pattern works:
Controller:
Listens on some kind of interaction/event stream.
Controller can send the model that type of interaction/event.
Controller can also communicate with the the view.
Model:
Models will listen in on the interaction/event from the controller.
Is an abstraction of a data source.
Handles data logic and manipulation.
After it is done with logic, it then sends to controller which will then communicate with the view.
View:
View can communicate with the controller.
Knows how to render data from the Model to the browser visually.
The Controller tells to View to do something with something from the
Model.
A couple of things to note is that models can't communicate with views directly and vise versa. Only the controller can communicate with the view and model, so the controller acts as the delegator for the interaction/event retrieved from users interaction on the browser.
check this link for more clear understanding
one more link to get clear