Application of MVC mode in J2ME project (1)
Author: FavoYang Email:
Favoyang@yahoo.com Welcome to exchange
Keywords: MVC J2ME UI mode
Summary:
This paper briefly introduces the idea of MVC mode, and analyzes the pros and cons of MVC mode, and finally combined with the MIDP platform to give several common MVC mode practices. Believe this article for any more or less business program developers using the MIDP platform.
Copyright Notice:
This article is also published
Www.j2medev.com and my blog (blog.9cbs.net/alikeboy), if you need to reprint, there are three ways: 1) Contact me and agree; 2) and www.j2medev.com has reprinting article cooperation agreements 3) Aggregate my blog through RSS. In addition, the online reprint requires a full text forwarding (including the statement of the head of the article), do not break chapter.
text:
First knowledge MVC mode
The first time I realized that the MVC mode started from the "Document-View" model used by the Microsoft MFC framework. The first time I came into contact with this concept, I was excited. I had a long time to trouble my program framework problem seems to be solved. Then I read the description of the MVC mode in the GOF book, enhanced some understanding of this mode. It should be said that the MVC framework is the evergreen tree in the field of programming, and is one of the most important modes in the GOF mode. This classic model is widely used, with too many program frameworks under this framework, from the early Expectation Application to the popular web. Different from their respective demands, MVC has a lot of variants. Understanding MVC is a compulsory course for each program designer, it is best to achieve proficiency.
I don't plan to introduce this model in detail, because the details are more complicated, my tongue is not easy to say clearly, everyone should see the books about the model, any one is better than I want. So therefore. The MVC mode is the abbreviation of Model-View-Controller, in Chinese to "Model - View-Controller". The core idea of MVC is separation. Model is an abstraction of the entity class; View is the representation of Model on the screen; Controller is the coordinator. There may be a friend to find that the description of Controller is a bit vague, don't worry, this will still talk. Probably because of being too famous, every implementation of MVC mode is very large, but they are called MVC! ! Get the foggy of beginners. Often abuse, finally made M.V.c. The coordination between the three is very confusing. This is actually not their fault, and the key to the idea is the word "separation" just mentioned. Although the MVC is different, the idea is consistent.
Proficiency of MVC mode
First talk about the advantages:
1) M.V.c. Separation allows different experts to be responsible for different modules, in general, the M part is responsible for experts who are familiar with the database, network transmission; v is handed over to the expert in the UI research. This is a tempting for the administrator of the project, and the division of labor means improving efficiency and can handle software development processes in accordance with traditional responsibility. For developers, you can concentrate on a field. The premise of this is that the interface should be clear, and the Separation of MVC is providing the basis for it.
2) Once the portion v is changed, it can be reconstructed without having to cause rework of the entire project. Today's software performance layer is too fast ...
3) The part of M, because it is enough to be abstract, can be easily reused, in line with OO's idea. On the other hand, we can use JUnit and other unit test tools to test M to ensure engineering quality.
After talking about the advantages, let's take a look at the shortcomings:
1) Use the MVC mode (also including modern modes), implies that we have produced some classes to improve the readability and robustness of the program. The disadvantage of the attached is the expansion of the number of classes. Said joke, MVC is like a quick-ended powder when it is sent, is the most convenient code expansion agent. I believe that everyone will experience:) 2) Although MVC has defined the meaning of MVC components, it is not specific And there is no very clear connection between the three. So, in addition to the view of View, there are many arguments in other respects, everyone wants to make their own understanding as a positive solution. In particular, "MODEL is the collection of screen data or entity data", "The role of the controller" is the problem of two frequent debates. The front mention of MVC varies a lot, which also left a lot of traps to beginners. The following combinations will analyze several common practices.
3) The implementation cost of MVC is high. But please note that this is relative, the greater the project, the more you can see its advantage.
Common MVC mode practice
Here will be introduced in several common practice in the MIDP platform, and finally the practice I am used to
M-V form
(Or MC-V
, M-VC
)
This is also a usual method in J2ME, refining this method is to make the development idea of the RAD tool with the screen as an organizational unit. A screen and its control are abstracted into a VC class, and this class has a private model object to represent the data elements you want to use on the screen. The screen object does not save any entity data, which is organized in the Model object. Probably because the screen object is very intuitive, the role of the controller does not clearly (which most of its function is replaced by VIEW or Model, which is often called Model-View mode. The form is as follows:
Class Myframe Extend Frame {
PRIVATE Model Model;
Private stringItem name;
Myframe (Model Model) {
THIS.MODEL = Model;
Name = new stringItem (Model.getName ()); // Request the data of the model
Append (name);
}
}
Class model {
Private string name = "m-c pattern";
Public string getName () {// This is a service interface
Return Name;
}
}
What is seen above is a typical M-V model, we can understand this meaning of the screen as the core. MODEL organizes the screen's data, view to Model to the data you want to display, pay attention to this operation must be accessed by a pre-negotiated interface instead of direct operation. If there is a complex transaction logic (some of the user selected), someone places it in the Model side, and some people are placed on the View terminal, but generally placed in the Model side, then Model has a serious Controller color.
This kind of form is very intuitive, and the display and data are limited. If you often look at the J2Medev.com webmaster Mingjava's article, you can see that most of the examples of his writing are this model. And this model is often used in the RAD tool.
The disadvantage of this mode is that it encourages you to think about problems from the screen as the RAD tool, which often caught the trap of the RAD - not to consider the process of affairs, but directly from the user interface to analyze the problem, this often kills Your global thinking.
Sun Blueprints: Smart Ticket
MVC mode used in
The famous Blue Map Program Smart Ticket uses the MVC mode, and this mode helps Sun's programmers are released when the MIDP2 is released, and quickly updates the Smart Ticket's View section from MIDP2.0. Sun is designed and improves this mode for MIDP, which is a very standard method in Sun's solution. It is only a huge transaction processor, all the needs of users collected by the UI object. Forward to Controller processing. A set of constants is saved inside the Controller. A huge Switch Case statement in a DISPOSE (Int ID) process handles different requests based on comparing different constants. This technique sometimes refers to Controller as a processor, or a screen navigator. The proposal of this mode is mainly to centrally process frequent picture navigation in J2ME.
Many people think that in J2ME transforms Controller into huge transaction processors, it is a good way. I have reserved advice on it.
Ifeedback
Simplified MVC
In order to greatly reduce the number of classes, IFEEDBACK's author, encapsulate MVC into a class, representing different methods to represent the separation of these three, this actions have proven to be helpful for reducing the number of classes.
Public Abstract Class MVCCComponent imports commandlistener {
// set from outside at beginning
Public static display display;
// Returns the screen object from the derived class
Public Abstract Displayable getScreen ();
Public Displayable PrepareScreen () throws exception {
IF (getScreen () == NULL) {
INITMODEL ();
CreateView ();
} else {
UpdateView ();
}
GetScreen (). setcommandlistener (CommandListener);
Return getscreen ();
}
Public void showscreen () {
Try {
Display.setcurrent (pre correspondscreen ());
} catch (exception e) {
E.PrintStackTrace ();
Alert a = new alert ("Error In Showing Screen");
a.SetTimeout; Alert.Forever
Display.SetCurrent (a);
}
}
// Initialize. If a data member is not backed by RMS, Make Sure
// IT is uninitilzed (null) Before you put in value.
Protected abstract void initmodel () throws exception
Protected Abstract Void CreateView () Throws Exception
Protected abstract void updateview () throws exception
Public Abstract Void CommandAction (Command C, Displayable S);
}
Because everything is in a class, you don't have to worry about the relationship between the three of the MVC, this degradation practice is a compromise on MIDP limited resources.
My customary practice
Believe in me to understand the MVC understanding and everyone. I am using a UML standard practice, and the idea of reflecting separation is maximized. First, talk to everyone, the word gap: View represents the screen.
View is requested by using the Controller as data by preloading, and the view collects the user's input, and the view does not process these inputs, but different from different input callback controller. Usually the subclass of View uses a UI suffix.
Controller controller
Provide interface-called interfaces, responsible for communicating with Model. Controller and View work together and user exchange.
Model refers to a series of entity objects
What to pay attention to is that the MODEL I understand is not an organizational unit of screen data. Model represents a series of entity objects. Communicate with Model with Model. I think the Rad tool often forms a collection of MODEL on behalf of the screen data to cause MVC concept confusion. MODEL in the RAD tool, is generally equivalent to the role of Controller here.
The controller does not always contact MODEL, sometimes just dependencies. And Controller often get the Model object through the corresponding life class class of Model. In this form, layer isolation, VIEW is closely connected to Controller, while Model has high independence, which can be reused.
The general binding of the UML design, there is a corresponding naming habit of each class of MVC.
VIEW
Boundary class (boundary) ends with UI
Controller
CONTROLLER
Class (control class) ends with Workflow
Modeel
Entity
Class (physical classes) with Entity or no needle
Model
Lifecycle class (life cycle class) ends with Locator
The base class of boundary classes and control classes is as follows
Baseview.java
/ **
* @Author Favo
*
* View class
* /
Public Abstract Class Baseview {
Public Abstract Display getDisplay ();
/ **
* Simple return screen object, don't do anything to prepare your screen!
* /
Public Abstract Displayable getScreen ();
/ **
* Create screen
* /
Protected Abstract Void CreateView () Throws Exception
/ **
* Update screen
* /
Public Abstract void updateview () throws exception;
/ **
* Return to the controller
* /
Public Abstract BaseController getController ();
/ **
* Prepare the screen
* Return to the ready screen object
* /
Public Displayable PrepareScreen () throws exception {
IF (getScreen () == NULL) {
CreateView ();
} else {
UpdateView ();
}
Return getscreen ();
}
/ **
* Display the current screen
* /
Public void displayscreen () {
Try {
GetDisplay (). setCurrent (PrepareScreen ());
} catch (exception e) {
E.PrintStackTrace ();
Alert Al = New Alert ("Error", E.TOString () '/ n' E.GetMessage (), null, alerttype.error; al.settimeout;
GetDisplay (). setcurrent (al);
}
}
}
BaseController.java
/ **
* @Author Favo
*
* Control class
* /
Public Abstract Class BaseController {
Public Abstract BaseView getView ();
Public Abstract Void SetView (BaseView View);
}
It is noted that the class of these foundations did not generate a complete framework as the MFC framework, but designed to have an abstract class. I hope to force everyone to implement an abstract class (prevent errors); I hope to add a little flexibility. Therefore, the communication between the two classes must rely on the constructor of the subclass written by everyone. Generally, my habit is to initialize the controller, and then use the controller as a constructor to the boundary class, which is implemented by the constructor of the boundary class to the SETVIEW () of the controller. These steps must be, otherwise nullpointerserexcpetion.
Although theoretical may be clear, the complexity brought about by practice is amazing. This is the problem of software development, too many details plague this developer's grasp of the overall situation. This article is next, will combine the final design idea to give a complete design instance. Help you understand this model from the perspective of practice. Please look forward to everyone.
