Classes and data access.

Hello guys.

The other day I was developing an application and I created an Employee class to store and retrieve information about the employees in a database.

I declared all the properties, events and methods inside the class, even the data access methods within the class itself. But somehow this doesn't feel right, maybe it's just me because I'm starting to learn all the trades about OOP.

Now my question is, what do you guys think it's better, to include the data access method in a dedicated data class? or maybe it's okay to include the data access methods inside the class itself?

Discuss please. :)

I recommend you add attributes to your property that a persister can use to read/write the class to the database...the class itself should not care where or how it is persisted.

Quote:

---

Originally Posted by Merrion

I recommend you add attributes to your property that a persister can use to read/write the class to the database...the class itself should not care where or how it is persisted.

---

Umm, I see. So you think it's okay to use methods whether they're inside or outside the class as long as it does the job?.

The class should be the data, and the methods that work with the data. If you have methods that do something to the entire class, they might make more sense outside of the class, but it depends on what those methods do with the class.

I've often wondered about this logic as well. Personally, I like putting Load and Save style methods within the class to load in and write back data to the database. Load methods typically take an argument that is the primary key for the corresponding table in the database. Putting the methods outside the class didn't seem to make much sense.

This is just me though.

depends on the architecture and how you want to look at it... I've seen it both ways... one arguement for taking it out of the class and having helper data classes is if you have to deal with multiple database systems... then your class doesn't care if its being stored in SQL Server, Oracle, or a text file.

-tg

See I'm the other way around, I have got into the habit of having a specific data access class just full of shared methods that do the actual saving/loading against the database. I use my 'business object' classes such as Employee or whatever purely to hold the data in memory, they dont tend to have any methods at all. I'm not saying this is a good way to do it, in fact I think the opposite, it always feels like im not doing things the proper way when I do it like that... but then having methods within these classes also doesnt feel right to me. I mean say you have a method that returns all of your Employees from a database, you would have to create an instance of your Employee class just to call GetAllEmployees or whatever (unless its a shared method of course, is that how you all do it?) and then where does that data end up? Should the GetAllEmployees method in the Employee class populate some list or dataset itself or should it just return the data ready for some other routine to process it and display it etc and if so then where does that routine belong? It all gets rather confusing for me :(

I think the main issue I have is that in my programs I rarely use these classes such as Employee etc to actually represent something that the user is actively working on, I tend to just load things into textboxes etc and then call a method when the user clicks OK on whatever editing dialog window they are in that just saves the contents of these text boxes back to the database (thats a simple example but you get what I mean hopefully).

I would tend to agree with Merrion. If you think of it like this maybe it's easier.

A class is formal framework in which to store pieces of data in a manner that makes sense given its context. For instance consider a note class. This would have information like the heading, time and date and the body of the message. It may also have some private methods to format any of these data pieces.

Now you can use this class to create a note object or loads of note objects. Now applying the same logic you would then create a class that takes these note objects and save them to a database or file or whatever. Obviously you may need to adorn your note class for serialization but you would still need a secondary class to save the data the note object should not be responsible for saving itself.

That was my kind of thinking but then I just end up with one huge class that is responsible for saving everything because it seems daft having a 'secondary' class for every proper class just for the save/load methods..

That was my kind of thinking but then I just end up with one huge class that is responsible for saving everything

You need a class or method that knows how to save "a thing" (by using reflection and attributes to match the properties of that "thing" to the location where it gets saved) and then pass your classes into that class or method.

I have some code but it is (a) in C# and (b) quite big becuase it is works for oracle or SQL Server but can post it if you think that would help understanding....

Quote:

---

Originally Posted by DeanMc

I would tend to agree with Merrion. If you think of it like this maybe it's easier.

A class is formal framework in which to store pieces of data in a manner that makes sense given its context. For instance consider a note class. This would have information like the heading, time and date and the body of the message. It may also have some private methods to format any of these data pieces.

Now you can use this class to create a note object or loads of note objects. Now applying the same logic you would then create a class that takes these note objects and save them to a database or file or whatever. Obviously you may need to adorn your note class for serialization but you would still need a secondary class to save the data the note object should not be responsible for saving itself.

---

Thank you guys for your replies.

This way seems kind of interesting to me, I'm gonna give it a try.

The problem I've been having (not so much of a problem but something that's been bothering me) is that when I use the same class to save it's own fields, I end up with a long list of methods that just doesn't seem elegant, if code should be such a thing. I have tried a couple of times dedicating a class to do these save/loads from the database, and sometimes I end up with a long list of parameters, which is annoying for debugging but I don't know whether it's bad or not. Maybe it's not that It's bad to use such a class, but the way I code the methods themselves I guess.
Maybe I should learn to pass up collections instead of values as parameters.

If the method is in a class that is not the object itself, it should take one parameter... and object of that type. So the myDB.SaveCustomer method should take a parameter of type Customer class. Doesn't matter if there are 5 properties of the class, or 50... then let the method extract the data out of the class and send it on to the database.

If the save method is a member (non shared) of the class that it is saving (myCustomer.Save() ), then it shouldn't take any parameters, since you can access them all through the Me keyword. If it is a shared method (CustomerClass.Save()) then you are back to passing in the instance to it.

I've done it a number of ways, and the conclusion that I've come to, is that like most things programming, it all just really depends on what works for you and the situation.

-tg