модель программирования с помощью типизированных наборов данных в VS 2008

Question

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

правой кнопкой мыши на «App_Code» добавить новый набор данных, имя его tableDS.

Открыть tableDS, щелкните правой кнопкой мыши, добавьте «настольный адаптер»

В мастере выберите предварительно определенные строки соединения, «заявления использование SQL»

выберите * из имя_таблицы и рядом + рядом с конца. (Сгенерировать одну таблицу адаптер для каждой таблицы в моей БД)

В моем коде я следующее, чтобы получить ряд данных, когда мне нужно только одно:

cpcDS.tbl_cpcRow тр = (cpcDS.tbl_cpcRow) (новый cpcDSTableAdapters.tbl_cpcTableAdapter()). GetData(). Выберите ("cpcID =" + cpcID) [0];

Я считаю, что это приведет к тому, что вся таблица из базы данных и фильтрации в dotnet (т. Е. Не является оптимальной), есть ли способ, которым я могу заставить tableadapter вместо этого установить базу данных в базе данных (IE, что я хочу to is send select * from tbl_cpc, где cpcID = 1 в базе данных)

И, как примечание, я думаю, что это довольно хороший шаблон проектирования для получения данных из базы данных в vs2008. Его довольно легко кодировать, читать и писать. Но я хотел бы знать, что есть другие шаблоны дизайна, которые лучше там? Я использую наборы данных для чтения/обновления/вставки и удаления.

Answer 1

Немного о смене, но вы спрашиваете о разных шаблонах - как насчет LINQ? Поскольку вы используете VS2008, возможно (хотя и не гарантировано), что вы также можете использовать .NET 3.5.

Контекст данных LINQ to SQL обеспечивает гораздо более управляемый доступ к данным (отфильтрован и т. Д.). Это вариант? Я не уверен, что сейчас подойду «Entity Framework» (see here).

Редактировать по запросу:

, чтобы получить строку из данных контекста, вам просто нужно указать «предикат» - в этом случае первичный ключ матч:

int id = ... // the primary key we want to look for 
using(var ctx = new MydataContext()) { 
    SomeType record = ctx.SomeTable.Single(x => x.SomeColumn == id); 
    //... etc 

    // ctx.SubmitChanges(); // to commit any updates 
} 

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

Однако LINQ очень гибкий; Вы можете также использовать «синтаксис запроса» - например, несколько иной (список) запрос:

var myOrders = from row in ctx.Orders 
        where row.CustomerID = id && row.IsActive 
        orderby row.OrderDate 
        select row; 

и т.д.

Answer 2

Существует два потенциальных проблем с использованием типизированных наборов данных,

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

Другой - ремонтопригодность.Использование типизированных наборов данных, как правило, является симптомом более глубокой проблемы, я предполагаю, что все ваши бизнес-правила живут за пределами наборов данных, а некоторые из немногих из них берут данные в качестве входных данных и выводят некоторые агрегированные значения на их основе. Это приводит к тому, что бизнес-логика протекает повсюду, и хотя все это будет честным в первые 6 месяцев, она начнет укусить вас через некоторое время. Такое использование DataSets принципиально не объектно ориентировано

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

Answer 3

Вы можете добавить запрос с ИНЕКЕ к TableAdapter за столом, вы заинтересованы в.

LINQ это хорошо, но это на самом деле просто ярлык синтаксис для того, что OP уже делает.

Типизированные наборы данных имеют смысл, если ваша модель данных не является очень сложной. Тогда написать свой собственный ORM будет лучшим выбором. Я немного смущен тем, что Андреас считает, что типизированные наборы данных трудно поддерживать. Единственное неприятное в них - это то, что команды вставки, обновления и удаления удаляются всякий раз, когда изменяется команда выбора.

Кроме того, преимущество скорости создания типизированного набора данных по сравнению с вашим собственным ORM позволяет сосредоточиться на самом приложении, а не на коде доступа к данным.