Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When it comes to OO database access you see two common approaches - the first is to provide a class (say "Customer") with methods such as Retrieve(), Update(), Delete(), etc. The other is to keep the Customer class fairly lightweight (essentially just properties) and perform the database access elsewhere, e.g. using a repository.

This choice of approaches doesn't just apply to database access, it can crop up in many different OOD scenarios. So I was wondering if one way is preferable over the other (although I suspect the answer will be "it depends")!

Another dev on our team argues that to be truly OO the class should be "self-contained", i.e. providing all the methods necessary to manipulate and interact with that object. I personally prefer the repository approach - I don't like bloating the Customer class with all that functionality, and I feel it results in cleaner code having it elsewhere, but I can't help thinking I'm seriously violating core OO concepts!

And what about memory implications? If I retrieve thousands of Customer objects I'm assuming those with the data access methods will take up a lot more memory than the property-only objects?

share|improve this question
1  
If I retrieve thousands of Customer objects I'm assuming those with the data access methods will take up a lot more memory than the property-only objects? -- No. Code only takes up space one time (at the class declaration level), regardless of how many objects you have. –  Robert Harvey Oct 16 '12 at 19:33

1 Answer 1

up vote 6 down vote accepted

One of the major principles of good OOP design is Separation Of Concerns.

Persistence - the loading and saving of object data is a separate concern to the business concerns of the object, the thing it is modelling.

As such, persistence concerns should be handled by a separate object - one often used pattern that you have mentioned is indeed the repository pattern.

share|improve this answer
    
I imagine persistence is a little more clear cut regarding SoC. However my real-world problem is a little different - I'm modelling physical valves that are opened and closed via the serial port. I don't know whether to implement Open() and Close() methods on the Valve class, or have a separate "ValveController" class. Managing the dependencies (comms library, configuration, etc.) feels like it would be simpler with the latter approach, rather than having to pass them to each valve instance (created by deserializing an XML config file). Would be interested in your opinion. –  Andrew Stephens Oct 16 '12 at 21:55
    
In your valve case, i would look at MVC pattern. You can still use the repository pattern to persist your object in database. –  Yusubov Oct 17 '12 at 2:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.