“Не может назвать методы на DateTime” и другие ограничения
Ваш hashCode не соответствует вашей equals реализации. Если a.equals(b) истинно, a.hashCode == b.hashCode() также должно быть истиной.
Поскольку equals требует только, чтобы имена были равны, hashCode должен возвращать name.hashCode().
public int hashCode()
{
return name.hashCode();
}
5 ответов
В основном тот список огромен..., это - все за пределами относительно маленького набора вещей, которые обрабатываются. К сожалению, Закон Текучих Абстракций умирает, и у каждого поставщика есть различные ответы...
LINQ к объектам сделает что угодно (в значительной степени), так как это - делегаты; у LINQ-SQL и Платформы Объекта есть различные наборы поддержки.
В целом у меня было изрядное количество успеха с помощью DateTime свойства и т.д. - но в действительности, Вы оказываетесь перед необходимостью удостоверяться, что Ваши выражения запроса покрыты модульными тестами, так, чтобы, если Вы когда-либо изменяете поставщиков (или поставщик обновляется) Вы знали, что все это все еще работает.
Я предполагаю, что одно представление должно думать с точки зрения TSQL; существует нет BOTTOM n, но существует a TOP 1 (ре OrderByDescending); С точки зрения string.IsNullOrEmpty, Вы могли быть довольно литеральными: foo.Bar == null || foo.Bar == ""; и с DateTime.Date можно, вероятно, сделать вполне немного с DATEPART / различные компоненты.
Другая опция с LINQ-SQL состоит в том, чтобы инкапсулировать логику в UDF - таким образом, Вы могли записать UDF, который берет a datetime и возвраты a datetime, и выставьте это через dbml на контекст данных. Можно затем использовать это в запросах:
where ctx.Date(foo.SomeDate) == DateTime.Today
Этот подход, однако, не обязательно хорошо использует индексы.
Обновление:
Для полных окровавленных деталей можно посмотреть на System.Data.Linq.SqlClient.PostBindDotNetConverter+Visitor в отражателе - в особенности Translate... методы; некоторые string функции обрабатываются отдельно. Так не огромный выбор - но это - деталь реализации.
LINQ является языком. LINQ-SQL компилирует Вашу команду LINQ вниз в SQL-запрос. Таким образом это ограничено нормальными ограничениями синтаксиса TSQL или скорее объектами, которые могут легко быть преобразованы в него.
Как другие сказали, списки того, что Вы не можете сделать, было бы огромно. Это - значительно уменьшенный список того, что можно сделать. Общее эмпирическое правило состоит в том, чтобы попытаться определить, как функция, которую Вы хотите использовать, была бы преобразована в TSQL. При наличии больших затруднений при понимании этого то не используйте ту функцию (или по крайней мере тестируйте ее сначала).
Но существует легкая работа вокруг для использования команд LINQ, которые не находятся в LINQ-SQL. Разделите чистые части LINQ своего кода от частей LINQ-SQL. Другими словами, сделайте LINQ-SQL для втягивания данных (с любыми функциями, в которых Вы нуждаетесь, которые доступны в LINQ-to_SQL), с командой для помещения его в объект (ToEnumerable, ToList или подобные другие). Это выполняет запрос и вытягивает локальные данные. Теперь это доступно для полного синтаксиса LINQ.
Я создал проблему Подключения для Строки. IsNullOrEmpty ():
Обратная связь: Я хочу использовать строку. IsNullOrEmpty в LINQ к SQL-операторам.
Не стесняйтесь добавлять свою речь или голосование ей, или создавать другие проблемы Подключения для различных других методов, которые не работают в Linq к SQL.Прав тот, кто громче кричит.
Я имел точно эту проблему с DateTimes и нашел, что в настоящее время следующее обходное решение работает на меня, но я понимаю, что с большими наборами результатов, это могло добраться, чтобы быть проблемой, как обработка находится теперь в моем приложении, а не на базе данных:
BlogPosts post = (from blogs in blogPosts
where blogs.PostPath == path
select blogs)
.ToList()
.Where(blogs => blogs.Published.Date == publishedDate.Date)
.SingleOrDefault();
Отметьте ".ToList ()" в середине - это бросает его к нормальному IEnumerable и позволяет мне использовать обычные свойства, которые я ожидал бы.
Одной вещью, которая все еще смущает меня немного однако, является то, что это законно в EF:
BlogPosts posts = from blogs in blogPosts
where !blogs.IsDraft
&& blogs.Published.Year == year
&& blogs.Published.Month == month
orderby blogs.Published descending
select blogs
Так, я могу назвать ".Year" или ".Month" на DateTime, но не ".Date" - я предполагаю, что он сводится к типам.
Ответ Marc Gravell является всесторонне правильным.
Я просто хотел добавить эту деталь для Логики Даты (и сравнения строк). Так как Вы используете LinqToSql, можно использовать в своих интересах SqlMethods, чтобы сделать те вещи, которые Вы привыкли делать в базе данных.