Re: Designing classes in business layer
On 3/6/2010 9:10 PM, raringsunny wrote:
Hi,
I have a question regarding the design of a class. Should the
properties of a class exist in a separate class from the methods of a
class?
After reading the paragraph below, I believe you're using the wrong
phrase when you say "properties of a class".
For e.g. If I have a class named "Employee". Should I make two
separate classes; one holding methods of a class such as 'Add
Employee', 'Update Employee' and 'Delete Employee' and another class
holding its properties such as 'Employee ID', 'First Name', 'Last
Name'.
Add, Update, Delete (and I'll suggest Get) are called CRUD operations
(Create, Retreive, Update, Delete). They are commonly found in service
layers. In particular, DAOs (Data Access Objects), DAOs manage the
persistence of objects (which is a separate and distinct concern from
the objects themselves).
I remember working on one project where we had separate classes for an
object's properties and a separate class where all the methods of the
class were implemented in the business layer using a class library
project template.
Please advice on what would be a most appropriate and effective
design?
If you have persistence requirements, then using a separate class for
that concern makes sense. Even using an entire framework would be
useful (look up Hibernate, EJB3, and JPA for some useful information)
Hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>