advise for 3 tier OO beginner

[Mike P]

I'm new to writing separate classes for each 'business object' and I'm
wondering if I'm going about it the right way. If I have a property of
a business class that has to be within a range of values specified in a
database table, is this how I would go about it?


public int JobRoleKey
{
get
{
return this.intJobRoleKey;
}
set
{
DataAccessLayer da = new DataAccessLayer();

bool blnValidJobRole = da.ValidateJobRole(value);

if (blnValidJobRole == true)
{
this.intJobRoleKey = value;
}
else
{
throw new JobRoleKeyException();
}
}
}


Many thanks,

Mike

 

[Andy]

There's a great book, which describes how to buidl a framework on which
to build business objects. Its called Expert C# 2005 Business Objects.
The framework is complete however, so if you like the functionality
you can actually build and use it.

The author is really good about making updates and supporting us on his
forum: http://forums.lhotka.net/forums/.

Andy

 

[Mike P]

All I really want to know is whether I am going about this the right
way....can any experienced OO programmers help?

 

[sloan]

You are mixing objects and object creation.
This is not a good idea.


http://sholliday.spaces.live.com/
6/5/2006 5/24/2006

Check my samples there (2.0 and 1.1 respectively)

You want to seperate your objects and their creation, by using a
EntityController or EntityManager (where "Entity" is anything like Emp,
Person, Department , etc)

You need a validator type thing.


public Employee ValidateEmployeeJobRoleKey ( Employee emp , int jobRoleKey )

{

DataAccessLayer da = new DataAccessLayer();

bool blnValidJobRole = da.ValidateJobRole(jobRoleKey );

if (blnValidJobRole == true)
{
emp.JobRoleKeyProperty = jobRoleKey;
return emp; // Notice, if the rule passes, I set the
appropriate property and return it. Simple, yet smooth.
}
else
{
throw new JobRoleKeyException();
//alot of times, I return a null here. Instead of using exceptions.
That way, the caller can check for null, and know if or if not it passed,
without the expense of throwing exception around.
}

}


and then the code will look like this (if you use my null trick)

Employee e = new Employee ();

e = e.ValidateEmployeeJobRoleKey ( e , 1001 );
if(null==e)
{
// I know it didn't work.
}


The null trick is good sometimes, sometimes its not. Don't lose sight of
the bigger issue.
The Employee object containing too much stuff in it.




This code should NOT be a part of the Employee class, because you want to
seperate your dal access, from the object itself.

Why? One reason is becasue your rules might change. Today you're checking
against a datastore.
2 years from now, you might have a range. (1000 to 2000 are valid).

You don't want to have to open up and change the Employee object, because a
data validation rule changes.
Else, you have to retest (or you're supposed to anyways) the entire Employee
object.
This way, you have isolated what might/can change, and how you test against
it.

 

[sloan]

Here is another option for the checking.

Again, the rule of thumb is that

"Exceptions should be EXCEPTIONAL"

If you expect the jobRoleKey to fail with any regular frequency, don't use
exceptions to handle this.
Use null or bool or some other kind of check.




You can test this, but you might have to pass the emp object in as a ref
value.

This is bool version.

public bool ValidateEmployeeJobRoleKey ( Employee emp , int jobRoleKey )

{

DataAccessLayer da = new DataAccessLayer();

bool blnValidJobRole = da.ValidateJobRole(jobRoleKey );

if (blnValidJobRole == true)
{
emp.JobRoleKeyProperty = jobRoleKey;
return true;
}

return false;
}


and then the code will look like this (if you use my null trick)

Employee e = new Employee ();

bool b = e.ValidateEmployeeJobRoleKey ( e , 1001 );
if(true==b)
{
Console.WriteLine ( e.JobRoleKeyProperty );
}
else
{
// we don't have a JobRoleKeyProperty !
}

 

[Greg Young]

I might look at using the specification design pattern (combined with the
notification design pattern) to do this.

There are two great "conceptual" books I will point you towards that will
help you alot.

Jimmy Nilsson Applying Domain Driven Design and Patterns
Eric Evans Domain Driven Design

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung