当你要设计一个东西的时候，首先考虑的是实体类，也就是传说中的model，比如User，这个基本上就是Java Bean。
假如你想加一个方法，可以添加一个用户。这个时候，你不可能在User这个类里面添加方法，因为你不可能说为了调用方法还得先new一个user出来，逻辑上说不过去。最好的方法是你再专门创建一个service类，比如叫做UserService。这个时候当你使用UserService里面的add(User u)方法的时候，就会通过UserService去操作数据库。
在更大的项目中，即使这样都还不行，因为你可能想要操作多个数据库，甚至多种数据库，这个时候就需要在UserService后面再加一个UserDAO。通过它来操作不同类型的数据库，从而达到屏蔽数据库的作用。这样的意思就是，对外提供一个接口，叫做UserService，然后由UserDAO来覆盖底层的东西，这样你将来换数据库，或者平台移植，就不太需要重写这些东西，只是添加一些model和service就行了。
ps: DAO=Data Access Object
以后的操作方法就是，你在UserService里面定义一个UserDAO类型的成员变量。假如UserDAO里面有一个方法叫做save(User user)，负责向数据库添加一个User的数据，那么你就在UserService里面写一个方法叫做add(User user)，在里面直接调用save(User user)就行了。save(User user)当然就提供了关于数据库的操作。
但是，问题又出来了，即使你写了UserDAO，假如里面实现了MySQL的操作，将来你要换数据库或者缓寸什么的，你还得改。这不是一样麻烦吗?
于是就有解决方法，那就是说将UserDAO也写成接口，然后分别创建几个实现类，比如说MySQL的，比如ORACLE的，将来你在Service里面，想调用哪个就调用哪个就完了，不会影响任何代码。就算将来再出了新的东西，也只是增加一个实现类的功夫罢了，完全不影响对外的接口。
可能不见得像现在说的这么完美，但是在大项目的开发中，这样做确实可以增加很多灵活性，让系统代码更加健壮。说句题外话，其实维护的成本不见得小于开发的成本，一个项目如果最初就能把可维护性考虑进去的话，虽然可能在开发的时候更加繁琐一些，但是一旦将来需要维护修改了(一定会的)，就会省很多时间成本。切记这一点。
记住一个大致的原理就是，如果系统对于访问有灵活性的要求，那么最好就写成接口。
说到这里，该说说配置文件了。
试想在大项目中，有很多很多的model类，很多很多的service类。有时候你希望你的service类不只有一个功能，那么最好的方式就是将service写成接口，然后写相应的实现类。举个例子吧，你写项目的时候总要测试吧，使用的是一样的功能吧。你不可能为了测试专门再去写一套代码吧。大项目肯定要访问数据库的，但是测试的时候不可能也访问数据库吧。那么将service写成接口，写一个实际中要使用到的实现类，再写一个测试用的实现类。实际使用的类该连接数据库就连接，测试的时候配置一个List就行了。
但是你总是不知道你有多少实现，还有你不知道你要new多少次，假如有一天你决定换一个实现，所有new的东西都必须全部换过，可能成百上千，非常容易出错。有问题就有对策，那么你写在配置文件中就好了。将接口和实现类绑定起来，调用的时候不管它的实现是什么，尽管调用接口方法就是了。某一天你不想用这个实现了，那么你只需要在配置文件中修改一行就行了，不管你用了多少次，只有这样才能保证在大项目的开发过程中修改代码的效率变高。上面说了这么多，这个就叫做Spring的注入，也就是Guice的基本原理。