面向资源的开发？

 原因

当一个人做了几年web项目后，那么一定会对web开发有一些想法，一定会找找是不是有更好的方法来进行开发，来避免加班，来避免过多的新人培训。

 

最近帮着另外一个组做一个web项目，使用的是structs。于是java开发web应用的噩梦再次上演了。倒不是说应用有多难，但是对于那些众多的structs-config.xml. applicaitoncontext.xml, web.xml已经够够的了。当我编写一个新的功能的时候，我该做什么呢：创建一个Action，修改structs-config.xml，创建一个business，修改applicaitoncontext.xml，哦，我还需要修改ibatis的配置文件。

 

如果我今天有点困的话，精神状态不是很好，可能我完成了这个功能以后，一运行的时候就会出错误，然后我再费尽地查找错误，是不是配置漏了？还是配置写错了？还是哪个层写的不对？甚至当我开始下一个功能的时候，我简直怀疑我从Action入手是不是错误了，我应该从 ibatis的配置开始，还是从哪个地方开始？我不停的尝试，不停的被郁闷。

 

为什么会这样呢？当我们面对一个用户管理的页面的时候，我们想的是什么？恐怕都是如何把这个html转换成jsp，如何编写各个层次的各种类，应该操作什么样的表，使用什么样的SQL等等。似乎我们的经验是在太丰富了，一个简单的页面展现在眼前的时候，我们竟然就能思考到如此细节的部分。

 

资源

难道真的是我们的经验丰富？我可不这样想。为什么面对一个页面的时候，我们会一头扎进细节中去？好吧，这只是一个简单的页面，所作的也只是对用户信息的读取，创建，修改，删除4种操作。为什么这样一个简单的功能也让我们如此的头疼？

 

那么我们换一个思路去考虑这个问题。当我们面对一个用户管理的页面的时候，我们应该认为：这个功能只是对“用户“这个资源的操作。甚至我们也可以说，整个系统中，我们其实要做的就是对资源的操作。

 

客户管理系统中，我们要操作的资源是客户信息；进销存系统中，我们需要操作的资源是仓储，销售信息。

 

我们甚至可以说，如果一个系统不操作任何资源，那么这个系统就是一个没有必要存在的系统。

 

既然如此，当我们要显示客户的信息的时候，为什么要从一个Action开始？Action是什么？是资源吗？不是，Action仅仅是一个动作，是操作资源的细节而已。那么，当我们要察看用户的信息的时候，是不是可以使用 http://sample/employee/list 来访问呢？而不是使用 http://sample/ViewEmployeeAction.do 呢？同样，创建，修改，删除也是使用同样的方式。

 

这算什么？ViewEmployeeAction.do 和 employee/list 有什么区别？换个名字而已，换汤不换药！

 

真的是换汤不换药吗？可是在我的体会中他们完全不一样。一个将注意力集中在动作行为上，一个将注意力集中在资源上。好吧，他们的结果完全相同，都是显示一个jsp页面，但他们的过程是不一样的!从而也就导致开发的过程也是完全不一样的。

 

Controller

 

怎么个完全不一样法呢？前提我们仍然采用mvc的方式。那么在Controller中我们考虑的是什么呢？在structs中，我们要考虑Action，那么现在我们换成考虑资源。那么最自然的想法就是 employee/list 会调用 employee controller 中的 list 方法。不自然的想法可能就是 employee/list 会调用 AbcEmployee controller 的 doList 方法。好吧，不管自然还是不自然，我们都知道我们最终要干的是什么：就是操作资源。

 

然而如果使用 ViewEmployeeAction.do 呢？我们最终要干的是什么？我们身经百战，都知道我们要找 ViewEmployeeBusiness ，然后调用一个 DAO 去操作数据库。

 

两者站位已经不同，就决定了思考的方式不同，决定架构的不同。

 

Business

 

既然我们的系统要操作资源，那么业务逻辑算什么呢?操作资源必然要有业务逻辑，例如检索普通用户和检索管理员用户，就是两个不同的逻辑。我认为逻辑应该是资源操作的“附加品“。例如我要察看全部用户，如果没有逻辑在里面，那么我要看的就是全部的用户资源；如果有了逻辑，我就按照逻辑来查看用户。

 

这样，业务就不是系统的核心了，业务仅仅是资源的附属品。业务应该是可以“挂”到一个资源上的，也应该可以从一个资源上“拿”下来。这似乎是大逆不道，如今谁不知道业务才是系统的核心，才是系统的灵魂？可是我现在恰恰认为，资源才是系统的核心，系统的灵魂。业务？如果需要你就把它“挂”到资源上，如果不需要就把它“拿”下来。

 

总结

 

这些仅仅是我的想法，是否是正确的想法不得而知。之前学习过一些REST的资料，当时并不能完全的理解，如今总算在实际中对REST有了深切的体会。只是目前的REST，似乎只是将重点集中在Controller部分，我相信在业务层中，资源早晚会成为主角，就如同今天在Controller中一样。

 

不过这些都只是我美好的想法，什么时候能够实现？希望能早点到来吧！