首先，看看在使用struts等框架做开发的时候，遇到的一些问题：
1.从URL到Action B和S之间是HTTP，我们在http中能够表达的仅仅是一个URL和若干字符串格式的参数。于是在任何业务开发过程中，我们都少不了从前端的URL+参数到后端的业务方法之间的映射。这个事情是枯燥无味的，是没有技术含量的，是可以被认为是体力活的--但却是不得不做的。
2.请求一个展现数据的页面，一定是先到Action，准备数据，然后forward到页面，这与早期的jsp+javabean开发或者asp开发中是完全相反的，后者实际上是你请求某页面，那么你首先就是到达这个页面，在这个页面的处理过程中，再去做诸如准备数据这样的事情。我认为后者这种方式才是更加自然的方式。
3.后端不知前端有什么 一次请求从前台提交到后台的时候，应用服务器把HTTP请求包装成request对象，并把所有的请求参数放在其中。于是，当后端接收到一个参数的时候，我们不知道这个参数在前端对应着什么样的html元素。这个问题在处理下拉框输入的时候尤为突出。我们写页面的时候通过定义select下面的option元素告诉应用，说只能选某几个选项其中之一，然后为了确保数据正确，在后端我们还是要校验用户的输入是否是那几个选项中的一个。这相当于我们两次告诉系统输入的允许范围。为什么不能只做一次呢。因为在以往的开发过程中，后端不知道前端有什么。
4.无状态的Action层 在以往的开发中，另外一个很重要的问题是关于状态的。HTTP是无状态的协议，于是基于HTTP的jsp、struts也都是无状态的。什么是无状态呢，典型的表现就是，你第一次请求查询出来的一条数据，在下一次请求的时候，一定已经找不到了（我们不可能把大多数如此普通的数据简单的放到session/application作用域中去）。这代表着使用Hibernate的场景下，为了正确的更新一个对象，你需要在提交表单的时候再次查询数据库获得这个对象，然后把用户修改了的属性Set到这个对象上，然后再保存之。同时，为了实现乐观锁定，你需要把version信息也放在表单上发送给客户端--如果客户端传回给你一个虚假的非常高的版本号，那么你的乐观锁形同虚设--两个人同时打开某一条记录，后提交的那个人完全可以在谁都不知情的情况下覆盖前一个人的提交结果。
JSF/seam为我们解决了这些问题。基于JSF，我使用Spring替代了Seam，同样能够解决这些问题。