Как заполнить универсальный список объектов в C# от базы данных SQL

Я просто изучаю ASP.NET c# и пытаюсь включить лучшие практики в свои приложения. Все, что я считал, говорит для разделения на уровни моих приложений в DAL, BLL, UI, и т.д. на основе разделения проблем. Вместо того, чтобы раздать таблицы данных, я думаю об использовании пользовательских объектов так, чтобы я был слабо связан к моему слою данных и мог использовать в своих интересах intellisense в VS. Я предполагаю, что эти объекты считали бы DTOs?

Во-первых, где эти объекты находятся в моих слоях? BLL, DAL, другой?

Во-вторых, при заполнении от SQL, действительно ли я должен циклично выполниться через средство чтения данных, чтобы заполнить список или сначала заполнить таблицу данных, затем цикл через таблицу для заполнения списка? Я знаю, что необходимо закрыть соединение с базой данных как можно скорее, но на еще больше служебное походит заполнять таблицу данных и затем цикл через это для списка.

В-третьих, все, что я вижу в эти дни, говорит использование Linq2SQL. Я планирую изучить Linq2SQL, но в это время я работаю с унаследованной базой данных, которая не имеет установки внешних ключей, и у меня нет способности зафиксировать его банкомат. Кроме того, я хочу узнать больше о c#, прежде чем я начну входить в решения ORM как nHibernate. В то же время я не хочу выводить все соединение и инфраструктуру SQL для каждого запроса. Это в порядке для использования Предприятия DAAB на данный момент?

6
задан jpshook 16 March 2010 в 18:29
поделиться

2 ответа

У вас много вопросов в одном вопросе.

Linq2SQL - это просто разновидность ORM, если вы идете по этому пути, я бы посмотрел на структуру сущностей (orm от Microsoft).

Давайте немного поговорим о многоуровневых приложениях, чтобы помочь вам понять, как заполнять объекты. Типичное приложение для базы данных состоит из трех слоев (некоторые говорят, что четыре уровня, а сама база данных - это слой, но на самом деле это не так. неважно). У вас есть следующее:

  • UI
  • BLL
  • DAL

Итак, ваше общение - это пользовательский интерфейс, взаимодействующий с BLL, а BLL - с DAL. DAL возвращает некоторые данные в BLL, который, в свою очередь, возвращает их пользовательскому интерфейсу. Я не знаю, кто сказал вам, что наборы данных / таблицы плохие ... конечно, читатель работает быстрее, но это не значит, что использование datatable плохо.

Приведу пример. Перестаньте думать о своем DAL как об одном простом классе. Начните думать о слое DAL как о целой папке различных классов. Один из этих классов - статический класс БД. Он статичен, потому что вы имеете дело с одной базой данных (в большинстве случаев), поэтому создавать экземпляр класса не нужно. Это может выглядеть так:

public static class DB {
private static readonly string connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString;
private static readonly DbProviderFactory factory = DbProviderFactories.GetFactory(dataProvider);

public static int Update(string sql)
        {
            using (DbConnection connection = factory.CreateConnection())
            {
                connection.ConnectionString = connectionString;

                using (DbCommand command = factory.CreateCommand())
                {
                    command.Connection = connection;
                    command.CommandText = sql;

                    connection.Open();
                    return command.ExecuteNonQuery();
                }
            }
        }

public static DataTable GetDataTable(string sql)
        {
            using (DbConnection connection = factory.CreateConnection())
            {
                connection.ConnectionString = connectionString;

                using (DbCommand command = factory.CreateCommand())
                {
                    command.Connection = connection;
                    command.CommandType = CommandType.Text;
                    command.CommandText = sql;

                    using (DbDataAdapter adapter = factory.CreateDataAdapter())
                    {
                        adapter.SelectCommand = command;

                        DataTable dt = new DataTable();
                        adapter.Fill(dt);

                        return dt;
                    }
                }
            }
}

Кое-что из этого было взято с веб-сайта компании. Отличный ресурс, чтобы узнать, как использовать шаблоны проектирования. В любом случае это всего лишь один файл .class. Теперь вам нужен еще один, скажем, CustomerDAO (объект доступа к данным клиента).

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

public IList<Customer> GetCustomers()
{
    StringBuilder sql = new StringBuilder();
    sql.Append(" SELECT CustomerId, CompanyName, City, Country ");
    sql.Append("   FROM Customer ");

    DataTable dt = Db.GetDataTable(sql.ToString());

    return MakeCustomers(dt);
}

Помните, что это находится в совершенно другом файле .class.Хорошо, так как же выглядят клиенты:

private IList<Customer> MakeCustomers(DataTable dt)
        {
            IList<Customer> list = new List<Customer>();
            foreach (DataRow row in dt.Rows)
                list.Add(MakeCustomer(row));

            return list;
        }

Итак, я делаю вот что: у меня есть таблица данных, полная клиентов. Мне нужно перебрать каждую строку таблицы данных и сделать клиента:

private Customer MakeCustomer(DataRow row)
        {
            int customerId = int.Parse(row["CustomerId"].ToString());
            string company = row["CompanyName"].ToString();
            string city = row["City"].ToString();
            string country = row["Country"].ToString();

            return new Customer(customerId, company, city, country);
        }

Итак, этот клиент является новым и хранится в списке клиентов.

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

Так где же сам класс Customer? Он может находиться в другой папке на бизнес-уровне, потому что это просто бизнес-объект. Здесь вы можете установить проверки и обязательные поля внутри класса клиента.

Ваш пользовательский интерфейс не имеет ничего общего с носителями данных, наборами данных или SQL. Ваш бизнес-уровень тоже не имеет к нему никакого отношения (он определяет некоторые правила, лежащие в основе ваших бизнес-объектов). Ваш dal может быть очень гибким (может работать с SQL, Oracle и т. Д.) Или ограничиваться SQL Server, если это то, что вы планируете делать. Не перегружайте свое приложение. Если вы парень MS и уверены, что используете только SQL Server, не усложняйте свою работу, пытаясь развернуть окончательный DAL, который работает с любым поставщиком. можно использовать SQLCommand, SQLConnection и т. д.

17
ответ дан 8 December 2019 в 13:45
поделиться

Ознакомьтесь с OpenAccess ORM от Telerik. Вам не обязательно использовать его в качестве "ORM", но он даст вам возможность быстро генерировать классы для ваших таблиц без необходимости набирать все это. Затем вы можете использовать эти strong-typed классы в вашем DAL для всего, что вы хотите, будь то написанное на заказ или основанное на ORM с чем-то еще. В данном случае вы просто используете его для генерации кода, чтобы быстро начать работу (а эти объекты очень базовые и простые - т.е. именно с того, с чего бы вы начали, если бы писали их вручную).

Что касается абстрагирования ваших объектов DAL от других объектов, ознакомьтесь с WCF. Вы можете поместить его между каждым слоем (UI/Biz/DAL), и он будет генерировать прокси-объекты, которые позаботятся о разделении проблем.

0
ответ дан 8 December 2019 в 13:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: