Introduction to the MVC structure in the j2_client

 

 

Model-View-controller (MVC) is a classic UI structure design model. The MVC mode divides an application or application into three parts: Model (model), the subject of the application, including the transaction logic; view (view), representing the user interface; controller, which processes user input and system events, assigns tasks to model services, and updates the corresponding views.

The MVC structure has different levels even in a class. This structure can be implemented based on different functions. Here are some examples-from simplicity to complexity-that will show how to convert all the j2_awv1 clients in the same class into a j2_awv2 [awv2] client integrated with the MVC structure; how the three classes are organized and how the functions in these classes are distributed. The pros and cons of this type are discussed in each client type, which helps developers select the appropriate client type.

All code clients in a class

The concept is simple: put all the code in a class, including Startapp (), pauseapp (), destroyapp (), like the helloworld example. I sometimes write code like this to test the features of a mobile phone, but that's all. Of course it is not a pattern, but it allows us to understand how to generate an MVC pattern from the beginning.

// Code example, items shared in different views

Public void commandaction (command cmd, displayable disp)

{

If (cmd = getcommand & cmdtview = mainform) then

{.}

Else if (cmd = getcommand & export tview = listform) then

{.}

Else {.}

}

Benefits:

The code length is the shortest, because if you abstract them as methods, there will be no repeated code. In fact, some entries can be used in different views.

Disadvantages:

The more views there are, the more complex the class structure will be. The pattern jumping from the control logic will confuse most developers.

View-based components

View-based component implementation class: each view of an application (or several similar views) is designed as a class. In a class, the MVC structure can be implemented based on different functions.

Figure 1 View-based component class diagram

Public class logincomponent extends viewcomponent implements commandlistener {

Public display;

...

// View related functions

Public displayable getview (... );

Public displayable prepareview (){... }

Public void showview (){... }

// Model related functions

Public bolean loginservice (string name, string password ){

...

}

// Controller

Public void commandaction (command C, displayable s ){

...

}

}

Benefits:

The structure is simple and intuitive. It consists of screen views and is easy for developers to understand. Through superclasses, we can place some public interfaces in it, and the code reusability will be higher.

Disadvantages:

Some view-based components may have similar functions, which leads to repeated code in different classes. Repetitive code is the smell of class design, making it difficult for applications to manage.

Model-View
The Model-View structure is the most common structure for the client of the j2_awv3. Entity Data and business logic functions are implemented as model classes.

Figure 2 view-model structure diagram

// View Example, use form as super class of a view

Class unitview extends form implements commandlistener {

Private loginengine engine;

Private string result; [awv4]

...

Unitview (string name; loginengine engine ){

Super (name );

This. Engine = engine;

}

String login (string name, string password ){

Result = model. getservice (name, password );

...

}

...

}

// Model example

Class loginengine {

Public String getservice (string name, string password ){

...

Return result;

}

}

Benefits:

Two or more view objects can share the functions of a model. They are similar to abstract classes.

Disadvantages:

The disadvantage of this structure is that the event processing functions and the screen process logic are distributed in different views. Because each view needs to manage the relationship with other views, if we have n view units, each maintaining a relationship with other views, there is a n * (N-1) relationship chain, but for an intermediary, There is only n relationship chains.

Single controller MVC

A single controller, also known as a System Controller, is responsible for receiving and processing all system events. Normally, the Controller allocates a lot of work to the model, controls the screen flow, and processes and distributes system events. In the smart ticket, sun's famous blueprint for j2_awv5, a large switching function is used as the core of a single controller.

Figure 3 MVC model class diagram

Figure 4 Timing Diagram of the MVC object

// Login View

Public class loginview extends form implements commandlistener {

Controller unicontroller;

Display display;

Mvcmidlet;

Textfield usernamefield;

Textfield passwordfield;

Command logincommand;

Public loginview (String title ){

Super (title );

Unicontroller = controller. getinstance ();

...

This. append (usernamefield );

This. append (passwordfield );

This. addcommand (logincommand );

}

Public void prepareview (display ){

Setcommandlistener (this );

This. Display = display;

}

Public void showview (){

Display. setcurrent (this );

}

Public void commandaction (command C, displayable d ){

If (C = logincommand ){

Event event = new event ();

Event. setbyname ("username", usernamefield. getstring ());

Event. setbyname ("password", passwordfield. getstring ());

Unicontroller. handleevent (event. loginevent, event );

}

...

}

}

// Controller

Public class controller {

Private Static controller instance;

Private display;

Private loginengine;

Private homeview;

Private loginview;

Private errorview;

...

Private controller (){

...

}

Public void Init (MIDlet ){

This. Display = display. getdisplay (MIDlet );

...

}

Public static synchronized controller getinstance (){

If (instance = NULL ){

Instance = new controller ();

}

Return instance;

}

Public void handleevent (INT eventid, event e ){

Switch (eventid ){

Case login_event:

String Password = E. getbyname ("password ");

String username = E. getbyname ("username ");

Boolean result = loginengine. loginservice (username, password );

If (result = true ){

Homeview. prepareview (Display );

Homeview. showview ();

}

Else {

Errorview. prepareview (display, "loginerror ");

Errorview. showview ();

}

Break;

...

}

}

}

// Login Model

Public class loginengine {

Public Boolean loginservice (string username, string password ){

Boolean result =...

...

Return result;

}

}

Benefits:

In the standard MVC structure, business logic (model), presentation logic (view), and event processing logic (Controller) are well divided. Modifications to one part are isolated from other parts. This improves the scalability and scalability of the entire application.

Disadvantages:

As the size of applications increases, more and more page flow logic is concentrated in a controller. This controller becomes very big and difficult to manage. It may be time to divide it into several parts. Strict separation of models, views, and controllers makes it more difficult to debug and test.

Multi-controller MVC

The multi-controller structure is generally based on use cases. That is to say, a controller processes only one or several related use case events. With the division of a single controller, the entire application may be divided into several packages with similar structures. For enterprise-level applications, this structure is very typical, but it is rarely used in j2_awv6 applications.

Figure 5 Multi-controller MVC structure object Diagram

Benefits:

Through the multi-controller structure, the Controller becomes easy to manage, and applications can be divided into several parts and allocated to several developers.

Disadvantages:

As the number of classes, objects, and files increases, the interaction between them becomes more complex.

Summary

The integrated MVC structure requires careful design and planning. You must spend enough time to consider the interaction mechanisms between different parts. The client has its own characteristics: applications are usually small in size and have limited available resources. Because of the small screen size, the j2_awv8 application prefers to replace a view instead of modifying it. The best design option is the most suitable for application requirements, rather than the best structure.