Как я должен передать данные между классами и прикладными уровнями?

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

Краткий ответ на ваш вопрос: Да вы захотите использовать экземпляры класса (объекты) в качестве посредника между вашим пользовательским интерфейсом и уровнем бизнес-логики. BLL и DAL будут обмениваться данными, как описано ниже. Вы не должны передавать SqlDataTables или SqlDataReaders.

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

Общая картина состоит в том, что для любой страницы вашего пользовательского интерфейса у вас будет одна или несколько «моделей», которые вы хотите отображать и с которыми вы хотите взаимодействовать. Объекты - это способ зафиксировать текущее состояние модели. С точки зрения процесса: пользовательский интерфейс запросит модель (которая может быть отдельным объектом или списком объектов) с уровня бизнес-логики (BLL). Затем BLL создает и возвращает эту модель - обычно с использованием инструментов уровня доступа к данным (DAL). Если в модель внесены изменения в пользовательском интерфейсе, пользовательский интерфейс отправит исправленные объекты обратно в BLL с инструкциями относительно того, что с ними делать (например, вставить, обновить, удалить).

.NET отлично подходит для такого рода разделения проблем, потому что общие классы-контейнеры - и в частности класс List <> - идеально подходят для такого рода работы. Они не только позволяют передавать данные, но и легко интегрируются со сложными элементами управления пользовательского интерфейса, такими как сетки, списки и т. Д., Через класс ObjectDataSource. С помощью ObjectDataSource вы можете реализовать весь спектр операций, необходимых для разработки пользовательского интерфейса: операции «заполнения» параметрами, операции CRUD, сортировка и т. Д.).

Поскольку это довольно важно, позвольте мне сделать небольшое отступление, чтобы продемонстрировать, как определить ObjectDataSource:

<asp:ObjectDataSource ID="ObjectDataSource1" runat="server" 
    OldValuesParameterFormatString="original_{0}" 
    SelectMethod="GetArticles" 
    OnObjectCreating="OnObjectCreating"
    TypeName="MotivationBusinessModel.ContentPagesLogic">
    <SelectParameters>
        <asp:SessionParameter DefaultValue="News" Name="category" 
            SessionField="CurPageCategory" Type="String" />
    </SelectParameters>
</asp:ObjectDataSource>

Здесь MotivationBusinessModel - это пространство имен для BLL, а ContentPagesLogic - класс, реализующий логику, ну, Content Pages. Метод извлечения данных - « GetArticles », и он принимает параметр с именем CurPageCategory . В этом конкретном случае ObjectDataSource возвращает список объектов, который затем используется сеткой. Обратите внимание, что мне нужно передать информацию о состоянии сеанса в класс BLL, поэтому в коде позади у меня есть метод « OnObjectCreating », который позволяет мне создать объект и передать параметры:

public void OnObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
    e.ObjectInstance = new ContentPagesLogic(sessionObj);
}

Итак, это как это работает. Но возникает один очень большой вопрос - откуда берутся модели / бизнес-объекты? ORM, такие как Linq to SQL и Subsonic, предлагают генераторы кода, которые позволяют создавать классы для каждой из таблиц базы данных. То есть эти инструменты говорят, что классы модели должны быть определены в вашем DAL и отображать непосредственно в таблицах базы данных. Linq to Entities позволяет вам определять ваши объекты способом, совершенно отличным от макета вашей базы данных, но, соответственно, более сложным (вот почему существует различие между Linq to SQL и Linq to Entities). По сути, это решение BLL. Джоэл и я говорили в разных местах в этой ветке, что на самом деле бизнес-уровень обычно находится там, где модели должны быть определены (хотя в действительности я использую смесь объектов BLL и DAL).

Как только вы решите это сделать, как вы реализуете отображение моделей в базу данных? Ну, вы пишете классы в BLL, чтобы извлекать данные (используя свой DAL) и заполнять объект или список объектов. Это Business Logic , потому что отображение часто сопровождается дополнительной логикой для конкретизации модели (например, определение значения производных полей).

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

Я использовал другой подход. В моем BLL я определяю классы Logic и классы Model . Обычно они определяются в совпадающих парах, где оба класса определены в одном файле и чьи имена отличаются своим суффиксом (например, ClassModel и ClassLogic). Классы логики знают, как работать с классами модели - делать такие вещи, как Fill, Save («Upsert»), Delete и генерировать обратную связь для экземпляра модели.

В частности, для выполнения Fill я использую методы, найденные в моем основном классе DAL (показанном ниже), которые позволяют мне взять любой класс и любой запрос SQL и найти способ создания / заполнения экземпляров класса с использованием возвращенных данных. по запросу (либо в виде отдельного экземпляра, либо в виде списка). То есть класс Logic просто получает определение класса Model, определяет SQL-запрос и отправляет его в DAL. Результатом является один объект или список объектов, которые я затем могу передать пользовательскому интерфейсу. Обратите внимание, что запрос может возвращать поля из одной таблицы или нескольких таблиц, объединенных вместе. На уровне отображения меня действительно не волнует - я просто хочу, чтобы некоторые объекты были заполнены.

Вот первая функция. Он возьмет произвольный класс и автоматически отобразит его на все совпадающие поля, извлеченные из запроса. Сопоставление выполняется путем поиска полей, имя которых соответствует свойству в классе. Если есть дополнительные поля класса (например,те, которые вы заполняете с помощью бизнес-логики) или дополнительные поля запроса, они игнорируются.

    public List<T> ReturnList<T>() where T : new()
    {
        try
        {
            List<T> fdList = new List<T>();
            myCommand.CommandText = QueryString;
            SqlDataReader nwReader = myCommand.ExecuteReader();
            Type objectType = typeof (T);
            PropertyInfo[] typeFields = objectType.GetProperties();
            if (nwReader != null)
            {
                while (nwReader.Read())
                {
                    T obj = new T();
                    for (int i = 0; i < nwReader.FieldCount; i++)
                    {
                        foreach (PropertyInfo info in typeFields)
                        {
                            // Because the class may have fields that are *not* being filled, I don't use nwReader[info.Name] in this function.
                            if (info.Name == nwReader.GetName(i))
                            {
                                if (!nwReader[i].Equals(DBNull.Value)) 
                                    info.SetValue(obj, nwReader[i], null);
                                break;
                            }
                        }
                    }
                    fdList.Add(obj);
                }
                nwReader.Close();
            }
            return fdList;
        }
        catch
        {
            conn.Close();
            throw;
        }
    }

Это используется в контексте моего DAL, но единственное, что вы должны иметь в классе DAL, - это держатель для QueryString, объект SqlCommand с открытым соединением и любыми параметрами. Главное - убедиться, что ExecuteReader будет работать при его вызове. Типичное использование этой функции моим BLL выглядит следующим образом:

return qry.Command("Select AttendDate, Count(*) as ClassAttendCount From ClassAttend")
          .Where("ClassID", classID)
          .ReturnList<AttendListDateModel>();

Вы также можете реализовать поддержку анонимных классов следующим образом:

    public List<T> ReturnList<T>(T sample)
    {
        try
        {
            List<T> fdList = new List<T>();
            myCommand.CommandText = QueryString;
            SqlDataReader nwReader = myCommand.ExecuteReader();
            var properties = TypeDescriptor.GetProperties(sample);
            if (nwReader != null)
            {
                while (nwReader.Read())
                {
                    int objIdx = 0;
                    object[] objArray = new object[properties.Count];
                    for (int i = 0; i < nwReader.FieldCount; i++)
                    {
                        foreach (PropertyDescriptor info in properties) // FieldInfo info in typeFields)
                        {
                            if (info.Name == nwReader.GetName(i))
                            {
                                objArray[objIdx++] = nwReader[info.Name];
                                break;
                            }
                        }
                    }
                    fdList.Add((T)Activator.CreateInstance(sample.GetType(), objArray));
                }
                nwReader.Close();
            }
            return fdList;
        }
        catch
        {
            conn.Close();
            throw;
        }
    }

Вызов этой функции выглядит так:

var qList = qry.Command("Select QueryDesc, UID, StaffID From Query")
               .Where("SiteID", sessionObj.siteID)
               .ReturnList(new { QueryDesc = "", UID = 0, StaffID=0 });

Теперь qList - это общий список динамически создаваемых экземпляры класса, определяемые на лету.

Допустим, у вас есть функция в вашем BLL, которая принимает в качестве аргумента раскрывающийся список и запрос на заполнение списка данными. Вот как вы можете заполнить раскрывающийся список результатами, полученными выше:

foreach (var queryObj in qList)
{
    pullDownList.Add(new ListItem(queryObj.QueryDesc, queryObj.UID.ToString()));
}

Короче говоря, мы можем определять анонимные классы бизнес-модели на лету, а затем заполнять их, просто передав некоторый (на лету) SQL в DAL. Таким образом, BLL очень легко обновлять в ответ на меняющиеся потребности в пользовательском интерфейсе.

И последнее замечание: если вас беспокоит, что определение и передача объектов приводит к бесполезной трате памяти, этого не должно быть: если вы используете SqlDataReader для извлечения данных и помещения их в объекты, составляющие ваш список, вы иметь только одну копию в памяти (список), поскольку средство чтения выполняет итерацию в режиме только для чтения и только для пересылки. Конечно, если вы используете классы DataAdapter и Table (и т. Д.) На уровне доступа к данным, вы будете нести ненужные накладные расходы (вот почему вам не следует этого делать).