I'm reasonably comfortable with javascript and php; I'd say I'm an intermediate. I'm starting a new project that really does need to be built in something like an MVC framework. I've been looking into backbone.js, but for some reason the logic is just not sticking. I've poked around with OOPHP and of course working with jQuery, a certain level of "objectness" is inherent... but I can't quite get my hands around the basic methodology of something like backbone.js.
Is there somewhere else I should start? A simpler MVC or maybe a good resource that I can work with that will help the concepts and methods stick?
It's just such a paradigm shift. Compared to all the procedural stuff I've done thus far, it really is like learning a new language.
Also, I won't be using a RESTful interface or anything, just good ole fashioned saving stuff to MYSQL via php.
If you are interested in learning the MVC approach using javascript, I would suggest to read Javascript Web Applications. You will also find a chapter on Backbone.
Take also a look at Backbone Patterns.
Well,
technically backbone.js is a variant on the whole MVC concept. Backbone uses a model-view-collection concept rather than model-view-controller. where the view, takes over some work of what the controller in real mvc would do.
it's not a bad thing, in my opinion javascript was never even intended to do such a thing :)
and if you're not used to programming in MVC you might not even notice the difference.
though if you want to start with a few simple examples, around backbone.js i suggest you take a look at this website http://www.backbonetutorials.com/ which gives you a kickstart into building model-view-collection apps (as backbone does it). then when you grasp the concept, you can hop on to the examples given on the backbone.js website. especially the Todo Application which has also provided the annotated source of the object. it's a fully working simple application, which might give you an idea of how it should work rather than having these separated examples. but you have to start somewhere.
Backbone is not an implementation of the MVC pattern. It's better instead to think of it as a MV* implementation, where it has models, but no controller, and its views are often implemented as a combination of view, controller, and presenter, and there is no strict controller or presenter or viewmodel. Understanding that is definitely the first thing to realize when feeling confused about backbone and trying to understand how to use it when referencing the MVC pattern.
The MVC, MVP, MVVM, and MV* patterns are difficult to truly grok with just reading an article or two, or with a simple example, and it seems like everyone has a similar yet slightly different idea of exactly what they are.
For a really really good discussion of MVP and MVC in relation to backbone, read Addy Osmani's article on developing backbone applications Here.
But if you are simply concerned about how to use backbone, and feel like you have to be a MVC expert to do it correctly, then you're worrying about the wrong thing. Instead, look at existing published backbone examples, follow those patterns, and as you add code to your view and model, keep the following points in mind for every piece of code you write:
Is this view specific code? Then put it in the view.
Is this data specific code? Then put it in the model.
Is this code about coordinating the view and model? Tend toward putting that in the view.
A good guideline for # 1 and 2 above, is to not allow your model to reference the DOM at all, then put all the code you can in the model. And only code that has to reference the DOM goes in the view. If you try for that goal, and only violate it when it's obvious that the code is way more convoluted if you put it in the model, then you should be pretty good.
Related
Once again, an MVC-related question. A few days ago I started reading the Cocoa Fundamentals Guide from Apple in which Apple explains their implementation of MVC.
In the chapter MVC as a Compound Design Pattern (link), they compare two MVC-versions:
The old / traditional SmallTalk version:
The current Apple-defined version:
They describe this current model as follows:
The controller object in this compound design pattern incorporates the
Mediator pattern as well as the Strategy pattern; it mediates the flow
of data between model and view objects in both directions. Changes in
model state are communicated to view objects through the controller
objects of an application.
The traditional pattern looks like MVC, nothing wrong. But the name of their current pattern confuses me. In my knowledge this could be seen as plain MVP because the Controller always seems to mediate between View and Model.
Am I completely wrong, do I misunderstand MVC or MVP? Or did Apple just use the wrong name for this pattern? And more importantly, WHY is this current pattern called MVC?
You're not wrong, but nor is the author of the Apple documentation.
The history of MVC is now long and complex -- not least because many systems advocated a tripartite separation which actually muddling the controller into the model or mixing the controller into the view. From the very early Smalltalk implementations, it became clear that keeping model information out of the view was a very good thing, and that this was fairly easy to do.
Cleanly separating the responsibilities of the controller and the view, on the other hand, is much less straightforward. Lots of views want to be reused, like buttons or textfields. The reusable part of their controllers wants to be reused too. But you don't PUSH a textfield or BOLD a button; lots of the button behavior is tied pretty closely to the view. At the same time, it can be hard to be sure when a business rule belongs in the model and when it belongs in the controller.
In addition, this (very good) Apple document is trying to capture a philosophical design idea, not describing The One True Way. Lots of Cocoa controllers subsystems look a lot like traditional MVC. Traditional cocoa deemphasized controllers, so this document is, in essence, arguing to give them a place as mediators between (reusable) views and (potentially reusable) models.
Lots of Cocoa implementors prefer thin controllers, essentially working as façades to decouple view and model.
Since MVP is a subset of MVC it's not surprising to find it in MVC systems. Yes, that second diagram illustrates the MVP pattern.
Apple calls it a mediating controller which – I synthesize – is just another name for MVP.
Frankly I'm not sure the term MVP ought to catch on. It implies it's a totally different pattern, and presenter seems focused on the UI, when sometimes it's just a relationship between model and controller. Mediating controller describes the distinction quite simply.
I had to look up MVP even to know what the heck you were asking about. The term was used in a paper in 1996. When OS X was released it would still have been new.
I'm not sure it's an acceptabale question for Stackoverflow but I have difficult time to understand the MVC structure of ExtJS so I decided to post a question, mainly because this part from the official ExtJS 4.0 tutorial "Every application works the same way so you only have to learn it once" so that is what I really want and intend to do - put more effornt on understanding how the ExtJS work and then I'm pretty sure writing the code will become a ton more easier.
I've learned MVC moslty from CodeIgniter and it was fairly simple to understand the logic behind "M", "V" and "C". However in ExtJS it's not like that mostly because we have stores which are the topic that confuses me most.What's the logic ot having store in MVC model, shouldn't it be a part from the "M" or the "C" and if someone want to spare the time, I would pretty much appretiate an explanation why exactly we need a store defined outside the main MVC structure.
Thanks
Leron
I would agree with comments by #Molecule Man and with opinions expressed in that Sencha thread.
Don't worry about naming. Think about stores as part of model in MVC. Only time you need to add special logic to the store classes if you have custom communication layer (and standard JSON, AJAX stores are not enough). And stores are not really part of your application business logic, so they don't need to be part of controllers.
I notice 2 distinct "flavors" of MVC:
1) "Original" MVC where the Model talks directly to the View
2) "Apple Cocoa" MVC where the Controller uses the Mediator pattern and Model and View never communicate directly
From link text:
The goal of MVC is, by decoupling models and views, to reduce the complexity in architectural design and to increase flexibility and maintainability of code.
That makes great sense to me. However with #1, as shown on wikipedia, you have a link between Model and View and therefore they seem quite coupled to me. It seems like "original" MVC does not solve it's goal.
In contrast, #2 to me very clearly results in a generic View that only knows how to display and input data via UI, a Model that does not care at all about how it is represented, and a Controller that knows about both and becomes the only potentially un-reusable code. It achieves the MVC goal.
This is good for me because I'm working in Cocoa which "Believes in" #2, and I'm working in plain C++ which I can make believe in anything. But which of these MVC flavors will I find out in the wild more? For instance, Ruby on Rails, Struts, PureMVC.. these "use MVC" but would I expect to see #1 or #2 there?
EDIT: Sounds like #2 is the more accepted one, so does any modern approach use #1, if so then what?
I'm not sure what's more universally accepted, but most people see Rails as being pretty much the 'spec' for MVC, and in Rails the model and view never (almost never) talk directly. The controller does all the finding and sending of model data to the view.
In asp.net Mvc the #2 approach is taken: the controller reads and writes from/to the model, sends and receives data to/from the views. Views and models never talk directly.
Looking at examples and tutorials for some MVC libraries for web development on the Internet, I found that many of them construct HTML directly in the code of Model class and then Controller just sends it to the View which just displays it. While this makes Controller and View very simple and clean, I feel it is a wrong approach. IMHO, Model should just retrieve data, without having any representation logic in it. Controller should pass this data to the View, and View would contain the code that iterates through it and generates final HTML.
Is my thinking correct, or am I missing some important point here?
Presentation logic is shared between the view (most of it) and controller. The model should not concern itself with presentation logic.
If it does, you don't have separation of concerns. This isn't inherently a bad thing, but you miss the advantages of having presentation and business logic separated. So no, it's not a good idea.
This being said, there are elements of presentation logic that may get to the model. Think of a cms. Idealy you would have all the data marked up, let's say xml, on which you would apply a template to deliver it. But the data, and the template are kept in the model. So what is presentation, and what is business here?
There are gray areas, but most of the times is easy to separate presentation and business logic.
Your thinking is absolutely correct. If you want a clean separations of concerns it is best to have the View generate HTML from Model. In some cases html helpers could be used.
Is fetching HTML directly from Model (MVC) a good idea?
My gut instinct would say no. Breaks the concept of separation of concerns.
I just read a blog post that explains MVC with a banking analogy. I have a few months of experience with web application development with an MVC framework (CakePHP), so I get the basics, but I began to see a theme that made me think I'm taking a flawed approach to where I put my logic:
Fat models, skinny controllers
Keep as much business logic in the models as possible
In my app, models are anorexic and controllers are obese. I have all business logic in the controllers and nothing besides associations and validation rules in the models.
Scanning through my controllers, I can now identify a lot of logic that should probably go in a model:
The app has lists, which contain items, and the items can be ranked. The sorting logic which puts the list in ranked order is in a controller.
Similarly, items (Item model) also have images (Image model). Each item may have a default image (designated by image_id in the items table). When an item is displayed with its images, the default image should appear first. I have the logic that does this in a controller.
When a list is displayed, related lists are displayed in the sidebar. The logic to determine which lists are related is in a controller.
Now to my questions:
With the examples I gave above, am I on the right track in thinking that those are instances of logic presently in a controller that belongs in a model?
What are some other areas of logic, common to web apps, that should go into models?
I'm sure identifying this problem and changing my design pattern is half the battle, but even if I decide to take those examples I gave above and try to move that logic to a model, I wouldn't know where to begin. Can anyone point me in the right direction by posting some code here, or linking to some good learning resources? CakePHP specific help would be great, but I'm sure anything MVC will suffice.
It's a bit tough to give you the "right" answers, since some of them deal with the specifics of the framework (regardless of the ones you are working with).
At least in terms of CakePHP:
Yes
Anything that deals with data or data manipulation should be in a model. In terms of CakePHP what about a simple find() method? ... If there is a chance that it will do something "special" (i.e. recall a specific set of 'condition'), which you might need elsewhere, that's a good excuse to wrap inside a model's method.
Unfortunately there is never an easy answer, and refactoring of the code is a natural process. Sometimes you just wake up an go: "holy macaroni... that should be in the model!" (well maybe you don't do that, but I have :))
I'm using at least these two 'tests' to check if my logic is in the right place:
1) If I write a unittest, is is easy to only create the one 'real' object to do the test on (= the object that you are using in production) and not include lots of others, except for maybe some value objects. Needing both an actual model object and an actual controller object to do a test could be a signal you need to move functionality.
2) Ask myself the question: what if I added another way to use these classes, would I need to duplicate functionality in a way that is nearly copy-paste? ... That's also probably a good reason to move that functionality.
also interesting: http://www.martinfowler.com/bliki/AnemicDomainModel.html