轻量级MVC标准

看到标题，估计有人就开始想吐了，没关系，你可以先吐完再看，现在MVC框架多如牛毛，没必要再重复发明轮子了，要声明的是，这里不是想要发明轮子，也没那个闲工夫去发明轮子，而是看到这么多MVC框架模样都差不多，想统一接口，减少迁移成本，Java世界里，最喜欢的就是定标准，然后就是一大堆的实现，估且这里也当一个标准来搞，纯属娱乐的标准。

注：下面的定义都是狭义的，用于限定本次要解决的问题域，你也可以定义你自己标准，这不是啥业界标准。

(一) 轻量级MVC定义：
1. 框架对应用无侵入，不依赖任何接口类
2. 框架零配置，零注解
3. 简单易用，易于理解，暂且不搞RESTful，免得复杂

(二) 轻量级MVC接口：
1. Controller采用setter注入请求参数，并支持层级注入，如：book.title.
2. Controller采用getter供给数据给View，在View中可直接取到相应属性值，如：${property}.
3. Controller采用任意非setter和getter函数处理请求。
4. Controller采用函数返回值控制跳转，只允许跳转到另一Controller，不允许一个Controller对应两个View.
5. Controller对Model的依赖采用setter自动装配，包括Model之间的依赖.
6. Session参数，如：loginUserId，也通过setter注入到Controller，如果有请求参数注入了loginUserId，也会被Session参数给覆盖.
7. View与Controller一对一，通过名称映射，并支持各种View模板类型扩展，比如：JSP, Velocity, FreeMarker, CommonTemplate等.
8. 没有Controller时，View也能执行，相当于隐式Controller。
9. 框架应提供COC接口，基于规则约定某个包名是model，某个包名是controller，某个目录是view，比如：com.company.module.controller，自动发现module，并以单例模式加载model，以原型模式加载controller。
总而言之，接口除了setter和getter，以及自动映射规则，什么都没有.

(三) 轻量级MVC访问：
http://主机名[:端口][/应用名]/模块名/控制器名/函数名.html[?参数名=参数值]
注：方括号代表可省

(四) 轻量级MVC实现：
符合以上接口的实现均可。

(五) 轻量级MVC优势：
业务逻辑不依赖任何框架，可以适配到任意框架而不影响业务代码，当旧的框架被淘汰，无人维护时，可以以最快的方式迁移到新的更稳定的框架.

理想是美好的，现实是残酷的，上面纯属个人想法，现实中困难多了，怀着美好愿景总是好的。

评论

20 楼 天机老人 2009-05-13  

好有空玩玩nutz这个mvc！

19 楼 天机老人 2009-05-13  

我也来说说我用的spring mvc(基于注解)
目前玩web4j，比较讨厌他回归了sql这一点，不过可以用Hibernate实现（参考里提到了不推荐）。

(一) 轻量级MVC定义：

引用

1. 框架对应用无侵入，不依赖任何接口类

Controller就是javaBean，类名上注解@Controller。非常勉强的列入不依赖。 

引用

2. 框架零配置，零注解

配置为零点几（java Bean扫描还是得配置的,基于注解也得配置），使用注解----还是难逃配置与注解。

引用

3. 简单易用，易于理解，暂且不搞RESTful，免得复杂

比较符合。

(二) 轻量级MVC接口：
1. Controller采用setter注入请求参数，并支持层级注入，如：book.title.
@Resource方式注入
[private] BaseService baeService (无需写set)

引用

2. Controller采用getter供给数据给View，在View中可直接取到相应属性值，如：${property}.

Controller返回值，返回一个model或者domain即可。

引用

3. Controller采用任意非setter和getter函数处理请求。

没发现

引用

4. Controller采用函数返回值控制跳转，只允许跳转到另一Controller，不允许一个Controller对应两个View.

支持

引用

5. Controller对Model的依赖采用setter自动装配，包括Model之间的依赖.

支持
6. Session参数，如：loginUserId，也通过setter注入到Controller，如果有请求参数注入了loginUserId，也会被Session参数给覆盖.
支持

引用

7. View与Controller一对一，通过名称映射，并支持各种View模板类型扩展，比如：JSP, Velocity, FreeMarker, CommonTemplate等.

不支持

引用

8. 没有Controller时，View也能执行，相当于隐式Controller。

不支持

引用

9. 框架应提供COC接口，基于规则约定某个包名是model，某个包名是controller，某个目录是view，比如：com.company.module.controller，自动发现module，并以单例模式加载model，以原型模式加载controller。

不支持。但是我发现spring mvc已经到到了这个边缘，但是为何不做成这样，这一点让我很郁闷！

18 楼 wendong007 2009-05-11  

<div class="quote_title">jindw 写道<br>
</div>
<div class="quote_div">
<br>提两个扩展建议： 可以考虑增加一个新的注入方式。 参数注入。 比如，根据类型注入。 请求处理函数中带有 HttpServletRequest，就把当前请求懂得request对象传入。。。。 也可以考虑更具参数名称注入。这个好像mod_python上也有实现， 就是说，如果我有一个参数 ：int pageSize，那么，他自动吧请求参数的【pageSize】给注入，<br>
</div>
<p><br>我之前写个一个MVC框架就是这么用的，不过遇到一个小问题：如果方法参数中有int等基本类型，而请求参数中又没有同名的参数，这个时候应该怎么注入呢，基本类型不能为NULL，0可能又会有特殊的含义，用包装类可以解决这个问题，不过总觉得有些别扭。<br></p>
<div class="quote_title">hatedance 写道</div>
<div class="quote_div">
<br>LZ的这个idea我以前尝试过，很容易基于反射就能实现了。虽然少了一层url到controler映射配置文件，但是总觉得不安，代码结构都让用户一览无遗了。也许只是心理问题。<br>
</div>
<p><br>这些倒不是什么问题，这个我也实现过，不过这个功能看起来很好，其实灵活性很差，某些场景下还会带来很多麻烦，LZ好像是阿里的吧，公司内部框架不用太多考虑通用性的问题，这样还没什么问题，但是都说到制定标准了，这样就有点说不过去了吧，至少也应该提供个配置路由的功能</p>
<p> </p>
<p>至于前面说的侵入性的问题，如果是制定标准的话，根本不存在所谓的侵入性问题，依赖于某个实现才算是侵入性，所以没必要追求不依赖任何接口、类</p>
<p> </p>

17 楼 javatar 2009-05-11  

whaosoft 写道

1. 框架对应用无侵入，不依赖任何接口类 2. 框架零配置，零注解 ?????难道不是这样就不是轻量级了吗???

这里是狭义的定义，每个人都可以有自己的定义。

neptune 写道

还是不要再搞了，今天你有一个好的想法，也按这个做了。明天，例如:spring出了一个新的mvc框架，和你想的差不多，而且有些地方更好，你会选择那个呀。现实点，维护不起的，除了你是一个大公司!!!

如果Spring实现了同样的功能，并且更稳定，因为接口不依赖框架，直接作一个COC适配，就直接用Spring了，业务代码不变。

jindw 写道

提两个扩展建议： 可以考虑增加一个新的注入方式。 参数注入。 比如，根据类型注入。 请求处理函数中带有 HttpServletRequest，就把当前请求懂得request对象传入。。。。 也可以考虑更具参数名称注入。这个好像mod_python上也有实现， 就是说，如果我有一个参数 ：int pageSize，那么，他自动吧请求参数的【pageSize】给注入，

呵呵，细节再考虑，我只是大概的瞎想想，但HttpServletRequest最好不用被业务代码所依赖。

hatedance 写道

LZ的这个idea我以前尝试过，很容易基于反射就能实现了。虽然少了一层url到controler映射配置文件，但是总觉得不安，代码结构都让用户一览无遗了。也许只是心理问题。

呵呵，配置文件通常也是一对一的，有些配置很无聊的。

16 楼 hatedance 2009-05-11  

javatar 写道

...
http://主机名[:端口][/应用名]/模块名/控制器名/函数名.html[?参数名=参数值]
...

LZ的这个idea我以前尝试过，很容易基于反射就能实现了。虽然少了一层url到controler映射配置文件，但是总觉得不安，代码结构都让用户一览无遗了。也许只是心理问题。

15 楼 jindw 2009-05-11  

javatar 写道

1. Controller采用setter注入请求参数，并支持层级注入，如：book.title.
2. Controller采用getter供给数据给View，在View中可直接取到相应属性值，如：${property}.
3. Controller采用任意非setter和getter函数处理请求。
。

提两个扩展建议：

可以考虑增加一个新的注入方式。
参数注入。

比如，根据类型注入。
请求处理函数中带有 HttpServletRequest，就把当前请求懂得request对象传入。。。。

也可以考虑更具参数名称注入。这个好像mod_python上也有实现，


就是说，如果我有一个参数 ：int pageSize，那么，他自动吧请求参数的【pageSize】给注入，

14 楼 neptune 2009-05-11  

还是不要再搞了，今天你有一个好的想法，也按这个做了。明天，例如:spring出了一个新的mvc框架，和你想的差不多，而且有些地方更好，你会选择那个呀。

现实点，维护不起的，除了你是一个大公司!!!

13 楼 kennethlin 2009-05-11  

grails可以实现LZ所说的COC

12 楼 esanone 2009-05-10  

kjj 写道

别搞什么mvc 标准了，都是人家创意触发了你的思维，怎么看也逃不出人家的圈圈，mvc基本也就那样了！！

同意这此兄才的说法！

11 楼 whaosoft 2009-05-10  

1. 框架对应用无侵入，不依赖任何接口类
2. 框架零配置，零注解

?????难道不是这样就不是轻量级了吗???

10 楼 zozoh 2009-05-10  

javatar 写道

TO: zozoh
上面的接口是采用原型模式的，Controller相当于命令模式中的命令，自身持有上下文状态，倾向于Martin的充血模型，WebWork, Struts2, Seam等采用该方式。你的nutz是采用单例模式的，Controller相当于前端服务域，上下文状态由参数传递，倾向于Eric的领域服务模型，类似的有Struts1, SpringMVC等，但你的nutz不同于其它MVC，函数返回值没有用作页面流控制，而是以数据为中心，这样便于资源多重表述渲染，很不错，感谢分享。

没错，最初的设想是这样的，但是现在的 Nutz 更加灵活了：
1. Nutz 的 Controller 有一个实现叫做 Action，也是个抽象类， 当你的命令继承自 Action 的时候，它每次被调用都会被重新创建并充血
2. Nutz 的 Controller 的配置基于 Nutz.Ioc 这个注入框架，任何 Controller 如果 singleton 被声明为 false，那么它也会被重新创建，不是单例。
3. 任何 Controller 可以返回三种对象，
   1) 另外一个 Controller ，那么框架会执行这个 controller，相当于动作链模式
   2) 某个 View ，框架会停止执行后续的 controller，直接渲染这个View，然后返回
   3) 随便一个 Object，那么框架会将这个对象记录在 request 里面，以备后续的 View 使用。

所以， Nutz 的 MVC 框架，你可以同时使用单例模式和充血模式，这个类似于 Spring 的 MVC ，可以使用普通 Controller 和 ThrowableController 一样。 并且它的返回值又不局限于一个 View

9 楼 javatar 2009-05-09  

TO: zozoh
上面的接口是采用原型模式的，Controller相当于命令模式中的命令，自身持有上下文状态，倾向于Martin的充血模型，WebWork, Struts2, Seam等采用该方式。你的nutz是采用单例模式的，Controller相当于前端服务域，上下文状态由参数传递，倾向于Eric的领域服务模型，类似的有Struts1, SpringMVC等，但你的nutz不同于其它MVC，函数返回值没有用作页面流控制，而是以数据为中心，这样便于资源多重表述渲染，很不错，感谢分享。

8 楼 zozoh 2009-05-08  

呵呵，忍不住和 Nutz框架 比较一下：

引用

1. Controller采用setter注入请求参数，并支持层级注入，如：book.title.

如果没有 getter 和 setter 也能注入到 Controller 里，但是不支持层级

引用

2. Controller采用getter供给数据给View，在View中可直接取到相应属性值，如：${property}.

将 Controller 的返回设在 Request 里，View 如果是 JSP 可以直接拿到，如果是 JsonView ，直接返回 Json 字符串。

引用

3. Controller采用任意非setter和getter函数处理请求。

侵入式的要求 Controller 实现 Controller 接口

引用

4. Controller采用函数返回值控制跳转，只允许跳转到另一Controller，不允许一个Controller对应两个View.

Controller 可以返回另外一个 Controller 也可以是个View, 也可以是随便什么对象，这个对象会被后续的 View 使用 （通过放在 request 属性里）

引用

5. Controller对Model的依赖采用setter自动装配，包括Model之间的依赖.

符合

引用

6. Session参数，如：loginUserId，也通过setter注入到Controller，如果有请求参数注入了loginUserId，也会被Session参数给覆盖.

不符合

引用

7. View与Controller一对一，通过名称映射，并支持各种View模板类型扩展，比如：JSP, Velocity, FreeMarker, CommonTemplate等.

符合

引用

8. 没有Controller时，View也能执行，相当于隐式Controller。

符合

引用

9. 框架应提供COC接口，基于规则约定某个包名是model，某个包名是controller，某个目录是view，比如：com.company.module.controller，自动发现module，并以单例模式加载model，以原型模式加载 controller。总而言之，接口除了setter和getter，以及自动映射规则，什么都没有.

Nutz 的 MVC  提供了一个 MvcSupport 接口，以及一个默认实现。 默认实现是使用 Nutz.Ioc 框架来为 Controller 注入相关的 Service 和参数。 当然也可以作一个基于上述约定的实现。并且这个实现应该可以支持LZ从1-8 大部分需求。比如要求用一个 POJO 作为 Controllor 等。

总之，LZ基于URL做映射的想法和我以前的一个框架差不多，我现在的框架更灵活一些，不过还是很欣赏搂主这种思路滴～～～～

7 楼 yananay 2009-05-08  

目前来说 rails 的方式是最方便的，甚至连 php 也已经开始模仿。
java 是麻烦了点，呵呵。不过熟练了也就那么回事，一个mvc，也就是控制一下流程，还能干多大的事呢？

至于 session 那个，注入到controller也不好，还是用一个session scope 的对象来管理好。

-------------------------------------
另外发到 ct mail group 那个问题再看一下？

6 楼 javatar 2009-05-08  

kjj 写道

别搞什么mvc 标准了，都是人家创意触发了你的思维，怎么看也逃不出人家的圈圈，mvc基本也就那样了！！

是的，就是因为MVC都这模样，才抽取最小交集接口，本来就没什么创意，呵呵。

stworthy 写道

有点RAILS和ASP.NET MVC的影子

像谁都没关系，只是因为迁移了一个应用，很麻烦，有感而发。

unsid 写道

印象中就是摒弃领域层

没有摒弃领域层，Service, Domain, DAO等，都是Model的一部分。

5 楼 unsid 2009-05-08  

印象中就是摒弃领域层

4 楼 stworthy 2009-05-08  

有点RAILS和ASP.NET MVC的影子

3 楼 kjj 2009-05-07  

别搞什么mvc 标准了，都是人家创意触发了你的思维，怎么看也逃不出人家的圈圈，mvc基本也就那样了！！

2 楼 javatar 2009-05-07  

wangxin0072000 写道

坏消息是： 我们都失业了。

呵呵，有点恺人忧天了，没有人会失业的，世上没有哪个人只会coding，其它什么都不会干的，不需要coding的时候，自然有其它活干。

wangxin0072000 写道

JVM上跑的都是各种DSL

DSL多了，复杂度更高，活更多了。

1 楼 wangxin0072000 2009-05-07  

最后一句话比较实际。醒醒吧。别做梦了。也许再过两年Java就没有了，JVM上跑的都是各种DSL，开发都是一站式的。Oracle给前台也定个标准。
这时候，好消息是：
基本表达流畅，思路清晰的人都能写出可读性极高的代码。那时候，什么设计模式，什么MVC都么有了。
坏消息是：
我们都失业了。