: 关于struts2 中对action 封装的方案的一些想法
 |
皇室勇少
2010-02-27
方法一: 每一个动作一个action 比如 userLoginAction [登陆动作]
优点: 这样操作起来好像很清楚, 缺点: 到时候action多得会让你头痛。 方法二 : 以实体为单位 比如 userAction [实体为用户],billAction[实体为表单] 优点: 这样就是以面向对象的概念来做的。关于这个实体的相关操作都写在这个action里面.同时action属性也好定义。用实体即可。 不论是用户请求时参数的封装还是。响应时的结果都比较方便 缺点: 这样一来一个action里面的东西实在太多。 方法三: 以页面为单位 每一个页面对应一个action类似于struts1 如果 [registeActoin]注册页面 优点: 一个页面一个action . 而且名字与页面类似即可。这样容易管理。又好找! 缺点: 有时候一个页面操作的类,可能好多个。对action属性的封装极为不利 现在公司采用的是第二种方案: 但以发现不少问题。想知道大家都是怎么做的。 |
 |
liwenjie
2010-04-20
这是action的粒度问题，建议采用一个领域模型或者小模块为一个action，比如订单、客户，而这个action保证不要太大，如果太大比如数十个方法，表明你的粒度过大了
|
 |
luojy8877
2010-04-23
liwenjie 写道 这是action的粒度问题，建议采用一个领域模型或者小模块为一个action，比如订单、客户，而这个action保证不要太大，如果太大比如数十个方法，表明你的粒度过大了
如何控制模块的大小呢 比如按订单，客户分 订单只有5个方法 客户有十多个方法 怎么去统一的规划粒度大小呢 过大的颗粒用何种统一的方式去拆分呢 |
 |
jakend
2010-04-23
采用方案4：
增删改查为一个action 列表一个action(包括分页等) |
|
liwenjie
2010-04-24
luojy8877 写道 liwenjie 写道 这是action的粒度问题，建议采用一个领域模型或者小模块为一个action，比如订单、客户，而这个action保证不要太大，如果太大比如数十个方法，表明你的粒度过大了
如何控制模块的大小呢 比如按订单，客户分 订单只有5个方法 客户有十多个方法 怎么去统一的规划粒度大小呢 过大的颗粒用何种统一的方式去拆分呢 订单和客户是肯定要区分的，action的粒度service的粒度包括dao的粒度都会有这个问题，下层的dao的粒度比较小即方法就是单表的增、删、改，和客户需要的查询（IBatis中，客户需要什么查询结果通常就是一个sql），上层的粒度比较大，service层调用多个dao，service方法很可能是一个门面方法，放置事务。 action的方法肯定是一个操作用例一个方法。 说到原则还是按照业务逻辑区领域去划分，只要是一个业务领域的操作聚集，并且action内的方法不要太大就可以了，如果比如客户操作比较多，那就要分析都是些什么操作，可以分下类然后划分，我们不是为了划分而划分，其实目的只有一个，达到较好的可读性及良好的对象封装,不至于代码混乱 |
|
luojy8877
2010-04-24
liwenjie 写道 说到原则还是按照业务逻辑区领域去划分，只要是一个业务领域的操作聚集，并且action内的方法不要太大就可以了，如果比如客户操作比较多，那就要分析都是些什么操作，可以分下类然后划分，我们不是为了划分而划分，其实目的只有一个，达到较好的可读性及良好的对象封装,不至于代码混乱 若有所悟，但又比较模糊。以前划分领域模型比较粗糙，比如客户操作都仍一个action 订单操作都扔一个action。现在看来是以前分析得不够细，太粗旷了  应该按功能类型啥的分细些，不过现在只是有个模糊的概念。这里比如像一个客户对象 操作很多，我们还可以根据什么来提取更细的对象呢 动作归类吗？可以再给些启发吗
|
|
liwenjie
2010-04-25
是啊 其实把action分离成一个比较好的粒度就是为了达到良好的可读性和OO原则。把操作根据需求分下类，看看都是什么业务逻辑，肯定是可以划分为更细的分类的
|
|
皇室勇少
2010-04-26
一直以为这里没什么人气。贴子发表了这么多天之后才有人回答。。!
所以一直就没来看过! 方案我解决了! 目前我采用的是! 类似 struts1 formAction的设计! 对实体进行封装! 然后在实体上面再进行抽象! 因为大概 5-8个实体会组成一个小模块! Abstract BaseAction[顶层Action] | Abstract ModuleAction[模块action] | | | Action_1 Action_2 Action_3 采用的是这种方案。 |
|
luojy8877
2010-04-26
皇室勇少 写道 一直以为这里没什么人气。贴子发表了这么多天之后才有人回答。。!
所以一直就没来看过! 方案我解决了! 目前我采用的是! 类似 struts1 formAction的设计! 对实体进行封装! 然后在实体上面再进行抽象! 因为大概 5-8个实体会组成一个小模块! Abstract BaseAction[顶层Action] | Abstract ModuleAction[模块action] | | | Action_1 Action_2 Action_3 采用的是这种方案。 是不是把实体先封装成一个action 主要是些属性的set方法 用于获取请求提交的参数 然后再按业务分类划分成多个业务action继承对应的实体action |
|
皇室勇少
2010-04-28
一般一个模块会包含5-8个实体[不一定]
所以应该是反过来 |
