Data Access Layer Encapsulation

[DannyT]

Can any patterns gurus rip appart my attempt at encapsulating my data access layer.

 

It's based on an abstract DataEntity superclass that abstracts its own Create, Retrieve, Update and Delete methods, all classes that utilise data from a db implement the DataEntity class. The DataEntity uses a DataManager which is a singleton responsible for making database calls. The Create method is overloaded to allow for 3 different implementations:

 

1 - no params Create() - creates a blank version to be added to the db

2 - an int param Create(int id) - calls for the row of information specific to the ID provided

3 - a DataRow param Create(DataRow dr) - no call to database creates self with datarow provided. * 3rd method allows for creation of a number of classes with 1 database call returning a datatable, rather than a call to return a list of IDs then repeat calls to get that IDs related information.

 

Implmenetation as follows: -

public abstract class DataEntity
{	
	private DataManager dm = DataManager.getInstance();

	public abstract void Create(); // creates a new object (i.e. not already in Database)

	public void Create(int id) // calls getRow which gets data needed from db to setup fields
	{
		SetupFields(getRow(id));
	}
	
	public void Create(DataRow row) // have all the data i need so i just SetupFields
	{
		SetupFields(row);
	}
	
	public abstract DataRow getRow(int id); // call to DataManager to get the required row
	
	protected abstract void SetupFields(DataRow row); // as per Experts Exchange example

	public abstract void Update();
	public abstract void Delete();
}

An example of implementation: -

public class Member : DataEntity
{
	private int memberId;
	private string name;
	private string gender;
	private int age;
	private string image;
	private string location;
	private bool online;

	# region Public Properties
	public int MemberId
	{
		get{return memberId;}
	}
	public string Name
	{
		get{return name;}
		set{name = value;}
	}
	public string Gender
	{
		get{return gender;}
		set{gender = value;}
	}
	public int Age
	{
		get{return age;}
		set{age = value;}
	}
	public string Image
	{
		get{return image;}
		set{image = value;}
	}
	public string Location
	{
		get{return location;}
		set{location = value;}
	}
	
	#endregion

	public override void Create()
	{
		memberId = -1; // identifies when updated that this is to be INSERTed into db
		name = "";
		gender = "";
		age = 0;
		image = "";
		location = "";
		online = false;
	}

	public override DataRow getRow(int id)
	{
		return DataManager.getMemberDetails(id); // our singleton datamanager has a call to return a row of member details
	}
	
	protected override void SetupFields(DataRow dr)
	{
		memberId = (int)dr["memberId"];
		name = (string)dr["name"];
		gender = (string)dr["gender"];
		age = (int)dr["age"];
		image = (string)dr["image"];
		location = (string)dr["location"];
		online = (bool)dr["onlineStatus"];
	}

	public override void Update()
	{
		DataManager.updateMember(this);
	}

	public override void Delete()
	{
		DataManager.deleteMember(this);
	}
}

so i can create a new member by: -
Member myMember = new Member();
myMember.create();

//an existing member like so: -
myMember.create(someId);

//create an arrayList of members like so: -
foreach(DataRow dr in dtMembers)
{
myMember = new Member();
myMember.Create(dr);
membersArray.Add(myMember);
}

Can someone please tell me if i'm on the right lines with this or not?

 

Also if this is practicable i would like to address the following: -

 

 

• Some form of factory for the instantiation and creation (in the Create() sense of the word) of 'Member' so no need to instantiate then create.
  
• seems like the implementation of the DataManager could be better, at the moment I just have a large singleton class that does all the calls to the db and returns rows or tables as needed.
  
• Is there some form of common data object i can pass around instead of my classes knowing that the data will be a row or a table, is there some common practice for creating a common data object?
  

 

Much appreciation to anyone that reads all of this, and even more so for any feedback.

 

Cheers,

 

Dan

[bri189a]

It looks like what you've done is re-invented the wheel for a strongly typed dataset.

 

I would call your example a business object, not a data access layer.