自己写的j2meMVC模式cotroller 控制类包model 数据组织类包view 视图类包参考文章：转载：http://www.yesky.
自己写的j2meMVC模式
cotroller 控制类包
model 数据组织类包
view 视图类包
参考文章：
转载：http://www.yesky.com/395/1923895.shtml
控制器并不总是联系着Model，有时只是依赖关系。并且Controller往往通过Model的对应的生命期类来获得Model对象。在这种形式中，层层隔离，View与Controller紧密相连，而Model有很高的独立性，可以很好的重用。
一般的结合UML设计的过程，对MVC的各个类有相应的命名习惯。
View 称为
Boundary 类（边界类） 以UI结尾
Controller 称为
Controller 类（控制类） 以Workflow结尾
Model 称为
Entity 类（实体类） 以Entity结尾或者没有尾缀
Model对应的
Lifecycle 类（生命周期类） 以Locator结尾
边界类和控制类的基础类如下
BaseView.java
/**
* @author Favo
*
* 视图类
*/
public abstract class BaseView {
public abstract Display getDisplay();
/**
* 简单的返回包装的屏幕对象,不要做任何准备屏幕的操作!
*/
public abstract Displayable getScreen();
/**
* 创建屏幕
*/
protected abstract void createView() throws Exception;
/**
* 更新屏幕
*/
public abstract void updateView() throws Exception;
/**
* 返回控制器
*/
public abstract BaseController getController();
/**
* 准备屏幕
* 返回准备好的屏幕对象
*/
public Displayable prepareScreen() throws Exception {
if(getScreen()==null){
createView();
} else {
updateView();
}
return getScreen();
}
/**
* 显示当前屏幕
*/
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(Alert.FOREVER);
getDisplay().setCurrent(al);
}
}
}
BaseController.java
/**
* @author Favo
*
* 控制类
*/
public abstract class BaseController {
public abstract BaseView getView();
public abstract void setView(BaseView view);
}
注意到这些基础的类并没有向MFC框架那样产生完整的框架，而是设计成了抽象类，一来希望强迫大家实现抽象类（防止出错）；二来希望增加一点灵活性。所以两个类之间的通信就要靠大家撰写的子类的构造函数了。一般我的习惯是，初始化好控制器，然后将控制器作为参数传给边界类的构造函数，由边界类的构造函数来回调控制器的setView()来实现的。这些步骤是一定要有的，不然会NULLpointerExcpetion哦。
尽管理论上可能很清晰，但实践带来的复杂性是惊人的。这正是软件开发的问题，太多的细节困扰这开发者对大局的把握。本文接下来，将结合最后这种设计思想，给出一个完整的设计实例。帮助大家从实践的角度理解运用这一模式。敬请大家期待。
上面看到的是个典型的M—V模型，我们可以理解这种以屏幕为核心的分离的含义。Model组织起屏幕的数据，view向Model索要其希望显示的数据，注意这一操作一定要通过预先协商好的接口访问，而不是直接操作。如果出现复杂的事务逻辑（用户选择的某种操作），有人将其放在Model端，也有人放在View端，但一般上放在Model端，这时Model带有严重的Controller的色彩。
这种形式的优点是非常的直观，也有限的分离了显示和数据。如果常看j2medev.com站长Mingjava的文章，可以看到大部分他写的例子都是这种模式。并且这种模式也常常用于RAD工具。
这种模式的缺点是它与RAD工具一样鼓励你从屏幕开始思考问题，这往往让你陷入RAD的陷阱——不先考虑事务的流程，而是从用户接口直接下手去分析问题，这往往扼杀了你的全局构思。
