Database in object-oriented design?

Question

Where do databases fit into object-oriented design? Lets say for example I had a articles database simple straight to the point, my use case diagram had scenarios for search articles, view article, and create article.

Should I have an article class with a connection to the database within the class or just a global database class so that other classes say user class can access the same connection?

Also should I use tables as objects such as article being it's own data object then having a class like ArticleApi for CRUD operations?

Another also if anyone has any start-to-finish object-oriented analysis and design tutorials that would be great.

Sorry for such a novice question I come from procedural programming practices and trying to move into the object-orientation part of software development.

Answer 1

You didn't specify any particular platform, so it's not gonna be a very accurate answer.

Where do databases fit into object-oriented design?

I guess we're talking about RDBMS, right? Well, they don't. This is why we need ORM software, like Hibernate for Java or Doctrine for PHP.

Should I have an article class with a connection to the database within the class or just a global database class so that other classes say user class can access the same connection?

Also should I use tables as objects such as article being it's own data object then having a class like ArticleApi for CRUD operations?

There are basically two common approaches for ORM architecture:

• Data Mapper, where your domain objects are just plain-old objects, without any dependencies to ORM/database. You should model your model in OO-way and then map it into your database. You've got a separate set of objects (EntityManagers) for dealing with actual persistance.
• Active Record, where your domain objects are tightly coupled with ORM and they provide a set of methods on their own for handling database-related operations.

In my personal opinion data mapper approach is superior to active record as it follows SOLID principles. But active record might be very usefull as well.

---

You should generally remember that your domain model (object oriented) and database model (rdbms) are two different things that have to be modeled with a different guidelines.

Answer 2

There is no single correct answer - all depends on application you are building. You can use Transaction Script approach (which is pretty procedural) for simplest applications.

Then you can evolve to Table Module - approach which uses class for each table in database, and that class is responsible for managing all data from table.

For more complex applications you will have Domain Model (usually even before you will have database). And you will need Data Mapper to map your Domain Model classes to tables in Database (you can map single class to many tables and vice versa). With power of modern Object Relational Mappers usage of Domain Model become much easier, because most part of this mapping is done automatically. Some tools like Entity Framework in .NET even allow you to generate Domain Model from Database tables.