Что возвратиться от DAL до BLL

Вы могли создать фиктивные Книжные объекты, которые содержат только данные. Получите, установите членские значения и свойства. Эта книга, имеет 1 свойство для каждого поля в базе данных, но ничего не проверяет.

Вы заполняете объект от дб, затем отправляете его в BLL.

Когда Вы хотите сохранить объект, Вы также отправляете его в BLL.

Ваши классы в BLL могли перенести aroud те объекты, если это имеет смысл. Таким образом, легко просто передать его обратно DAL.

Фиктивная книга:

public class DummyBook:IBook 
{
    private nullable<int> _id;
    private string _name;
    private string _genre;

    public string Id
    {
        get {return _id;}
        set {_id = value;}
    }

    public string Name 
    {
        get {return _name;}
        set {_name = value;}
    }

    public string Genre 
    {
        get {return _genre;}
        set {_genre= value;}
    }

}

Книга DAL:

public class DALBook 
{
    public static IBook:GetBook(int id) 
    {
        DataTable dt;
        DummyBook db = new DummyBook();

        // Code to get datatable from database
        // ...
        // 

        db.Id = (int)dt.Rows[0]["id"];
        db.Name = (string)dt.Rows[0]["name"];
        db.Genre = (string)dt.Rows[0]["genre"];

        return db;
    }

    public static void SaveBook(IBook book) 
    {
        // Code to save the book in the database
        // you can use the properties from the dummy book
        // to send parameters to your stored proc.
    }
}

Книга BLL:

public class Book : IBook
{
     private DummyBook _book;

     public Book(int id) 
     {
         _book = DALBook.GetBook(id);
     }

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

     // Code for other Properties ...



     public void Save()
     {
         // Add validation if required
         DALBook.Save(_book);
     }

}

Edit1: фиктивные классы должны войти в свой собственный проект (Модель, столь же указанный в комментариях прекрасен). Ссылки работали бы следующим образом:

DAL ссылается на образцовый проект.
Ссылки BLL модель и DAL.
UI ссылается на BLL.

BookDB должен возвратить экземпляр IBook. Мне нравится шаблон репозитория, который является всем об отображении от дб до домена.

Реализация репозитория возвращает экземпляры объектов области. Это экранирует остальную часть кода от конкретной реализации персистентности, которая может быть затронута технологией (тип БД, веб-сервис, [вставляют что-то еще]), и формат раньше сохранял данные.

Я, вероятно, использовал бы ExecuteReader для создания объекта в коде от базы данных. Причина этого состоит в том, что таблица данных имеет больше служебное, чем читатель, потому что она имеет больше функциональности (и был, вероятно, создан читателем). Так как Вы не делаете, обновляет/удаляет использование таблицы данных, Вам не нужны издержки.

Однако я сделал бы статический вспомогательный метод в классе BookManager.

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

Причина этого состоит в том, потому что причина, у Вас есть интерфейс, состоит в том, потому что Вы могли бы хотеть изменить реализацию. Вы можете eventuallu иметь INovel: IBook, IReference: IBook и т.д. и затем Вы захотите иметь абстрактную реализацию фабрики в своем слое данных.

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
        }
    }
}

Другое преимущество DAL здесь - то, что можно кэшировать поиски. У Вас может быть Словарь, который содержит книги, которые Вы искали, уменьшать дополнительный дб обращается к объектам, которые Вы уже возвратили. Когда обновление происходит, Вы удаляете кэшируемый объект... Это - другое сообщение все же.

При использовании нескольких блоков интерфейсы и вспомогательные методы должны будут находиться в нейтральном (независимом) блоке. Прямо сейчас в блогосфере, существует перемещение к меньшему количеству блоков, что означает меньше зависимостей, и т.д.

Вот ссылка из блога, который я прочитал по этой теме: http://codebetter.com/blogs/patricksmacchia/archive/2008/12/08/advices-on-partitioning-code-through-net-assemblies.aspx

В конечном счете я думаю, что ответ - то, что слой данных возвращает экземпляр Вашего интерфейса к бизнес-слою.

Удача :-)

DataTable, который Вы хотите возвратить, является базой данных, связанной, и для BLL, он не должен заботиться, о какой базе данных Вы используете и какова схема. Можно использовать Объектный DB Картопостроитель для отображения dbtable на объект в DAL.

Если Вы не хотите возвращать DataTable, можно передать в реализации IBook из BookManager для DAL для заполнения.

На мой взгляд, вы никогда не должны позволять DAL обращаться к BLL. Это излишняя зависимость.

Помещение класса Book в новый проект (возможно, с именем DomainModel) исправит циклическую ссылку. Вы можете сделать что-то вроде этого:

Ссылка на DAL проекта BLL и DomainModel

Ссылка на DAL проекта DomainModel

Ссылка на пользовательский интерфейс проекта BLL и DomainModel

Project DomainModel ничего не ссылается

Чтобы следовать намеченной модели, уровень доступа к данным (DAL) отвечает за получение и отправку данных из источника данных.

DAL не должен заботиться ни о каких бизнес-сущностях, которые использует ваш BLL, поскольку его единственная задача - получать данные и возвращать их в виде нейтрального объекта. Он должен быть нейтральным для общей пригодности, в противном случае вы можете не разделять слои, поскольку вы не выполняете его предназначение.

Ваш уровень бизнес-логики (BLL) не должен заботиться о том, как DAL достигает получения или записи данных.

Для связи между BLL и DAL вы должны использовать нейтральные объекты.

Ваш BLL передает свойства объекта как отдельные параметры методам в DAL. Параметры в DAL являются нейтральными, используя строки, int, bool, любые другие объекты .NET, которые не являются ни специфичными для версии базы данных, с которой вы общаетесь, ни специфичными типами, существующими только в вашем BLL.

DAL будет получать данные из любого места любым способом и возвращать нейтральный объект данных вызывающей стороне. Например, это может быть DataSet или DataTable или любой другой объект, НЕ специфичный для используемого типа/версии базы данных. Следовательно, DataSet и DataTable - это объекты в пространстве имен System.Data, а не System.Data.SQL и т.д....

По сути: - BLL передает DAL нейтральные типы (например: string, int, bool, long, float и т.д.). - DAL отвечает за преобразование этих типов в типы, специфичные для базы данных, если это необходимо, перед передачей их источнику данных. DAL возвращает BLL нейтральные типы данных (например: DataSet, DataTable и т.д.). - BLL отвечает за использование содержимого этих нейтральных типов данных для создания, наполнения и возврата конкретных бизнес-сущностей

Ваш BLL должен ссылаться на ваш DAL. Вот и все.

Вы, конечно, можете полностью игнорировать эту модель и хакать, как многие предлагали ранее, используя IBOOK, и т.д... но тогда вы не будете использовать предназначенную модель, и с таким же успехом можете бросить все это в одну сборку, поскольку вы все равно не сможете поддерживать ее независимо.