Is it a good practice to write all database access code in one class?

I created for a project a single class, that contains all access code to the database. Is this a good practice , under the assumption that this class doesn't contain any logic, or should i use several classes? If yes, how should i partition my code? I use C# .开发者_JAVA技巧Net.

Actually Under the concept of MVC framework, it is a good practice to create a different class for database access, seperate class for logic and seperate class for your views.

You are doing good if you are writing a seperate class for database access under the assumption that it does not contain any logic.

In Agile Developement there is a term named as Database Encapsulation Layers.

A database encapsulation layer hides the implementation details of your database, including their physical schemas, from your business code. In effect this layer provides your business objects with persistence services – the ability to read data from, write data to, and delete data from – data sources. Ideally your business objects should know nothing about how they are persisted, it just happens. Database encapsulation layers aren’t magic and they aren’t academic theories; database encapsulation layers are commonly used practice by both large and small applications as well as in both simple and complex applications. Database encapsulation layers are an important technique that every agile software developer should be aware of and be prepared to use.

An effective database encapsulation layer will provide several benefits:

-> It reduces the coupling between your object schema and your data schema, increasing your ability to evolve either one.

-> It implements all database-related code in one place.

-> It simplifies the job of application programmers.

-> It allows application programmers to focus on the business problem and Agile DBA(s) can focus on the database.

-> It gives you a common place to implement data-oriented business rules and logic.

-> It takes advantage of specific database features, increasing application performance.

Hope this helps.

If your database is quite small, say, only a couple of tables, you could write all your queries in one class. otherwise I would suggest that per Entity/Table one class. for example, StudentDao.class will only focus on the queries to database table "STUDENT", and TeacherDao.class will only contain queries to table "TEACHER". if you are gonna implement a complex business logic, you may want to have a service class, to weave StudentDao and TeacherDao together.

Unless your data access is very simple, probably not.

you probably shouldn't need to write this code yourself. Take a look at some Object Relational Mapping tools. NHibernate is a popular .Net solution. http://en.wikipedia.org/wiki/NHibernate

If you really do want to write it yourself look up design patterns in this area, like the Data Transfer Object pattern. http://martinfowler.com/eaaCatalog/dataTransferObject.html

These are some of the suggestions while accessing database.

1.) Always keep your database access parameters in a properties file. Use a handler to get those data. Because when you change your database then you need not change your code just make a change in the properties file it's enough. -- So here you need a handler class.

2.) Never create a single class (a god class) which performs all the actions. Disperse your behaviour in to different classes depending on the intent. For example Keep all read behavior in one class, Write behavior in another class ... so on.

3.) You can create a class which deals with connection creations and pooling stuff... Hope this helps.