What to return from the DAL to BLL

Question

I currently have an application which consists of: User Interface (web page) BLL (Manager & Domain Objects) DAL (DataAccess class for each of my Domain Objects).

I use the following in the UI to search for a domain object.

protect sub Button1_Click()
{
    IBook book = BookManager.GetBook(txtID.Text);
}

Here is my BLL

public class BookManager 
{
    public static IBook GetBook(string bookId)
    {
        return BookDB.GetBook(bookId);
    }
}

public class Book : IBook
{
    private int? _id
    private string _name;
    private string _genre;

    public string Name
    {
        get { return _name; }
        private set 
        {
            if (string.IsNullOrEmpty(value))
                throw new Exception("Invalid Name");
            _name = value;
        }
    }

    public string Genre
    {
        get { return _serial; }
        private set 
        {
            if (string.IsNullOrEmpty(value))
                throw new Exception("Invalid Genre");
            _genre = value;
        }
    }

    // Other IBook Implementations

}

And finally here is my DAL

public class BookDB
{
    public static IBook GetBook(int id)
    {
        // Get Book from database using sproc (not allowed to use any ORM)
        // ?? Create IBook Item?
        // return IBook
    }

How would one create a IBook Object and return it to the Manager? I'm thinking of returning a DataTable from BookDB to BookManager and having it create the Book Object and return it, but that doesn't seem right. Is there another way to do this?

Edit: I decided to seperate each layer into a project and ran into a circular dependency problem in the DAL layer when trying to add a reference to the BLL. I can't access the Book Class or Interface or anything in BLL from DAL. Should i just use ado.net objects here and have my manager create the actual object from the ado.net object? Here's how its layed out

BLL.Managers - BookManager
BLL.Interfaces IBook
BLL.Domain - Book
DAL - BookDB.

Thanks!

Answer 1

I would probably use ExecuteReader to create an object in code from the database. The reason for this is that the datatable has more overhead than a reader, because it has more functionality (and was probably created by a reader). Since you aren't doing updates/deletes using the datatable, you don't need the overhead.

That being said, I would make a static helper method in the BookManager class.

internal static IBook BookFromReader(IDataReader reader)
{
     Book B = new Book();
     B.Prop = reader.GetString(0);
     B.Rinse = reader.Repeat();
     return B;
}

The reason for this is because the reason you have an interface is because you might want to change the implementation. You may eventuallu have INovel : IBook, IReference : IBook etc and then you'll want to have an abstract factory implementation in your data layer.

public static IBook GetBook(int id)
{
    // SqlCommand Command = new Command("SQL or sproc", ValidConnection);

    using(IDataReader DR = Command.ExecuteReader(id))
    {
        // checking omitted
        switch(DR.GetInt32(1))
        {
            case 0:
                 return BookManager.BookFromReader(DR);
            case 1:
                 return BookManager.NovelFromReader(DR);
            etc
        }
    }
}

Another benefit of the DAL here is that you can cache lookups. You can have a Dictionary that holds books you've looked up, to reduce extra db calls on objects you've already returned. When an update takes place, you remove the cached entity... That's another post though.

If you're using multiple assemblies, interfaces and helper methods will need to reside in a neutral (non-dependent) assembly. Right now in the blog-o-sphere, there is movement towards less assemblies, which means less dependencies, etc.

Here is a link from a blog I read on this topic: http://codebetter.com/blogs/patricksmacchia/archive/2008/12/08/advices-on-partitioning-code-through-net-assemblies.aspx

Ultimately, I think the answer is that the data layer returns an instance of your interface to the business layer.

Good luck :-)