First, I would like to ask some very basic questions about MVC in general. Simple questions, but can't find any good answer for them.
Is MVC useful for a one man project, or is it only needed, when more people work on a project to make it easier to co-op?
How big a project needs to be, to make good use of MVC. I hear everywere that I should always use MVC, but even for big projects it looks like an overkill. I can't imagine how big something would need to be, for all this overcomplicating to pay off.
I have made a single player rpg that is pretty short, and I am trying to turn it into massive multiplayer. It is all for educational purpose only. So I was thinking to redo it with MVC, but even though it has a lot of functions and data to process it still looks way to simple and clear, to bother with MVC. Maybe if I am making so small projects that I can't see the benefits of using it, I just shouldn't use it?
Will using all the MVC additional code slow down my app in visible way?
Now about Javascript, there are some solutions for MVC avaliable. Are they worth using?
Thanks
MVC is just a pattern, guidelines to organize your project and decoupling your code, so the size of the team or the project is not relevant. I've made by myself a very simple website with a list and a couple of web forms using MVC and it was pretty faster to develop than other alternatives. If you have the opportunity to work with a powerful IDE like Visual Studio, you will find that most of the common things to do for building a web page/site are already automated. And I also have worked with 12 people in a bigger project using also an MVC approach without noticing differences.
One of the main advantages of using MVC is that you can change the whole front end in the future without having to make changes in your model or controller layer.
Also, using MVC doesn't have to slow down your code, it depends on your implementation. When using ASP.MVC instead of ASP.NET, for example, the code and download times are faster, in fact. With ASP.MVC you get rid of nonsense ViewState pieces of code and the html code generated is cleaner.
In my experience, MVC is an excellent pattern to chose for working in web projects, since the front end technologies are changing very fast and it gives the flexibility to evolve with them without having to annoy about the business logic.
I hope I have helped you.
You can find more info in:
http://www.asp.net/mvc
Related
I've been asked at work to convert a popular mechanical engineering excel application to a single page web application. It requires no database so my idea is to put everything on the clientside in javascript.
First version is gonna be pretty small but more complexity will be added further along. Canvas graphics is gonna be drawn in realtime as user changes input. So performance is important. My question is: Should I use a MVC framework such as Angular JS? Or is it better to stick with Jquery? If I should use a MVC, which one is best suited for this app?
Everyone at my company uses IE9 so I dont need any support for older browsers.
Angular bills itself specifically as a way to build CRUD apps - basically database front ends. The app you're describing doesn't sound like it's doing a ton of that, so Angular would probably be more trouble than it's worth.
jQuery is a helper library - it makes dealing with the DOM easier, but doesn't do a thing to provide overall structure to your application. jQuery is a "necessary but not sufficient" in my book - you're going to want it, but it's not enough on its own.
Personally, I'd lean more towards Backbone, specifically because it's so minimal - it gives you some useful data binding stuff and some hints on how to organize your app, then gets out of your way to let you build the abstraction you want. Based on the fact that you mentioned the original is in Excel, some sort of data binding / change notification system is going to be important. This way you can emulate the spreadsheet's "change a cell and the chart redraws" system that everyone's already used to.
In the end it's hard to say without more detail on the app in question, and what kind of calculations / how often they have to happen are. Figure out what your app architecture should be, find (or build) a library that helps implement that architecture. It might be MVCish, it might not.
Well jQuery will get very messy as complexity increases. Angular JS is an amazing library but there are also a myriad of different ones out there. Depending on the Mechanical Engineering principles you are working with using AJAX may prove to be more perform-ant, due to the lack luster power of some older browsers.
It really depends on the complexity of the calculations, but in terms of dealing with events and managin the structure I would suggest using Jquery as well as Angular on top of it. then make the decision about whether or not to move some functions to the server or not, based on performance.
I have a few years' background with server-side MVC app development using CakePHP and a few more with vanilla PHP. Sadly I can't say the same about JS apps, although I do have experience in spicing up static pages with Mootools.
So now I'm trying to study client-side app building and my success so far hasn't been so great. Since the only MVC I've touched is CakePHP, every JS MV* framework seem incomprehensible at best. It doesn't help at all that I've grown so accustomed to writing neat CakePHP and Mootools Class code that big blocks of JS code feel just disorderly.
I've even tried to write my own simple MVC-like lib by imitating CakePHP for mostly academic use. I guess it's needless to say that I haven't really gotten anywhere with it.
Some things I realised while studying and writing my own MVC:
Js is asynchronous. CakePHP works the way it does because PHP is synchronous. In JS there's an endless list of things that need to be implemented differently and about just as long list of things that can be done differently thanks to async. What are the most important differences between server-side MVC(or CakePHP implementation of it) and client-side MV*?
I still don't quite get the concept of client-side models. In Cake they handle data validation and database connections. Client on the other hand is an unsafe environment, so client-side models can only do basic data filtering, pre-validation and default values. Am I completely wrong here?
Some apps require a server counterpart. Should Server also be MVC?
It seems that in client-side MV* you can have multiple controllers simultaneously. Although I kind of understand that it has its uses, my knowledge at this point is so little I can't even think of a better question than "What good does it do?"
I've also downloaded TodoMVC and tried to examine the different frameworks with little success. The main problems with it are that it's only single-page(actions happen at different urls but the layout stays the same) and the implementations are so different that I'm having hard time even comprehending the basics, let alone finding the best suited framework for me. Also, it doesn't communicate with the server in any way, which is a huge disappointment since I'd wanted to see how different frameworks do that.
So, the optimal answer to this question would be a link to a book called Client-side JavaScript MV* For Dummies (Who only have experience in server-side MVC), which would earn you somewhere around 500 internets in addition to the regular StackOverflow rewards.
I would be extremely thankful for any insight(ful links) on any of my ramblingly written question's topics. You will be rewarded with the standard +1s and as a further incentive I promise to write your nickname on a post-it note and keep it on my monitor for the next month. The person with the most helpful answer of course gets an Accepted and additionally may provide a picture to be printed along their nickname to be attached to my monitor.
I'm interested to know where you ended up on this one. PHP was my first love, and while I still enjoy the ease of the language, it's hard to really take it seriously when it so clearly is being phased out for faster, more scalable technologies.
You hit it on the head that javascript's asynchronousness complicates things, but it definitely opens the doors for performance increases. There are quite a few libraries (more for node.js than client side work) that aim to make javascript written as if it's synchronous - again I don't see it helping with your current ask, but it's good to know other's share your pain.
I think MVC in javascript can be thought of like this:
M: the models are simply an explanation of your data. So if you have a person, you can say that every person has a first name that's a string, an age that's an int and so on. Now whenever you create a new person, you can have validation. Models, client side, tend to be very simple, I've found.
V: views are another interesting thing. Some like to have a big set of render functions that contain strings of HTML (ew). Other's like to have the views just be a wrapper for a templating engine like handlebars.js (probably a better solution).
C: functions pretty much identically to a controller in PHP.
My advice for you would be to NOT write you own, but rather take Backbone.js (quicky becoming the industry standard), learn it inside and out, and perhaps build on top of it.
Good luck!
When would one go for using Javascript MVC ? I mean why there was a
need for JS-MVC ?
Is it only because this design pattern was famous in other languages, for code maintenance,readability and many web apps are shipping client side ?
How does it helps a developer, tester and end-user easing their
tasks ?
Any use-case where JS-MVC is suited best and any case where it is
not at all required ?
Question 1,2,4
My view is that you should apply any kind of design pattern only and only if you really need it. Simply because design patterns aren't easy after all. They will add complexity to your solution, but they'll also provide you the benefit of (normally) being established and working solutions for specific kind of problems.
Whether to use or not use them really depends on what you are going to construct and how complex it is. That said, I'm probably not going to structure my 200 lines jQuery plugin using the MVC pattern, maybe...
But at work we create single page applications where we have 2-5 devs working on a project the same time, projects of the amount of 500 days. In such environments things can get complex very quickly and if you don't follow any kind of proper structuring you're lost.
I hope that should answer your question 1 and 2.
For question 3:
The end-user hopefully gets a better quality app with less bugs, but usually he shouldn't even notice (nor does he care) about the underlying architecture of an app.
MVC helps the developer
as an orientation when navigating in the app's source code. Consider an app of 3000 lines of code in a single source file and then when having 4 devs working on it at the same time. A mess, right? When having an MVC app which normally also use routings etc...you normally already know by looking at the route in the url where the corresponding controller lies in the source code and where you should put your hands on
for easier testing. Separation of concerns is always beneficial when applying unit testing practices because you can much easier test your controller because it isn't directly couple to data or presentational stuff (like HTML code etc). And just as a side note, you should definitely unit-test your JavaScript code, definitely!!
maintenance: which is the result of the previous points somehow
I'm not sure which kind of figure you intend by "tester". If he writes automated tests at the unit or acceptance level, then the benefits from before pretty much hold as well. If he's testing the app as a whole in the sense of navigating around, taking the app as a black box by testing its reaction to different kind of inputs, then MVC doesn't really play a big role for him. It's like for the end-user.
So I hope I was able to clarify some things for you. But as said, never just follow a pattern because people follow it but only 'cause it gives you any kind of benefits.
MVC is used to structure your code especially if you are working a lot with client side rendering. Without structure your code gets complex very fast.
User experience for end user is much better when you don't have to wait for the whole page refresh if you only need partial update.
It helps to navigate through the code much faster if you have well defined structure of your code.
JS MVC frameworks are best used where you have complex systems and you want to provide better user experience by using AJAX and partial page reloads or updates. Usually you would not use MVC for Personal website, blogs or stuff like that...
Im working on a framework based off bootstrap that will be used across multiple websites. At the moment im just writing a ton of jQuery functions for different events and doesn't seem scalable at all. I been reading up on MVC for js and not sure when it should be used or if its what I need to start applying.
Any suggestions on when its needed?
The answer to this is simple ... use MVC when your project gets large enough to warrant it. Many patterns can end up being overkill when you're writing a small project, or simple feature. But there will come a time when not using something like MVC to organize your code will result in an unmaintanable mess. It sounds like you're already hitting that point, so it could definitely make sense to put some thought into how you structure your application.
I actually wrote an article on how you can easily use the pattern from javascript without having to bring in any heavyweight external dependencies:
http://codecube.net/2009/06/mvc-pattern-with-javascript/
MVC stands for "Model View Controller" and it is a coding paradigm. You can quite easily apply it on the client using JS for webapplications. Models are just plain old JS objects. Views can be implemented using templates (jQuery has templates, but others such as Mustache, Handlebar or Dust are arguably better). And the Controllers are triggered by events and handle the dataflow and processing.
Take a look at some of the other libraries which help create this sort of structure.
My personal favourite is Backbone.js its pretty lightweight but extremely functional.
IMO the best time for structure is from the start, its easier to add to a code structure from the beginning than it is to make code fit into a structure after the fact.
Personally I think structure whatever the choice is, is important especially in JavaScript (Since its so damned mutable) for maintainability, scalability and just plain old helping other people understand what's going on when they have to do a bug fix in code they didn't write! :)
Disclaimer & Long Winding Question Approaching
I know topics like this have been beaten to death here so suffice to say I'm not asking about which framework is better, I don't really care about opinions on the better framework. They all do pretty amazing things.
The Question
Given that I have an existing web application, made of mostly regular HTML+CSS (jQuery where needed), which is the optimal framework to integrate a few "rich" pages into typically a regular stream of HTML.
Reason
I am trying to bring our proven application into the realm of awesome desktop like UI but I want to do it one small piece, one screen at time. But for our users, support personel and especially me taking it slow is the only option.
Also, with our branding requirements having a framework that just takes over the viewport isn't an option, it has to play nice with other HTML on the screen.
Imagine the example being a rich user manager in an otherwise plain HTML+CSS environment.
Experience Thus Far
Dojo + Dijit
Pros: The new 1.5 widgets plus the claro theme is the cure for what ails us. Dojo seems to be able to use markup to create the UI which is very appealing and has a fair amount of widgets.
Cons: Holy bloated lib Batman! Dojo seems to be enormous and I have to learn a custom build system to get it to stop requesting 4,800 javascript files. This complex empire of Javascript makes me believe I won't be able to create much that isn't already there.
ExtJS
Pros: Amazing set of widgets, does everything we could possibly want. Seems quick, every version brings new improvements.
Cons: I'm not sure how to use this without the entire display being EXT. I'm still building a web site, so I would prefer something that could integrate into what we already have. Some pointers here would be great.
YUI
Pros: Well, it's Yahoo isn't it? AWS console is downright wicked. Plenty of support and a giant community.
Cons: Well, it's Yahoo isn't it? AWS console is the only wicked thing. Complex for someone who's used to jQuery.
Help Me
I am willing to accept experience, links to ways to solve problems I've outlined, new toolkits (even though I'm pretty sure I've seen most by now) or even just advice.
Regarding ExtJS, it's pretty easy to start it in an existing div with something like this:
Ext.onReady(function() {
App = new Ext.Panel({...})
App.render('div-id')
});
The App panel can then have it's own layout manager.
This might be useful if you're familiar with jQuery, but not yet familiar with YUI 3 syntax: http://www.jsrosettastone.com/
Each of the libs you listed is excellent. When embarking on a larger scale project, the quality of a lib's documentation, community, and commitment to support become more relevant.
With Dojo, keep in mind that outside of dojo base, it only ever loads what you tell it to. But yes, without a built layer, that means it could easily end up requesting 50 JS files at startup for a large application using a bunch of widgets.
There are several pages in the reference guide documenting the build script: http://www.dojotoolkit.org/reference-guide/build/index.html
Rebecca Murphey wrote a nice blog post outlining an example app and build profile that you might find illuminative: http://blog.rebeccamurphey.com/scaffolding-a-buildable-dojo-application
If you get stuck, there's likely to be people in the Dojo IRC channel that can help.
RE ExtJS: I'm not sure what your exact situation is, but keep in mind that if you're intending to use it in commercial non-open-source software, you need to pay for licenses: http://www.sencha.com/store/js/
I'm a little curious as to why you think the size / number of requests is specifically an issue with Dojo though. I haven't used the others, but I'd expect it to be somewhat of a potential concern with any of them.