Object oriented approach using RDBMS

I have a question regarding how to use an object oriented approach while using an RDBMS such as mysql. I am developing a small application that will keep track of billing. It is built in java and I am using a MySQL database to store data. My application has a costumer and a product class. Now normally if I were dealing with persistent data storage using arrays or different data containers I would have an update, delete etc for the customer class and one for the product class. However I find my self using more static methods than ever before. Because I don't have a array of customer for example I just have a database with customers in开发者_开发百科fo I see no point in creating a customer object just to delete it when I could just call a static method that deletes a customer (or product) based on it's primary id. In the end I feel like there is no reason to even create a customer or product class because there is no need for specific methods.

What I would like to ask everyone is how do you take an object oriented approach when using a RDBMS?

Design your Java classes using OO principles.

Design your DB with SQL and normalisation principles.

Then, run full speed into the challenge that is Object/Relational Mapping! :-)

Technologies like Hibernate and Ibatis are designed specifically to help with this, it's a well documented problem. Additional technologies like Spring can make their use really quite easy and pleasant to work with.

Abstract your persistence to a DAO (Data Access Object) layer, e.g. if you've got lots of classes like Vehicle and Animal, you would have DAOs like VehicleDao and AnimalDao to separate out how they talk to the DB from what they fundamentally do in your system.

FWIW, I advocate doing just this: good app design on the app side, good DB design on the data side. With that done, there's always a way to map the two when persisting and retrieving class data to and from the DB, and that's far better IMO than compromising one of your individual layers to "help" the other.

Using DTO's (Data Transfer Objects), which in your case would be classes that represent the objects in the database, abides by the Single-Responsibility Principle. Which is a design pattern based off of OOP principles (more specifically the process of encapsulation). This ensures that each of your classes accomplishes only one purpose. If you keep your business logic inside SQL strings it becomes hard to maintain and violates the DRY "Don't Repeat Yourself" principle. From my experience ORM's have expedited the process of system design. Try NHibernate. http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx

If you expect this application to ever grow (which is probably 99% of applications) then create the objects. Even if the delete is a single SQL call, down the road you might need to add in logic (delete rows in children tables, store audit data, you move to logical deletes instead of hard deletes, etc.)

Your database represents your business objects - fully normalized, etc.

Your object model represents how you need to work with the data in your code. They are usually not the same, e.g., you have a customer table linked one-to-many to an address table, but in code you use an object that contains both types of information.

Your Data Access Objects (DAOs) handle the business objects (i.e. read/write). Your service layer gets the work done, combining the output of the DAOs into your objects if necessary. Your service layer will handle transactions too as needed.

Abstracting your data access from your service layer will make it easier to maintain code, update the database schema, and facilitate testing.

Dealing with databases AND oo-code is always a hot topic. And some might say "JUST DON'T".

I don't agree with those, but I've seen a lot problems when I had to do so. I absolutely disagree with some of the others that immediately recommend OR-Mappers like Hibernate. In many cases you don't really have any benefits during development and gain a lot problems (performance, error diagnostics) during runtime.

As always it all depends of what you're doing in your app. You say, you don't have an customer object. Why is this? For example, if you just show all customers in a table inside the gui and the user can delete one of these by right-clicking or whatever, the best approach would be to read DB data via JDBC, put it into your JTable and having a static delete method using JDBC again.

But if you really deal with customers inside the app it will be useful to establish a customer object and then you need OR-Mapping. But you don't need a framework. Handwritten sql/JDBC does a great job in most cases.

From my point of view OR-Mapper-Frameworks can be a good thing in applications where performance isn't interesting and you're not in the mood for thinking about all that DB stuff (i.e. prototyping) in most other cases I'd go with handwritten code for reading and storing.

Domain model is good approach. Separate your business logic into a layer that does not depend on database directly. Use SOLID principles and look at Domain Driven Design. This way you will have readable OO code that is isolated and can be easily tested. Patterns like 'Repository' will help you keep focus on business requirements while working with realities of relational database. Essentially you define and interface like:

List<Customer> customers = Customers.WithOutstandingOrders(DateRange range)

And then implement this interface in the data access layer (outside your domain). The easiest way is to use ORM like Hibernate. The role of the database in this architecture is more of a 'bit bucket'. In other words, most logic lives in OO code and database just protects against data anomalies and speeds things up (using normalization, referential integrity and indexes).