Class Design Questions

[Burntchips]

Hello all,

I'm creating a wrapper class for entries in a database. I've created all of the properties in my class to match the columns in the database but I am wondering what is the best practice for instantiating one of these objects. The two approaches I'm debating are using either:

[VB]
Dim myPerson as Person = Person.LoadPerson("bob")
[C#]
Person myPerson = Person.LoadPerson("bob");

Or

[VB]
Dim myPerson as Person = new Person("bob")
[C#]
Person myPerson = new Person("bob");


Which of those are the best approach and why? Does creating a static LoadPerson method have any negative performance effects?

 

[chiph]

Go with the static method instead of using the constructor. Often, you'll want to create an instance in memory without having to hit the database to do it.

It also allows you to do stuff like clone your objects with a minimum of fuss (yes, you could create a copy constructor, but the standard under .net is to implement ICloneable for copying an object)

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Burntchips]

Alright if thats the case what should the constructor return or should there even be a constructor? Does it make sense to do something like:

Person newPerson = new Person("John", "Hutz", 12, "More info")


And that contructor would actually create a person entry in the database or should at create a virtual person and you need to call a .SaveToDB If thats the case is it better to do:

Person newPerson = new Person("John", "Hutz", 12, "More info")
newPerson.SaveToDB();

OR

Person newPerson = new Person("John", "Hutz", 12, "More info")

Person.SavePersonToDB(newPerson);


Also, in the case that I'm creating an object that simpley allows for viewing database data in the form of objects and not modifying the values of the objects (so all exposed properties are readonly) for an object like that should you even allow for a constructor? (as there would be no way to set the properties of the object even if you did create a new instance of the object)

 

[chiph]

You can create a parameterized constructor if you find that you're always setting those attributes anyway. It might save you some time.

But you should always have a default constructor, especially if this object will be serialized.

A .Save method would be good.

Keep in mind that a lot of these kinds of decisions are based on the needs of your application. But it's been my experience that tying database insertion/creation to object instantiation is generally a bad thing.

Being able to view an object without inserting a row into the database would be a good reason not to tie the constructor to database insertion.


If you get a chance, buy a copy of Rockford Lhokta's book: Expert C# 2005 Business Objects. It covers his CSLA architecture, which is pretty good for your typical CRUD-style apps. You can download the source at his site:

http://www.lhokta.net

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

I agree with chip, although my feeling is more intuitive. It generally has to do with the idea that an object's constructor shouldn't create objects, unless they are inherently a part of the object (composition), which a database connection isn't or at least shouldn't be. A composition relationship between two objects means that they share the same lifetime, and a database connection shouldn't live beyond its usefulness to the object. As such, it's more of a simple association relationship, and should be implemented via a method that's restricted to the purpose of pulling the data.

Bob

 

[CosmicCharlie]

To BobRodes and Chiph:

Thank you for the comment about not creating objects in constructors. I have recently been given the responsibility of creating a fully functional VB.Net data tier for my company's future applications, and am in need of good design advice. I had not thought of the particular issues to consider when writing a constructor, but these comments give me a lot to think about as begin my design process.

Charlie

 

[BobRodes]

Let me point out that a composition relationship IS generally implemented by creating objects in constructors. If you want to read up on the different types of association (simple association, aggregation, composition), a good book is "The UML Bible" by Tom Pender, available from Wiley Publishing.

Bob

 

[h0h0h0]

Wait a sec - there is a difference between creating an object and persisting an object. I think it's been illustrated here. Using the constructor to create an object is a pretty standard usage. I'll second the idea of not persisting an object in a constructor. Give the developer the control of when they want to persist an object via a .Save method. That method will call back to a DAO object behind the scenes.

 

[DonQuichote]

What about:

Dim MyPerson = thePersonsCollection.Item("Bob")

The collection could then be instantiated with the database object (or other storage object) and handle the storage, while the Person object itself is just being a person, constructed with either the values separately or a record (array or whatever) containing them.

See for more on this

http://www.w-p.dds.nl/article/wtrframe.htm