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

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

1 голос
/ 17 ноября 2008

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

Щелкните правой кнопкой мыши "app_code", добавьте новый набор данных, назовите его tableDS.

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

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

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

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

cpcDS.tbl_cpcRow tr = (cpcDS.tbl_cpcRow) (новый cpcDSTableAdapters.tbl_cpcTableAdapter ()). GetData (). Select ("cpcID =" + cpcID) [0];

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

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

Ответы [ 3 ]

1 голос
/ 17 ноября 2008

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

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

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

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

1 голос
/ 17 ноября 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;

и т. Д.

0 голосов
/ 09 января 2009

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

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

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

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

...