Which is a Better class design

Question

If I have an object, say, a user class, with say First & Last Name properties what is a better way to populate it:

1. The PAGE instantiates the class and the PAGE calls the business layer to popualte the class. (In this case the class is essentially a container for data).

or

1. The class itself not only has the properties, but it also has a method to call the business layer, populate itself and return itself populated to the page.

Answer 1

I'd go for the former. I think it's cleaner, and that way your User class can stand on its own, even if the business layer changes.

Note, also, that the former would seem more conducive towards using a 3-tiered MVC architecture as well.

Answer 2

I prefer the former. With the latter you end up forcing dependencies in the weirdest places.

Answer 3

I would have an abstract superclass for all the business objects implement a reloadData() method. It can be tested separately from the web environment, and the web environment does not depend on the data layer.

Answer 4

The way I look at it is you have to have separation of concerns. Testing is much easier too when you have less dependencies. I would use the first method.

Answer 5

It really depends on what you are going to use that class for. Is it only ever going to be a container that you populate and use for display? Are you going to be modifying that data and using it to update your database?

Basically what you are looking at is the DAO/DTO set of functionality. In case #1 you are talking about a data transfer object (DTO) it's just a container for the data. In case #2 you are talking about a data access object (DAO) it's an object that understands how to persist your data and where to get it from.

What you are missing is a case #3 which is a business object that understands the business logic associated with your data. i.e. what permissions does my user have, what is my users position within the company (assuming a business user).

Unfortunately there is no one correct answer, it all depends on what you are trying to build.

Answer 6

I'd suggest reading up about the factory method and abstract factory patterns, with a view to delegating creation of the class to something other than the class or the page. Here's why:

The page is focused on page stuff - it only cares about something that holds a first and last name, not the type of class. Therefore, it shouldn't create the class, just ask for an implementation. The page only really cares about an interface, with maybe firstname and lastname properties, and maybe a save() method.

If the class knows about the specifics of the business layer, you have dependencies you don't need. To change the business layer, you'd have to change the class internals or change the page so it creates a different class. If you did that for many classes, changing the business layer would require many changes in the class and/or page layers.