ssh一些设计疑问

Question

很深的设计问题啊。
1, 个人认为 业务逻辑层与struts之间总是使用参数进行耦合 可以提高灵活性.
2, 文件过大 没有明白lz 的意思.
3, 定义常量的静态类: 优点是使用方便 ,性能更好. (适合不变化的一些值 如编码设置等 .)
   配置文件: 灵活性好.可以随时修改   .  缺点: 要通过解析.使用麻烦.而且要去读取这个配置文件.无疑要消耗性能.
   这个问题也就是 在  灵活 和 性能 上做一个权衡把。纯属个人观点.

Answer 1

回楼上：第一点：如果业务与struts通过领域模型进行耦合，好像更加灵活啊。比如，我要修改其中的属性，只需要在模型/web层/数据库 等进行改动。
       但如果使用参数耦合，我要在数据库/web层/业务逻辑/接口/action 这些地方进行改动，而且还造成了多余的代码，这样是否有意义呢？
       注：struts可以支持在web层/action 通过领域模型进行值传递。
第二点：就是说，如果所有的领域模型都有关联，按照要求来说，应该把所有的业务逻辑都置于一个业务逻辑类中，这样是否会造成这个业务逻辑类过于庞大？
        会不会有更好的方法避免的这样的问题呢？
第三点：楼上的朋友叫的很有道理，受教了！！

Answer 2

struts2支持属性驱动和模型驱动 我也觉得模型驱动更灵活 而且编码比较少 
刚接触struts2 其他的还不明白

Answer 3

我也总感觉struts2.0不是很爽..说不上来哪里不爽

Answer 4

我用 struts2 + ejb3(hibernate3) 进行开发。
1、dao 层可以抛弃，但需要一个 BaseEntityManager 或 BaseEntityService 类，该类使用范型实现基本的 CRUD 操作，其他业务逻辑 Manager 类扩展该类，实现特殊的业务逻辑，业务逻辑层和 struts 之间通过领域模型进行耦合。
2、仔细分析一个业务逻辑的“所属”问题，确认和该业务逻辑更加“亲密”的 Manager，并放置到该 Manager 中。
3、常量应放入到不同的静态类中，而不是一个 Constants 中。以上属于个人意见。

Answer 5

1.看来楼上的几位朋友都认为的确适合使用领域模型进行耦合。2.如果按照更加"亲密"放置到manager中，但问题又出来了。可能会令一些Action同时需要多个Manager了。这样是否合适？3.为什么常量要放在不同的静态类中，不放在一个Constants呢？请解释一下，为什么这样？谢谢大家的回答！受益非浅！

Answer 6

2、“可能会令一些Action同时需要多个Manager了。这样是否合适？”——这是完全正常的！
3、“为什么常量要放在不同的静态类中，不放在一个Constants呢？”——这个问题怎么说呢，如果是零散的系统级常量放到 Constants 中没有问题，但是有些实体属性常量，如销售单上的“发票种类”，我觉的应该定义一个 InvoiceTypePropertyConstants 来存放常量（因为 InvoiceType 也可以在采购单中出现，所以如果放到销售单中是不适合的）。另外说一下，如果你觉得适合当然也可以在 xml 文件中配置，相应的类用单例模式，不存在2楼所说的性能问题（一次载入）。

Answer 7

哦，附带说一下，Manager 负责的是业务逻辑，Action 负责的是访问逻辑（或者说是页面逻辑、页面导航），这两个是解耦的，从框架上说是完全不相干的。

Answer 8

我给系统采用了一种架构，大家看看好不好？有什么不对？每一个领域模型对应一个Action类，每一个领域模型对应一个Service接口，这个接口包括这个领域模型的基本操作。这个Action将依赖这个Servcie接口。然后有一个实现类，实现以上所有的Service接口。这样，实际上Action依赖的还是简单的与自己相关的Service接口，但实现类进行关联操作也比较方便。这样基本的操作就可以很好的实现了。然后，再定义一个接口(或多个接口)，表示多个领域模型之间关联的一些操作。开始的实现类还是实现这个(或这些)接口。结论：
每个Action类只依赖自己相关的接口，不相关的接口，完全与已无关。
实现类实际只有一个，但是实现了所有的接口。只要关联操作的接口定义的好，Action的依赖会尽量减少。
这样也不至于接口过于庞大。大家帮忙参考一下！先谢谢。

Answer 9

补充一下：
所有的Action类还是会依赖这些(与自己相关的)关联操作的接口。

Answer 10

每一个领域模型对应一个Service接口——这个没有问题。然后，再定义一个接口(或多个接口)，表示多个领域模型之间关联的一些操作。——这个要看具体情况，虽然这些操作会涉及多个领域模型，但如果“所属”关系比较明确，我觉得没有必要另外定义接口。每一个领域模型对应一个Action类——这个问题有多种情况，我简单的说一下：
1、如果是“传统的” Web 应用，每个 Action 应该对应一个页面比较合理，实际上大部分应用也是这么做的。
2、如果按 REST 构架思想，每个 Action 应该对应一个领域模型（这里领域模型既是资源）。
第一种做法会比较简单，第二种做法除了工作量大还会涉及其他很多知识，但是也拥有 REST 构架的好处。如果你的应用是纯粹的 Web 应用，并且不存在为其他第三方提供接口的，建议第一种做法。

Answer 11

太好了，思路开拓了很多！让我着实能够深入了一点这些。。可否介绍一些这样的书籍给我看一下呢？我感觉xcjself 你的架构懂的很多啊！向你多多学习！

Answer 12

对于我一个实现类来实现所有接口的这种方式，xcjself你觉得怎么样呢？？或者说有更好的方法？