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.
Related
We have been using ExtJs for a long time, and now, with the advent of MVC pattern in it we are facing a critical question of whether to use it or not in the times ahead given the approach we had been following so far.
In our application, we have similar screens, like 40 similar screens for generating the reports and so on. These report screens would be having a form with buttons - PDF, CSV, EXCEL. All the buttons would be having same functionality at every screen, that is, submit the form to a url and generate the specific report.
The approach which we had been following was to create a custom class, say reportscreen class, which extends the window class of ExtJs.
This custom report screen class would already have buttons with their handlers defined (given the fact that the functionality is similar for them for all the screens) and will also have a form present with a function setFormItems(). Any instance of this class would provide the items for the form using setFormItems() and the url for generating the report.
This approach not only helps us in reducing the development effort to a great extent, but also allows even a new member of the team to use the class & create a new screen.
Now comes in MVC, the most advised pattern, and the approach shared above is definitely not as per MVC pattern. But then, do we need to really move to MVC pattern here?
Using the above approach, we are not only able to save the effort, but also have a greater control over things.
The purpose of asking this questions is to know about the exact advantages we shall get if we implement the above scenario using MVC pattern and move away from our current approach.
Thus, what extra things would MVC bring to the table in the context above? And also, what would be the best way to implement such a thing in MVC pattern?
Thanks for any help in advance.
Do you need to use MVC? No. Assuming you've already got a structure that works well for you, if it's not broke, don't fix it. If you were starting a new project I'd recommend using MVC, but I wouldn't refactor a whole bunch of code for the sake of it. If you did use MVC, you would follow a similar approach. You'd have a base view class where you dynamically push on the items in the subclass. You'd have a base controller to handle all the custom events, then subclass controllers to implement custom functionality on a "per module" basis.
It's hard to explain the advantages of using MVC to someone who had no experience with it. As someone who developed with both ExtJs 3 and 4 (with MVC), I think one of the greatest advantages of MVC is that it forces you to think right - whether you want it or not, using MVC is likely to result in code base that is more reusable and better encapsulated. But if you boys and girls are good programmers/designers, this will be the case anyway.
If you do choose to move to MVC, I believe that the main change will be in that now instead of handling user interaction within your custom class, you will have a single controller to do the same job - leaving your custom class to realize the view only. Controllers in ExtJs4 are global - meaning that the same controller may control 40 similar views. So no duplication of controllers here.
It's important to mention that even within an MVC design you will find non-MVC code. For example, I have a custom record editor which is a form - the component knows how to handle user actions and update the records accordingly (the form is not submitted as it's mostly dealing with associations). This component takes the equivalent role of both the controller and the view within an MVC design. It seems to me more than reasonable to encapsulate things this way, rather than split this to a view and a controller. But the (non-reusable) user screens are implemented using MVC. So maybe just another reason not to rush to MVC.
While I agree with Evan that if it aint broken don't fix it, had I been your development leader and given time and money is not an issue, I would actually request the gradual migration to MVC - overall I think that 3 years down the line you won't regret this decision. I would at least attempt it.
When ExtJs 4 came out I scraped 2 months of work to rewrite from scratch a system using MVC - I don't regret this for a second now (I did at the beginning, but not for MVC - rather for the amount of bugs in the early versions of 4).
Please excuse the verbosity here but I need to be detailed.
I recently built a framework that uses a somewhat unconventional pattern. Essentially it's pull based from the view. Rails, imo, is a push based pattern. You push data from the model through the controller onto the view.
In my design the view requests data using custom Liquid (liquidmarkup.org) tags & drops. That triggers calls to backend API's (or return from memcache) which returns JSON which gets converted into ruby Arrays and Hashes which Liquid can iterate through and use as objects within the view. No business logic in the view. It's purely pull.
When the user posts something, a handler (aka controller, but only for PUTS & POSTS) deals with validation & passing along data again to the back-end services. Depending on the outcome the user can be redirected, rendered a page, etc...
The major advantage to this approach is that our frontend guys can design without us stepping on each others toes and also fits in nicely with our SOA environment.
My question... What, if any, design pattern does this resemble or is it a combination? Does anybody know of comparable frameworks using a similar approach? I'd really like to get ideas on improving this architecture and maybe even one day build an open source version. It's worked brilliantly for us so far.
I look forward to your comments.
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.
I am contemplating about using an MVC pattern in my new project and I can clearly see the main advantage of being able to put the data layer (the model) a little closer to the presentation layer (the view), which will allow a little increase in application speed. But apart from performance stand point are there any other advantages of MVC over the view-logic-data layered type pattern?
EDIT:
For those who's interested I just uploaded a sample PHP code that I created to test the use of MVC. I purposly omitted all the security checks to make the code a little easier to read. Please don't critisize it too much, because I know it could be a lot more refined and advanced, but nevertheless - it works!!! I will welcome questions and suggestions: Here is the link: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip
The separation of concerns that's quoted as being an advantage of MVC is actually also an advance of a 3-layer/3-tier system. There too, the business logic is independent and can be used from different presentation tiers.
A main difference is that in classic MVC the model can have a reference back to the view. This means when data is updated the model can push this data back to possibly multiple views. The prime example is a desktop application where data is visualized in multiple ways. This can be as simple as a table and graph. A change in the table (which is a change in one view) is first pushed via the controller to the model, which then pushes it back to the graph (the other view). The graph then updates itself.
Since desktop development is on the decline, a lot of programmers have only come in touch with MVC in some web variant, e.g. via JSF in Java EE.
In those cases the model almost never has a reference to the view. This is because the web is mainly request/response based and after a request has been served, the server cannot send additional information. I.e. an update pushed from the model to the client would be meaningless. With reverse ajax/comet this is changing, but many web based MVC frameworks still don't fully utilize this.
Thus, in the case of web based MVC, the typical "triangle" between M, V and C is less there and that MVC variant is actually closer to an n-tier model than 'true' MVC is.
Also note that some web MVC frameworks have an intermediate plumbing part between M, V and C called a backing bean (Java/JSF) or code behind (ASP.NET). In JSF the controller is provided by the framework, and the view often doesn't bind directly to the model but uses this backing bean as an intermediary. The backing bean is very slim and basically just pre-fetches data from the model one way and translates model specific messages (e.g. exceptions) into view specific messages (e.g. some human readable text).
Beside
code reuse,
separating of concerns,
less coupling between the layers,
already mentioned by #bakoyaro and #arjan
i think that MVC is better than 3-tier when combined with the "convention over configuration" pattern. (i.e. "ruby on rails" or Microsofts "MVC for asp.net").
In my opinion this combination leads to to better and easier code maintanance.
In the first place it makes learning the mvc-framework a bit more difficuilt since you have to learn the conventions (a la controllers go into the controllers folder and must be named xxxxxcontroller)
But after you learned the conventions it is easier to maintain your own and foreign code.
Forget increasing application speed by moving to MVC. I have found the biggest benefit to be ease of code reuse. Once you move to MVC, there are no dependencies on the presentation of your data or the storage of the actual data.
For example you could write a servlet that served up .jsp pages as your presentation layer one day, and the next day write a web service as another presentation layer to your existing Model and Controller. Like wise if you want or need to switch your DBMS. Since accessing the Model is completely separate from everything else, you would just need to re-write just your data access objects to return the data in a way your Controller can handle it.
By separating concerns into 3 distinct pieces, you also facilitate true unit testing. Your Presentation layer can be tested free of the Model or Controller, and vice-a-versa.
On a side note, I've often felt that the MVC abbreviation was inaccurate. Whenever I see it I think of it as View->Controller->Model. The presentation layer will never have DAO code in it, and the model will never have presentation logic in it. The Controller is forced to act as a go-between.
Where 3-tier separates presentation from business and data access, MVC is a presentation layer pattern which further separates Model (data) from View (screen) and Controller (input).
There is no choosing MVC over 3-tier/3-layered. Use them both.
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.