This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

What you've been using before isn't exactly the DAO pattern. You're creating DAO, but using the Abstract Factory pattern.

IoC replaces, no implements and combined creational patterns, such as the one mentioned above and others like the Builder pattern and the Prototype.

Of course the result of your two code snippets is exactly the same, except for the fact that the one using the programmatic Abstract Factory pattern is referencing the factory itself. It knows where to get the DAO whereas in IoC, it wouldn't. When using Dependency Injection (you better use that term) the DAO is injected by the framework, without passing the dependant information about where it got the DAO.

Thank you for your reply.I understand it now. :-) You mean that my first code is not DAO pattern? I see it in the "Sun's blueprints " .So mybe I think wrong . I also want to know how to implements it using DAO . Could you change above code to a DAO implement? Thks

Comment

You're still using the DAO pattern here in both cases in that you have a logical data access object whose interface defines a contract meeting your persistence requirements.

What's different is how the DAO is located. In the getInstance() case you're going out and finding it, in j2ee speak this is called a "Service Locator" and you're locating it using a Singleton.

In the IoC an assembler object -- the spring container -- locates the DAO for you and hands it to you - the user of the DAO is removed from knowing where the DAO reference came from. The main advantage is you make service location a 'separate concern' allowing you to vary it more easily, and use your DAO client more easily in different envrionments.