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

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

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

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

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

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
}

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

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

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

так далее

Есть две потенциальные проблемы с использованием типизированных наборов данных:

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

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

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

Вы можете добавить запрос с предложением where к tableadapter для интересующей вас таблицы.

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

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

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