1.Action层
2.Service层
3.Dao层
请教一下大家这种分层设计的粒度怎样才合理呢？
对于一个模块的 是1个Action对应一个service，再对应一个Dao比较好，还是说
多个Action对应一个service，再对应多个Dao比较好？
或者大家有什么更好的设计，说说好处。。。。
例如现在项目有几大模块，数据初始化模块，系统管理模块。
数据初始化模块下面又分 用户初始化，机构初始化，每个初始化下又有各自的增删改查，
这时候，我是设计成一个 dataInitAciton好，还是单独为每个初始化功能设计一个Action好？
同理service和dao要如何设计？
6 个解决方案
#1
1个Action对应一个service，再对应一个Dao比较好
#2
理由呢？
我感觉如果分成多个Action，
那我在处理一类问题的时候，业务逻辑会更清晰一点。
例如;
处理数据初始化模块的用户初始化和机构初始化的时候，如果用户和机构分别有自己的Action。
那么在处理用户的信息的时候，用户action不会有机构的信息和一些不相关的信息，这样逻辑会更清晰一点。
我感觉如果分成多个Action，
那我在处理一类问题的时候，业务逻辑会更清晰一点。
例如;
处理数据初始化模块的用户初始化和机构初始化的时候，如果用户和机构分别有自己的Action。
那么在处理用户的信息的时候，用户action不会有机构的信息和一些不相关的信息，这样逻辑会更清晰一点。
#3
struts2 里面引入ofbiz
1个Service 对应多个Action 比较好 减轻好多代码量 容易理解，业务挺清晰 对于Dao 最好是一对一（个人觉得 嘿嘿）
1个Service 对应多个Action 比较好 减轻好多代码量 容易理解，业务挺清晰 对于Dao 最好是一对一（个人觉得 嘿嘿）
#4
你实在不行 画个UML类图 就一目了然了
#5
我现在倾向于一个模块下建多个Action,这样不会有太多的类耦合在一个action中，避免修改action的时候影响到其他部分，同时多个action也不会导致代码太复杂而不容易被其他人了解。
#6
我感觉这个应该从项目大小来说，如果很大的项目都放到一个DAO中，那就臃肿了
#1
1个Action对应一个service，再对应一个Dao比较好
#2
理由呢？
我感觉如果分成多个Action，
那我在处理一类问题的时候，业务逻辑会更清晰一点。
例如;
处理数据初始化模块的用户初始化和机构初始化的时候，如果用户和机构分别有自己的Action。
那么在处理用户的信息的时候，用户action不会有机构的信息和一些不相关的信息，这样逻辑会更清晰一点。
我感觉如果分成多个Action，
那我在处理一类问题的时候，业务逻辑会更清晰一点。
例如;
处理数据初始化模块的用户初始化和机构初始化的时候，如果用户和机构分别有自己的Action。
那么在处理用户的信息的时候，用户action不会有机构的信息和一些不相关的信息，这样逻辑会更清晰一点。
#3
struts2 里面引入ofbiz
1个Service 对应多个Action 比较好 减轻好多代码量 容易理解，业务挺清晰 对于Dao 最好是一对一（个人觉得 嘿嘿）
1个Service 对应多个Action 比较好 减轻好多代码量 容易理解，业务挺清晰 对于Dao 最好是一对一（个人觉得 嘿嘿）
#4
你实在不行 画个UML类图 就一目了然了
#5
我现在倾向于一个模块下建多个Action,这样不会有太多的类耦合在一个action中，避免修改action的时候影响到其他部分，同时多个action也不会导致代码太复杂而不容易被其他人了解。
#6
我感觉这个应该从项目大小来说，如果很大的项目都放到一个DAO中，那就臃肿了