C# - У чего приоритет больше - у операторов или паттернов?
И затрат с ними много - пишешь днями то, что на EF делается за час.
-----
Снова - квалификация.
В большинстве случаев будет объемнее, но быстрее по реализации именно на dataSet'ах.
Алекс, а ты вообще уже работал в каком-нить проекте на EF?
Прям в коммерческом, а не хелловорлд в НИИ.
Далее будет вопрос - а если работал, то какую роль выполнял? А то ведь можно просочиться в какой-нибудь ФААНГ, и там годами быдлокодить. Это апелляции к личности, а не к теме разговора.
А по теме, вы с дата сетами дублируете данные. Вы сначала загружаете в них всё, а потом их опрашиваете, создавая объекты с теми же данными, что и в датасетах. И чтобы иметь возможность опрашивать не только частично, но и полные (по столбцам) таблицы, вы всегда держите в датасетах полные таблицы. Тогда как в EF вы получаете эти объекты сразу и только те столбцы, что запросили. Я вообще не понимаю, как с датасетами работали в начале 2000-х, когда памяти на машинах было куда меньше. Оно же жрало как не в себя и ворочалось как черепаха, особенно на том древнем железе.
Опросить таблицу в дата сете - это неочевидная грёбаная простыня из вложенных циклов, т.к. данные в тиблице хранятся в виде двухмерного массива, но без удобного доступа по двум индексам одновременно. Или пара отдельных запросов LINQ to objects.
Из-за своей древности дата сеты не поддерживают нормально налловые значения. При обращении к свойству вы не знаете, может ли оно быть налл. Надо проверить кучку методов Is<PropertyName>Null - нет ли в них названия свойства, к которому вы хотите обратиться. Поняли, да? Каждый раз, чтобы прочитать свойство, надо открыть класс с ним и внимательно его изучить. А теперь представьте себе таблицы с десятками столбцов - удачи в блуждании по сгенеренным дата сетами классам для этих таблиц.
Снова - квалификация.
В большинстве случаев будет объемнее, но быстрее по реализации именно на dataSet'ах.
Какая, в задницу, квалификация позволит вам выкопать котлован лопатой быстрее, чем экскаватором? Будь вы хоть суперпрофессиональным землекопом семизначного уровня, но даже начинающий студент-экскаваторщик выполнит работу в разы быстрее. ))
чот ты какую-то херню несёшь
Что из базы данных выбрал, то и сохраняется в датасете
string queryString =
"SELECT CustomerID, CompanyName FROM dbo.Customers";
SqlDataAdapter adapter = new SqlDataAdapter(queryString, connection);
DataSet customers = new DataSet();
adapter.Fill(customers, "Customers");
Опросить таблицу в дата сете - это неочевидная грёбаная простыня из вложенных циклов, т.к. данные в тиблице хранятся в виде двухмерного массива, но без удобного доступа по двум индексам одновременно.
до жего же ты ебанутый
Покажи мне как ты к коллекции из EF обратишься по двум индексам, чтобы взять второе свойство третьей строки?
в наших старых проектах мы на null проверяли вот так. Что тебе мешает?
foreach(DataRow row in table.Rows)
{
object value = row["ColumnName"];
if (value == DBNull.Value)
// do something
else
// do something else
}Какая, в задницу, квалификация
------
Именно в упомянутом месте и лежит твоя квалификация.
выкопать котлован лопатой быстрее
------
Вот Я так и понимаю - незачем хвататься за лопату при наличии многократно проверенного в работе экскаватора.
И, кстати, от DataSet'а ты используешь от силы 2-3% доступной функциональности. Когда изучишь хотя бы до 50-60% - будет об чем поговорить. И это... LINQ на том же уровне нужен...
т.к. данные в тиблице хранятся в виде двухмерного массива
------
интерфейсная частьтам в виде RB-дерева... а представление в виде двухмерного массива это винда и стоит это почти половину наличной памяти.
Мат.часть учи...
представьте себе таблицы с десятками столбцов
-----
представил - строготипизированные таблицы.
и никаких проблем.
Единственное - мат.часть учить надо-ть...
object value = row["ColumnName"]; if (value == DBNull.Value)
А чего так сложно?
У меня вроде как всегда было
row.ColumnName.IsNull
А как и с чем оно сравнивается - закопано в типизированной таблице.
через функцию Field<> вообще сразу получаешь nullable тип
using (DataTable dtSources = SQLHelper.Fetch(sQuery))
{
foreach (DataRow drSource in dtSources.Rows)
{
int? iID = drSource.Field<int?>("ID");
}
}ну и повторю вопрос: есть ли у тебя боевой опыт с EF или только пару хелловорлдов написал?
Он не знает где и сколько ему придется мудохаться с EF...
Я изначально тоже радовался... Оказалось - зря - дохрена чего просто невозможно сделать через EF. Но, да. на первом этапе все неплохо компактикуется... а потом начинаются проблемы, решать которые сложнее, чем в датасетах...
взять второе свойство третьей строки?
------
А мне, плс, поменять его значение и после 10 секунд простоя записать в обратно в базу в одном баче с остальными изменениями...
Покажи мне как ты к коллекции из EF обратишься по двум индексам, чтобы взять второе свойство третьей строки?
А в EF и не надо по индексам:
Skip(2).Take(1).<второе свойство>
Теперь так же коротко в датасетах сделайте. Хоть с индексами, хоть без. Только у меня в EF эта строчка сразу и запрос выполняет, и я считываю нужное свойство. А в датасетах надо сначала выполнить запрос, а потом считать датасет.
в наших старых проектах мы на null проверяли вот так. Что тебе мешает?
foreach(DataRow row in table.Rows) { object value = row["ColumnName"]; if (value == DBNull.Value) // do something else // do something else }
Наверное, 4-5 строк кода на каждое свойство, вместо одной?
В принципе, ничего не мешает копать котлован лопатой вместо экскаватора.
Он не знает где и сколько ему придется мудохаться с EF...
Я изначально тоже радовался... Оказалось - зря - дохрена чего просто невозможно сделать через EF. Но, да. на первом этапе все неплохо компактикуется... а потом начинаются проблемы, решать которые сложнее, чем в датасетах...
Проблемы в чём? В скорости и неоптимальных запросах? В узких местах пишете свой оптимальный запрос "вручную". Нет универсального инструмента, подходящего всегда. Но есть подходящие в подавляющем большинстве случаев.
Вы как те придурки, кто жалуется на производительность C# после работы с низкоуровневыми оптимизациями - вот мол вас Сишарп тормозной. Ну так в узких местах вставляй свои оптимизации, а в остальных - пользуйся удобным Шарпом.
взять второе свойство третьей строки?------
А мне, плс, поменять его значение и после 10 секунд простоя записать в обратно в базу в одном баче с остальными изменениями...
И ещё добавить, что все 100% ваших запросов только из таких условий и состоят. Тогда да - EF можно закапывать (для вас лично).
Наверное, 4-5 строк кода на каждое свойство, вместо одной?
где там у тебя на EF одна строчка, болезный?