OOP design in .NET with databases

[Friedl Neurauter]

Check out the Data Access Objects (DAO) design pattern
proposed by E. Gamma in the Go4 book.

-----Original Message-----
I am struggling with a design issue using .NET.
Let's say we have an object model and now want to code it. In the objectmodel is an Access database. Most programmers would start a new project andslap a connection and data adapter object on a form and start coding.Unfortunately this could not possibly fit any object model ever conceived.I am trying to determine best practices with this issue. My suggestion isthe following:

Encapsulate the database into a class. This class would be an aggregate ofother objects such as Customer, Company, etc. All needed collections such ascustomer names would be other objects. There would be methods in the classfor accessing the database and filling the properties as needed.
Does anyone have comments on this? All the books I have read on ADO.NETslap connections and data adapters onto the main form. This doesn't seem tobe very scalable. Is this the way people are really building .NETapplications?

Regards
Jerry
.

[Slonjo]

Wizards... FAH!

I've also written my own Data Access Block that the app's data access
object (DAO) inherits. It handles connections and common SQL method
calls to eliminate redundant coding.

The project's data access class contains all the app's SQL and is
exposed through a global property that all the other object classes in
the project can see/use.

Module AppCommon

Private m_objDA As MyDataAccessObject

Friend ReadOnly Property g_DAO() As MyDataAccessObject
Get
If m_objDA Is Nothing Then m_objDA = New MyDataAccessObject()
Return m_objDA
End Get
End Property

End Module

So from anywhere in my *.dll it's simply g_DAO.FetchMyResults or
g_DAO.cn to get to the database.

I also use stored procs.

Compartmentalization is a good thing.