
不是,相当于setter。至于何时new这个dao层对象的,是你在dao层对象上做了@Repository注解,这是spring就会为你实例化这个对象。然后当它看到@Autowired是它就会去它的上下文中找到跟这个变量类型的相同的实例进行注入了。我的建议是Service用来处理
业务,当然如果划分的更详细一点,可以再添加一个ServiceIMPL层,把Service里面只放业务的
接口,在ServiceIMPL具体实现业务,而action主要用来处理业务逻辑。你要分清楚业务和业务逻辑的区别。这么跟你说吧。每一个业务你可以想象成一个最基本的 *** 作,比如说增、删、改、查、验证、判断等基本 *** 作。而业务逻辑好比再什么情况下进行这个 *** 作,比如说,当用户点击查询时,你就该进行查询 *** 作,当用户点击删除按钮,你就该进行删除 *** 作,而这些请求的处理可能都交给同一个action,所以你就应该在action中写好这个业务在什么情况下进行处理,也就是业务逻辑。不知道我这样说你能否明白?这里的Service就是每一个最基本的 *** 作。action就是用来处理业务逻辑的。估计你那里 调用者拿到的 只是一个 接口. 看不到实现.
这个是 接口设计的目的, 也就是你 客户端, 只调用 接口定义的方法. 而不管具体的实现是怎么处理的.
这样, 如果 具体实现类发生变化了, 只要还是 符合接口定义的, 那么客户端不需要重新编译.
你可以把新加的方法的定义, 追加到 接口上面.
如果不允许修改接口.
那么恐怕你要用 比较 难看的代码来写代码了. 还不确定能不能执行通过.
例如
接口 ITest 定义方法 HelloWorld()
实现 TestImpl 实现方法 HelloWorld(), 还写了另外一个方法 SayHello()
客户端一般是只有一个类型为 ITest 的变量。
例如
ITest test = 某工厂方法获取实例()
// 这个是没有问题的。
test.HelloWorld()
// 下面这个是 编译不通过的.
test.SayHello()
// 尝试下面这种修改, 可以编译通过, 但是不能保证 100% 可执行, 这个要看前面的 工厂方法是如何创建 TestImpl 实现的。
((TestImpl) test).SayHello()
评论列表(0条)