Why a developer should pay attention to Model-view-controller for designing a GUI? and is there other elements that a developer should pay attention for designing a GUI?
If you don't separate your model from your view, you will have great difficulty refactoring later when you find that you want to present the same information in a different way.
MVC doesn't really have much to do with the interface design so much as the implementation and interaction with the business logic of your application.
http://en.wikipedia.org/wiki/Model–view–controller
MVC will help you to separate the responsabilities of the GUI with respect of the business rules you want, maybe later you want to reuse some code or change it, having an MVC will help you.
Here are other architectures for GUI's from Martin Fowler.
http://martinfowler.com/eaaDev/uiArchs.html
Model-View-Presenter (MVP)
Humble View
And more.
MVC is the need of modern application developement. Take look at Model-View-Controller.
SUMMARY:
How do you modularize the user interface functionality of a Web application so that you can easily modify the individual parts?
The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes [Burbeck92]:
- Model. The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the
controller).- View. The view manages the display of information.
- Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.
Model View Controller architecture simply implies separation between:
1. Data (Model) 2. User interface (View) 3. Logic of the application (Controller)
It's advantages might not be visible in minor projects. However, as others mention, MVC comes in handy when working in a team and especially when the app needs to be scaled.
Another technique you want to familiarize yourself with is Object Relational Mapper. It is a set of classes that provide object oriented interface for a database.
These are good answers, and I would agree with them, except I stumbled on another way to do it, and now I'd rather dig ditches than have to use MVC.
I know you tagged this as java, but this could also be applied to JavaFX or even a web based application.
One currently popular technique with WPF is the Model-View-ViewModel, here;
- Model represents your business tier, here your business logic resides, this is completely agnostic of your UI
- View is the user interface component of your control, mainly going to be XAML markup
- ViewModel: is the data component that your UI will interact with, this is where you will also define your commands to interact with the Model. This could be thought of as the controller in some respects, but it has state, where a controller doesn't typically have a lot of state.
Model-view-controller is one of the more commonly-used ways of encapsulating the different parts of a program, but it is by no means the only way; there are many other options. For example, many GUI systems use widgets + styles rather than views + controllers. The combined functionality comes out to about the same thing, but the separation of responsibilities is subtly different. In widgets + styles, the visual representation of each widget is strongly linked to its actions (sort of like a bunch of tiny view + controller systems). The overall look and feel of the application is determined by a style (this is what makes the visual system cohesive, whereas in the MVC the view is what makes the visual system cohesive).
MVC is very common because it is generally simple to understand and maintain, and is widely applicable. My advice is to learn it well and use it often. But I also warn against letting it become your "hammer" (when all you have is a hammer, everything starts looking like a nail). Become aware of other options and use them when appropriate.