POJO IN ACTION实例代码里有如下一段
public TransferFacadeImpl(AccountRepository repository, MoneyTransferService service) {
this.accountRepository = repository;
this.transferService = service;
}
这是facade层的构造器，唯一一个构造器，我很不理解的是为什么构造器参数还要传入service对象，service对象是facade下一层的，也就是服务层的，然到界面调用facade的时候还要先构造一个service对象，不太可能吧?
另外 Repository资源对象是在什么时候创建的？有谁创建的？
[b]问题补充：[/b]
to :lewhwa
facade 的确封装了service 。但关键是这里在创建facade的时候就的传入一个service对象，facade是由界面层调用的，界面层要创建facade的时候，难道还要先创建一个service，再创建一个repository，最后再构造一个facade，那界面不就一下涉及到了3个属于不同层次的类？为什么facade自己不创建service呢？
[quote]facade 的确封装了service 。但关键是这里在创建facade的时候就的传入一个service对象，facade是由界面层调用的，界面层要创建facade的时候，难道还要先创建一个service，再创建一个repository，最后再构造一个facade，那界面不就一下涉及到了3个属于不同层次的类？为什么facade自己不创建service呢？[/quote]
有这样的疑问很正常。从目前你提供的信息来看，比较混乱。但是，在真实的应用场景中，是多个模式组合应用的结果。比如此例，Service的创建可能采用Factory Method模式，而调用者根本不用知道Service对象是如何生成的（在这里当然可以IOC容器）。Facade和Factory Method同时出现，并共同完成对子系统的封装。哪为什么Facade不自己来完成Service呢？灵活性决策使然，前面说了，可以Factory来创建，可以用IOC容器得到Service对象。
关于repository，Facade，Factory Method以及Service应该放在一个包中，处在同一层次。
建议看看书上，看看有没有相应的Factory Method的内容？
[quote]这是facade层的构造器，唯一一个构造器，我很不理解的是为什么构造器参数还要传入service对象，service对象是facade下一层的，也就是服务层的，然到界面调用facade的时候还要先构造一个service对象，不太可能吧? [/quote]
Facade是GOF 23中的一种，中文叫外观或者门面模式，其定义为：
提供了一个统一的接口，用来访问子系统中的一群接口（服务也是接口）。外观定义了一个高层接口，让子系统更容易使用。
本例正是Facade的妙用。Service是接口，一定要暴露的。由于Service较多，所以定义一个外观来统一提供服务。外观模式让客户和子系统之间避免紧耦合。
[quote]另外 Repository资源对象是在什么时候创建的？有谁创建的？[/quote]
我没有POJO IN Action, 我想应该在书的上下文中找到。
Facade应该采用这种模式引入其他.Service;
AccountRepository 也应该是包含部分逻辑的DomainObject的;
[quote]facade 的确封装了service 。但关键是这里在创建facade的时候就的传入一个service对象，facade是由界面层调用的，界面层要创建facade的时候，难道还要先创建一个service，再创建一个repository，最后再构造一个facade，那界面不就一下涉及到了3个属于不同层次的类？为什么facade自己不创建service呢？ [/quote]
IoC 就是这么来处理的;
不过如果Spring类似的框架,框架本身可以帮你DI,就不用调用者管理对象的生成以及诸如了.