Integrating DB code

Hey,

I'm just starting out in C# and getting to grips with OOD.

What are people's thoughts on the location of database access code in a C# program?

Off the top of my head, I see main 3 options:

1. DB code in its own class.
The main program has access to the other objects and also the DB class and acts as the go-between, keeping the objects themselves free of DB code.

2. Classes have DB code inside
Each object can perform its own DB activities and effectively manage itself but the classes then become less reusable.

3. DB Wrappers
Each class that needs DB access has a corresponding wrapper class that extends it and can do DB stuff.


I'm interested in opinions on which ties in nicest with good OO principles, and if anyone has any other suggestions?

The short answer is "It depends". What I mean to say is, what and how do you expect to use/reuse the objects involved.

I personally have designed using two schools of thought.

1. This is a relatively self contained app, though it MAY be extended to some degree. In that instance, I placed the DB access code in it's own class within the application and all DB calls went through this code.

2. This app will be distributed in some fashion. In the instance that comes to mind, I was dealing with an application that had a WinForms module that live on Sales Peoples' laptops. Another module was a web app running at the home office that managed some workflow. In this case, I encapsulated all the DB code into the objects themselves. That way I was able to pass the objects back & forth between the modules and the objects knowledge of its own state and location dictated how it interacted with the DB involved. Think in terms of a Sales person placing a "Special Order". While the app the salesperson used lived on their laptop, the object needed to connect with the loacl DB. When it got passed to the home office for processing via the next network connection, it needed to connect to the server at that location. Rather than trying to develop two separate and distinct data layers that would require changing both locations if the app were changed, or even if the underlying data for a single object was changed.

At some point, whether you're using strongly or weakly typed datasets, you need to have SOME understanding of the underlying data in order to develop useful code. If your trying to do something too generic, all you're doing is trying to recerate what MS has already done for you (i.e. DataSets, etc...).

Hope this helps,

Steve

My school of thought is to always put the data access in its own layer. Break it out into its own project completely, every time. Then I usually declare interfaces in another project that the DataAccess layer references and implements. The calling code will then go thru the interface to get to the underlying data calls. This allows you to swap out the data layer at will, like if you have to go between Access and SQL Server (or Oracle, or whatever). The top code doesn't need to change. Plus, other applications can reference this and use it, too. I usually follow the MVC pattern and have 3 layers... UI (View), Controller (Business code), and Data (Model).