Hello,
I have what I am assuming is a pretty newb question about C# class architecture.
I have some basic data objects in the business layer of a project-tracking webapp, for example Task, which exposes various properties such as Name, ID, Text, UserID, ...
I have got a static class set up to interact with the SQL Server Tasks table. I want to be able to call a method such as RetrieveTaskFromDB(int taskID), but I don't want to create and populate a Task object from within this DAL class, as it makes the coupling between the layers too tight (no ).
My current solution is to use a Hashtable to mediate between the two (DAL returns a Hashtable, the positions of which are set by an enum - eg. hashTask[TaskProperties.name] = reader["name"].ToString() ).
Not really sure why, but this 'design' doesn't feel quite right!
Can anyone suggest a pattern or something that is more like The Right Way
Many thanks in advance,Carlos

Means of decoupling DAL and business layer?
Leigh_d
There is no problem for the data layer to populate a business logic, you want to have this:
Task cur_task;
cur_task = DataLayer.GetOneTask(10);
What I do is that I have a function called: Task PopulateTaskFromIDataReader(IDataReader reader)
This way if the task class change I only have one function to change. and if the data layer is using an other reader (ex: changing from access to sql server) then this function is still good.
You don't want to go to extreme measure to seperate each layer. The idea behind all this is to have easy to read/modify code.
Satie Cheung
Dr. Ning
And how about in the other direction, ie I have generated a Task object and I want to commit it to the database Is there a standard practice here
Many thanks,
Carlos
jacobmross
Some people will have: InsertTask(int id, string title, ...) // Return unique ID
But I just pass the task object: InsertTask(Task task) // Set unique ID in object