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

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

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

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

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

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

有点RAILS和ASP.NET MVC的影子

印象中就是摒弃领域层

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


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


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

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

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

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

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


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

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

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

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

符合
不符合

符合

符合

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

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

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