Architechure Question

[ColinM]

Here I have two similar ways of populating a simple Employee class.
I'm trying to work out the pros & cons of each method.
1) Seems simpler but tightly-coupled to the DAL(Data Access Layer)

1)

class Employee
{
  public int ID;
  public string Forename;
  public string Surname;

  public Employee(int ID)
  {
     // Fill this Employee with values
     DAL.GetEmployee(this, ID)
  }
}

Employee emp = new Employee(5)

2)

class Employee
{
  public int ID;
  public string Forename;
  public string Surname;
}

Employee emp = DAL.GetEmployee(5);
[code]

What are your views on the best method?

 

[chiph]

I would vote for #2, as it would allow your DAL to return a collection of employees in addition to a single employee. It would extend the paradigm just a bit, whereas if you went with #1, it might be tough to return more than one employee.

Chip H.


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

 

[obislavu]

As the code is shown I also prefer the 2nd but I have some comments:

The first solution assumes that Employee class knows the DAL class.
The second solution assumes that DAL class knows the Employee class.
I will design an Employee class which is independent of the DAL class.
There are many solutions depending on what is in DAL class or classes.
I will do something like that

public class Employee
{
   private int ID;
   private string ForeName;
   private string SureName;
   //
   Employee (){};
   Employee(ref Hashtable ht)
   {
    if(ht.Containskey("ID") 
       this.ID = ht["ID"];
    else 
     {
     }
    if(ht.Containskey("Forename")
     this.ForeName = ht["ForeName"];
    else
    {
    }  
    
   } 
}
How to use:
The DAL dll will contains a function like that:
 public void GetEmployee(ref Hashtable ht, int ID)
{
   // this function will polulate the reference of the ht object with all attributes of an employee : id, forename, surename, hiredate, birthdate, title, department, salary etc...
}

Now:
    DAL MyDAL = ...
    Hashtable ht = new Hashtable();
    DAL.GetEmployee(ref ht, 5); // this function could return a ht with more than the three fields defined in the Employee class.
    Employee emp = new Employee(ref ht);

Solution 2:

More flexible solution is using the Attribute class:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)]
public class EmployeeColumnsAttribute : Attribute 
{
    public string EmployeeFields;
    EmployeeColumnsAttribute ( string EmployeeFields)
    {
      this.EmployeeFields = EmployeeFields;

    }
}
[EmployeeColumns("ID;Forename;Surename")]
public class Employee 
{
    Hashtable htEmployeeData;
    //
    Employee (ref Hashtable ht) 
    {
       htEmployeeData = new Hashtable();
       // Retreive the EmployeeColumns attribute object e.g. 
       Type type = this.GetType();
	EmployeeColumnsAttribute [] AttributeArray = (EmployeeColumnsAttribute []) type.GetCustomAttributes(typeof(EmployeeColumnsAttribute), false);
      string [] a = AttributeArray[0].EmployeeFileds.Split(";");
      foreach (string s in a)
      {
        htEmployeeData[ s ]=ht[ s ];
      
      } 
     }
}

How to use: 
The DAL dll will contains a function like that:
 public void GetEmployee(ref Hashtable ht, int ID)
{
   // this function will polulate the reference of the ht object with all attributes of an employee : id, forename, surename, hiredate, birthdate, title, department, salary etc...
}

Now:
    DAL MyDAL = ...
    Hashtable ht = new Hashtable();
    DAL.GetEmployee(ref ht, 5); // this function could return a ht with more than the three fields defined in the Employee class.
    Employee emp = new Employee(ref ht);

As you can see in this 2nd solution, the Employee class code is not dependent on the fields you want to store about an employee.
Another solution is to be able to build an Employee object with the field names that are retrieved from the database e.g. the names of the columns that refer to an employee in one or more databases.
This is not deficult starting from the 2nd solution , remove the attribute class and have a function in the DAL that retrives the attributes found in the database (column names from the tables) and store them in the hashtable object as the keys.
-obislavu-

 

[ColinM]

Thanks for the replies,

This has got me thinking more generally about OOP. In a lot of examples I've seen with lots of layers of abstractions. i.e. DAL, Business Layer, UI Layer.

However in "true" OOP wouldn't an Employee class have all these layers embedded inside.

Employee.Draw()
Would render the employee object to HTML for example.

Why shouldn't the UI layer be inside the object?

Anybody got any good links to read up on this?

 

[chiph]

Having the .Draw method inside the employee object is making a big assumption: that a GUI will always be involved.

If that's all your company deals with, fine. But it's been my experience that once you send an employee to the screen, the next request is to send it to paper (via a report), and after that, to send it to a business partner (via some sort of integration).

It might be better to have the employee serialize itself to XML. Once you have that, you can write a XSLT to produce an HTML version of an employee. Or have another piece of code send it to your integration engine.

A good book to pick up is Martin Fowler's "Patterns of Enterprise Application Architecture", where he calls an object like this a Data Transfer Object (DTO). It violates the classic OOP design because it isn't able to populate itself from a data store, but has the advantage of working better in the real world of application integration.

Chip H.


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