一 : 常用Web_MVC框架_介绍

 基于Web的MVC framework在J2EE的世界内已是空前繁荣。TTS网站上几乎每隔一2个星期就会有新的MVC框架发布。目前比较好的MVC,老牌的有Struts、Webwork。新兴的MVC 框架有Spring MVC、Tapestry、JSF等。这些大多是著名团队的作品，另外还有一些边缘团队的作品，也相当出色，如Dinamica、VRaptor等。这些框架都提供了较好的层次分隔能力。在实现良好的MVC 分隔的基础上，通过提供一些现成的辅助类库，同时也促进了生产效率的提高。　　如何选择1个好的框架应用在你的项目中，将会对你的项目的效率和可重用是至关重要的。本文将对目前最流行、最常用的2种framework进行介绍。　　一、Struts　　Struts是Apache软件基金下Jakarta项目的一部分。Struts框架的主要架构设计和开发者是Craig R.McClanahan。Struts 是目前Java Web MVC框架中不争的王者。经过长达五年的发展，Struts已经逐渐成长为1个稳定、成熟的框架，并且占有了MVC框架中最大的市场份额。但是Struts某些技术特性上已经落后于新兴的MVC框架。面对Spring MVC、Webwork2 这些设计更精密，扩展性更强的框架，Struts受到了前所未有的挑战。但站在产品开发的角度而言，Struts仍然是最稳妥的选择。　　Struts有一组相互协作的类（组件）、Serlvet以及jsp tag lib组成。基于struts构架的web应用程序基本上符合JSP Model2的设计标准，可以说是MVC设计模式的1种变化类型。根据上面对framework的描述，我们很容易理解为什么说Struts是1个web framwork，而不仅仅是一些标记库的组合。但 Struts 也包含了丰富的标记库和独立于该框架工作的实用程序类。Struts有其自己的控制器（Controller），同时整合了其他的一些技术去实现模型层（Model）和视图层（View）。在模型层，Struts可以很容易的与数据访问技术相结合，包括EJB,JDBC和Object Relation Bridge。在视图层，Struts能够与JSP, Velocity Templates,XSL等等这些表示层组件想结合。　　Struts的体系结构　　struts framework是MVC 模式的体现，下面我们就从分别从模型、视图、控制来看看struts的体系结构（Architecture）。 　　从视图角度（View）　　主要由JSP建立，struts自身包含了一组可扩展的自定义标签库（TagLib），可以简化创建用户界面的过程。目前包括：Bean Tags，HTML Tags，Logic Tags，Nested Tags，Template Tags　这几个Taglib。有关它们的详细资料请参考struts用户手册　　从模型角度（Model）　　模型主要是表示1个系统的状态（有的时候，改变系统状态的业务逻辑操作也也划分到模型中）。在Struts中，系统的状态主要有ActiomForm Bean体现，一般情况下，这些状态是非持久性的。如果需要将这些状态转化为持久性数据存储，Struts本身也提供了Utitle包，可以方便的与数据库操作　　从控制器角度（Controller）　　在Struts framework中， Controller主要是ActionServlet，但是对于业务逻辑的操作则主要由Action、ActionMapping、ActionForward这几个组件协调完成（也许这几个组件，应该划分到模型中的业务逻辑一块）。其中，Action扮演了真正的业务逻辑的实现者，而ActionMapping和ActionForward则指定了不同业务逻辑或流程的运行方向。对于Struts 如何控制、处理客户请求，让我们通过对struts的4个核心组件介绍来具体说明。这几个组件就是：ActionServlet。Action Classes，Action Mapping（此处包括ActionForward），ActionFrom Bean。　　二、Spring　　Spring 实际上是Expert One-on-One J2EE Design and Development 一书中所阐述的设计思想的具体实现。在One-on-One 一书中，Rod Johnson 倡导J2EE 实用主义的设计思想，并随书提供了1个初步的开发框架实现（interface21 开发包）。而Spring 正是这一思想的更全面和具体的体现。Rod Johnson 在interface21 开发包的基础之上，进行了进1步的改造和扩充，使其发展为1个更加开放、清晰、全面、高效的开发框架。　　Spring是1个开源框架，由Rod Johnson创建并且在他的著作《J2EE设计开发编程指南》里进行了描述。它是为了解决企业应用开发的复杂性而创建的。Spring使使用基本的JavaBeans来完成以前只可能由EJB完成的事情变得可能了。然而，Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言，任何Java应用都可以从Spring中受益。　　简单来说，Spring是1个轻量的控制反转和面向切面的容器框架。当然，这个描述有点过于简单。但它的确概括出了Spring是做什么的。为了更好地理解Spring，让我们分析一下这个描述： 　　1、轻量，从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在1个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于轻量??从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在1个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于Spring的特定类。　　2、控制反转??Spring通过1种称作控制反转（IoC）的技术促进了松耦合。当应用了IoC，对象被动地传递它们的依赖而不是自己创建或者查找依赖对象。你可以认为IoC与JNDI相反??不是对象从容器中查找依赖，而是容器在对象初始化时不等被请求就将依赖传递给它。 　　3、面向切面??Spring包含对面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统服务（例如审计与事物管理）进行内聚性的开发。应用对象只做它们应该做的??完成业务逻辑??仅此而已。它们并不负责（甚至是意识）其它的系统关注点，例如日志或事物支持。 　　4、容器??Spring包含和管理应用对象的配置和生命周期，在这个意义上它是1种容器。你可以配置你的每个bean如何被创建??基于1个配置原形为你的bean创建1个单独的实例或者每次需要时都生成1个新的实例??以及它们是如何相互关联的。然而，Spring不应该被混同于传统的重量的EJB容器，它们经常是庞大与笨重的，难以使用。 　　框架：Spring使由简单的组件配置和组合复杂的应用成为可能。在Spring中，应用对象被声明式地组合，典型地是在1个XML文件里。Spring也提供了很多基础功能（事务管理、持久性框架集成等等），将应用逻辑的开发留给了你。 　　所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种子框架提供了基础。 

二 : mvc中partialview的用法

一、PartialView的调用

1、 @Html.Patial

2、 @ www.61k.com

3、 @Html.Action

4、 @ www.61k.com



二、调用 www.61k.com 有四种方式

1、 www.61k.com (string partialName);

2、 www.61k.com (string partialName,object model);

3、 www.61k.com (string partialName,ViewDataDictionary viewData);

4、 www.61k.com (string partialName,object model,ViewDataDictionary viewData);





三、 www.61k.com 和 www.61k.com 的主要区别

1、 www.61k.com ：直接将View呈现在父视图的相应地方，View中绑定的Model需事先生成好

2、 www.61k.com ：需要进入子视图对应的Action方法中，按照Controller->Model->View的顺序走一遍，然后将产生的View呈现在父视图相应的地方,如果要呈现的视图需要后台处理数据，那么需要选用 www.61k.com 或者Html.Action



四、PartialView()与View()的区别

当返回视图后，View()会被加上默认的母板页，如果不需要layout，需要在页面上显式的加上Layout=null，如果返回分部视图PartialView，则相当于 Layout=null，不会加载 默认的母板页。[www.61k.com）即：

1、PartialView()=>渲染视图=>不带Layout

2、View()=>渲染分部视图=>自动加上Layout

参考资料： mvc中partialview www.61k.com .html

三 : 框架模式 MVC 在Android中的使用

算来学习Android开发已有2年的历史了，在这2年的学习当中，基本掌握了Android的基础知识。越到后面的学习越感觉困难，一来是自认为android没啥可学的了（自认为的，其实还有很多知识科学），二来网络上的很多框架已经帮我们做了太多的事情了，我们只需要画画UI就可以了，感觉Android开发没有太多的技术含金量。最近闲来无事，开始总结之前学过的知识点，想着是否应该学点其他的东西呢？总不能局限于Android基础知识吧。慢慢的探索发现在大的项目工程中，一个好的框架，好的设计模式，能减少很大的工作量。因此接下来两篇博客来学习一下Android中常用的两种框架设计模式 MVC和MVP。

MVC概念[www.61k.com]

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。说了这么多，听着感觉很抽象，废话不多说，我们来看看MVC在Android开发中是怎么应用的吧！

MVC for Android

在Android开发中，比较流行的开发框架模式采用的是MVC框架模式，采用MVC模式的好处是便于UI界面部分的显示和业务逻辑，数据处理分开。那么Android项目中哪些代码来充当M,V,C角色呢？

M层：适合做一些业务逻辑处理，比如数据库存取操作，网络操作，复杂的算法，耗时的任务等都在model层处理。 V层：应用层中处理数据显示的部分，XML布局可以视为V层，显示Model层的数据结果。 C层：在Android中，Activity处理用户交互问题，因此可以认为Activity是控制器，Activity读取V视图层的数据（eg.读取当前EditText控件的数据），控制用户输入（eg.EditText控件数据的输入），并向Model发送数据请求（eg.发起网络请求等）。

接下来我们通过一个获取天气预报数据的小项目来解读 MVC for Android。先上一个界面图：

Controller控制器

package com.xjp.androidmvcdemo.controller;import android.app.Dialog;import android.app.ProgressDialog;import android.os.Bundle;import android.support.v7.app.ActionBarActivity;import android.view.View;import android.widget.EditText;import android.widget.TextView;import android.widget.Toast;import com.xjp.androidmvcdemo.R;import com.xjp.androidmvcdemo.entity.Weather;import com.xjp.androidmvcdemo.entity.WeatherInfo;import com.xjp.androidmvcdemo.model.OnWeatherListener;import com.xjp.androidmvcdemo.model.WeatherModel;import com.xjp.androidmvcdemo.model.WeatherModelImpl;public class MainActivity extends ActionBarActivity implements OnWeatherListener, View.OnClickListener { private WeatherModel weatherModel; private Dialog loadingDialog; private EditText cityNOInput; private TextView city; private TextView cityNO; private TextView temp; private TextView wd; private TextView ws; private TextView sd; private TextView wse; private TextView time; private TextView njd; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); weatherModel = new WeatherModelImpl(); initView(); } /** * 初始化View */ private void initView() { cityNOInput = findView(R.id.et_city_no); city = findView(R.id.tv_city); cityNO = findView(R.id.tv_city_no); temp = findView(R.id.tv_temp); wd = findView(R.id.tv_WD); ws = findView(R.id.tv_WS); sd = findView(R.id.tv_SD); wse = findView(R.id.tv_WSE); time = findView(R.id.tv_time); njd = findView(R.id.tv_njd); findView(R.id.btn_go).setOnClickListener(this); loadingDialog = new ProgressDialog(this); loadingDialog.setTitle(加载天气中...); } /** * 显示结果 * * @param weather */ public void displayResult(Weather weather) { WeatherInfo weatherInfo = weather.getWeatherinfo(); city.setText(weatherInfo.getCity()); cityNO.setText(weatherInfo.getCityid()); temp.setText(weatherInfo.getTemp()); wd.setText(weatherInfo.getWD()); ws.setText(weatherInfo.getWS()); sd.setText(weatherInfo.getSD()); wse.setText(weatherInfo.getWSE()); time.setText(weatherInfo.getTime()); njd.setText(weatherInfo.getNjd()); } /** * 隐藏进度对话框 */ public void hideLoadingDialog() { loadingDialog.dismiss(); } @Override public void onClick(View v) { switch (v.getId()) { case R.id.btn_go: loadingDialog.show(); weatherModel.getWeather(cityNOInput.getText().toString().trim(), this); break; } } @Override public void onSuccess(Weather weather) { hideLoadingDialog(); displayResult(weather); } @Override public void onError() { hideLoadingDialog(); Toast.makeText(this, 获取天气信息失败, Toast.LENGTH_SHORT).show(); } privateT findView(int id) { return (T) findViewById(id); }}

从上面代码可以看到，Activity持有了WeatherModel模型的对象，当用户有点击Button交互的时候，Activity作为Controller控制层读取View视图层EditTextView的数据，然后向Model模型发起数据请求，也就是调用WeatherModel对象的方法 getWeathre（）方法。当Model模型处理数据结束后，通过接口OnWeatherListener通知View视图层数据处理完毕，View视图层该更新界面UI了。然后View视图层调用displayResult（）方法更新UI。至此，整个MVC框架流程就在Activity中体现出来了。

Model模型

来看看WeatherModelImpl代码实现

package com.xjp.androidmvcdemo.model;/** * Description:请求网络数据接口 * User: xjp * Date: 2015/6/3 * Time: 15:40 */public interface WeatherModel { void getWeather(String cityNumber, OnWeatherListener listener);}................package com.xjp.androidmvcdemo.model;import com.android.volley.Response;import com.android.volley.VolleyError;import com.xjp.androidmvcdemo.entity.Weather;import com.xjp.androidmvcdemo.volley.VolleyRequest;/** * Description:从网络获取天气信息接口实现 * User: xjp * Date: 2015/6/3 * Time: 15:40 */public class WeatherModelImpl implements WeatherModel { @Override public void getWeather(String cityNumber, final OnWeatherListener listener) { /*数据层操作*/ VolleyRequest.newInstance().newGsonRequest(http://www.weather.com.cn/data/sk/ + cityNumber + .html, Weather.class, new Response.Listener() { @Override public void onResponse(Weather weather) { if (weather != null) { listener.onSuccess(weather); } else { listener.onError(); } } }, new Response.ErrorListener() { @Override public void onErrorResponse(VolleyError error) { listener.onError(); } }); }}

以上代码看出，这里设计了一个WeatherModel模型接口，然后实现了接口WeatherModelImpl类。controller控制器activity调用WeatherModelImpl类中的方法发起网络请求，然后通过实现OnWeatherListener接口来获得网络请求的结果通知View视图层更新UI 。至此，Activity就将View视图显示和Model模型数据处理隔离开了。activity担当contronller完成了model和view之间的协调作用。

至于这里为什么不直接设计成类里面的一个getWeather（）方法直接请求网络数据？你考虑下这种情况：现在代码中的网络请求是使用Volley框架来实现的，如果哪天老板非要你使用Afinal框架实现网络请求，你怎么解决问题？难道是修改 getWeather（）方法的实现？ no no no，这样修改不仅破坏了以前的代码，而且还不利于维护， 考虑到以后代码的扩展和维护性，我们选择设计接口的方式来解决着一个问题，我们实现另外一个WeatherModelWithAfinalImpl类，继承自WeatherModel，重写里面的方法，这样不仅保留了以前的WeatherModelImpl类请求网络方式，还增加了WeatherModelWithAfinalImpl类的请求方式。Activity调用代码无需要任何修改。

MVC使用总结

利用MVC设计模式，使得这个天气预报小项目有了很好的可扩展和维护性，当需要改变UI显示的时候，无需修改Contronller（控制器）Activity的代码和Model（模型）WeatherModel模型中的业务逻辑代码，很好的将业务逻辑和界面显示分离。

在Android项目中，业务逻辑，数据处理等担任了Model（模型）角色，XML界面显示等担任了View（视图）角色，Activity担任了Contronller（控制器）角色。contronller（控制器）是一个中间桥梁的作用，通过接口通信来协同 View（视图）和Model（模型）工作，起到了两者之间的通信作用。

什么时候适合使用MVC设计模式？当然一个小的项目且无需频繁修改需求就不用MVC框架来设计了，那样反而觉得代码过度设计，代码臃肿。一般在大的项目中，且业务逻辑处理复杂，页面显示比较多，需要模块化设计的项目使用MVC就有足够的优势了。

4.在MVC模式中我们发现，其实控制器Activity主要是起到解耦作用，将View视图和Model模型分离，虽然Activity起到交互作用，但是找Activity中有很多关于视图UI的显示代码，因此View视图和Activity控制器并不是完全分离的，也就是说一部分View视图和Contronller控制器Activity是绑定在一个类中的。

MVC的优点：

(1)耦合性低。所谓耦合性就是模块代码之间的关联程度。利用MVC框架使得View（视图）层和Model（模型）层可以很好的分离，这样就达到了解耦的目的，所以耦合性低，减少模块代码之间的相互影响。

(2)可扩展性好。由于耦合性低，添加需求，扩展代码就可以减少修改之前的代码，降低bug的出现率。

(3)模块职责划分明确。主要划分层M,V,C三个模块，利于代码的维护。

本文标题：常用的mvc框架-常用Web_MVC框架_介绍
本文地址： http://www.61k.com/1060935.html