可以使用 @ActionKey 注解

此外， controller 中的代码应该要极少，所以一般无需拆分。如果想拆分，先警惕一下是不是业务逻辑写在了 controller 中

绝大部分代码应该放在 service 中

@JFinal ActionKey注解不能写在类上啊，我这里指不是action的uri，是Controller本身的url

@tctc4869 me.add(controllerKey, controllerClass)，如果添加两个相同的url字符串，会报错

@tctc4869 controllerKey 顾名思义，它是 controller 的唯一 key，所以是被独占的，不能与多个 controller 共享

目前的解决办法是让某一个 controller 独享这个 controllerKey，然后在其它需要共享的地方使用 @ActionKey， 当然，这个注解只能用在方法上

你提的这个需求只有极少数人提出来过，目前看来需求并不是太大

jfinal 的路由做成当前的样子当然也是有很多考虑的，不可能支持所有需求，有一定的取舍，例如要考虑性能、学习成本等等

还要考虑对用户的代码有一定的规范性指导，每一个 controller 一个 key 值，对于模块化或者 restful 风格有一定的约束，会带来一些用户在浅层感受不到的好处，但对用户的代码切实有利的好处

最后，如果不习惯使用 @ActionKey， 使用一下 Handler 做一下 url 的处理也是可以实现你需要的功能的

楼主解决了吗？我也遇到这个问题了，api的controller越写越大了，想拆分啊

@ymwcwee 抱歉这么久才看到，截止目前，我找不到在final的Http请求分派器体系内解决这个问题，我认为就java语言本身和final的Web请求分派器体系的组合无法解决。

目前只有一个不是办法的办法，不使用Jfinal的Http请求分派器 （如果不理解Http请求分派器，那么可以简单的理解为，等同于放弃使用jfinal的Controller,action拦截器，但不包括jfinal webHttp体系下的handler组件）。

办法如下：
自己另外定义设计一套Http请求分派器，新建一个jfinal的handler，并根据需求，在自己定义的http请求分派器下，重新定义一套Controller，action，以及action拦截器体系) ，在自己定义的handler里编写自己设计的Http请求分派器实例代码，处理http消息分派。（Http请求分派器建议用单例模式）

目前只有这个办法，自己重新定义Http请求分派器，并在此之下定义Controller，action，以及action拦截器体系，并对接到Jfinal框架下的handler里，然后关键的一点，在你自己定义的http请求分派器体系里设计一个可以拆分Controller的组件。目前只有这个办法可以做到，其实设计Http请求分派器的成本已经相当于半个重新开发一个MVC框架的程度了。

不过我也不想回到Spring MVC那里，Spring MVC的action拦截器的代码和响应请求的代码编写可比Jfinal的拦截器复杂了。我已经自己定义自己需要的http请求分派器，(重新定义一套Controller，以及action拦截器体系）

@tctc4869 jfinal 后续要推的另一个框架会设计成多 Controller 共享同一个 path 的风格，但这个必须是要在 jfinal 生态建设之后的事，当前最重要提是建立 jfinal 生态

@JFinal 不仅仅是显示Controller内容的体验。

我其实觉得Spring MVC和Jfinal的Http请求分派器，在我看来，基于它们使用java进行代码编写业务代码的体验上是差不多的（至少Controller和action的使用体验是差不多的），区别在于Spring MVC那里action注解太多，一些常用http消息处理方法，记不得名字就得去百度一下，jfinal的action注解少一点，扩展上自由度多一点，可我觉得还是有不好的代码编写体验问题。

我不喜欢写注解的，不是注解不好，而是我记不得那么多注解名称，我更喜欢的是靠智能提示提升优质的代码编写体验，所以我更喜欢通过set方法，返回this的方式进行设置。

还有一点，action的注解和action方法是硬编码，这些仅仅只有硬编码的特性注定了扩展，运行时更改会有很大的限制。

波总，我建议你应该再设计一个新的http请求分派器，并用一个jfinal的handler对接

@tctc4869 我不知道你希望的用法是怎样的，希望你能将你希望的用法，甚至你现在自己的扩展分享出来

如果很好用，可以引入后续的 jfinal 版本中，或许放开 controllerKey 的唯一性限制是件很简单的事情，例如在添加路由的时候去除 containsKey 判断可能就可以了

controllerKey 改名为 controllerPath

我16.02分发表的言论，不是关于action路径问题，是关于目前的Web框架的Action的代码编写体验问题。我只说开发体验问题吧。

无论是Spring MVC，还是Jifnal的http请求分派器，都有个问题

action配置非常依赖注解，无法使用基于set的建造者模式设计action。另外action方法是硬编码。这两个痛点注定了不能很好进行扩展和对Controller内的action方法处理流程进行动态编辑配置。

所以我的一个建议是，增加新设计一个http请求分派器组件，消灭我所说的两个痛点，通过配置决定是否启动新的http请求分派器。反正jfinal现有的Controller，action，拦截器都是基于jfinal某个的handler工作处理的。控制好handler的处理逻辑，不会发生与jfinal旧有的http请求分派器冲突的情况

@JFinal

@tctc4869 当然新设计一个特点不同的http请求分派器组件，肯定要重新设计Controller，action,以及action拦截器体系。这得花时间

@tctc4869 还是不知道你的具体需求是什么，希望你能写个分享，将所希望的用法直接写成类似于伪代码的形式