What design patterns should I apply in application with database access

I will start to develop an application that has to acc开发者_如何学JAVAess to database. What kind of design patterns area usually need to be implemented to make my application more flexible for example changing DB client from SQL to Oracle.

I believe to perform execution of some query I can implement Template Method Pattern. And to get connection a singleton pattern with double check would be sufficient.

Is there anything else I should know before starting?

Application will be developed in C#, so there is support for object inheritance and polymorphism.

Any help is appreciated.

Make sure all your code is encapsulated in a data access layer. Code against interfaces so that if you need to write a new data access library, you don't have to change all calling code. This will at least isolate all data access into on library. How likely is the changing of database to be? Don't make the software complex for the what-ifs as this will just make life more difficult.

Abstract something 'on-fly' and only when You can clearly see a benefit.
Otherwise - that's just waste of time.

Do not think like:

I should use pattern [x] because it might fix [y]

Think like this:

Oh crap, again got to write same stuff. Let's see how we could avoid that...

There's a good design pattern called Data Access Object, you will have to incorporate it into C#.

Summary:

The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP) or low-level sockets. The business component that relies on the DAO uses the simpler interface exposed by the DAO for its clients. The DAO completely hides the data source implementation details from its clients. Because the interface exposed by the DAO to clients does not change when the underlying data source implementation changes, this pattern allows the DAO to adapt to different storage schemes without affecting its clients or business components. Essentially, the DAO acts as an adapter between the component and the data source.

Check the Catalog of Patterns of Enterprise Application Architecture by Martin Fowler.

You may find a few good ideas there.

you should investigate the user of the data mapper pattern to keep the implementation details of how your data is stored (SQL/Oracele/Access) independent from the use of the data itself.

http://martinfowler.com/eaaCatalog/dataMapper.html