Добрый день.
Если вы собираетесь использовать LINQ в проектах, стоит узнать, как ускорить работу этой технологии.

Начиная с версии 2008 (и пока что заканчивая ей) MS SQL Server имеет встроенную поддержку пространственных данных. Прекрасно!

На данный момент времени уже существует несколько СУБД, предлагающих индексированное хранение пространственных данных. Наверное, самые популярные из них, это: «народная» MySql и PostGIS.

Программируя на c#, естественно, в очень многих случаях, отдаёшь предпочтение продуктам и решениям Microsoft. Причины просты: полнее поддержка одних технологий другими, хорошая документация, более полная реализация, например провайдеров данных, и гораздо меньшая глючность. Я выбрал SQL Server. Заодно захотелось освоить LINQ в общем и LINQ to SQL в. частности.

Поначалу всё было хорошо. Для меня хороший старт сделала, обнаруженная на msdn, статья «LINQ to SQL: .NET Language-Integrated Query for Relational Data».
Но я не сильно удивился, когда «всё хорошо» закончилось.

Для хранения геометрических данных в SQL Server были введены два дополнительных типа: geometry и geography. Первый используется для хранения геометрических объектов, описанных в декартовой системе координат, а второй — для геометрических объектов заданных географическими координатами (широта/долгота).
Такое разделение, по всей видимости, пришлось сделать из-за того, что пространственный индекс реализован в SQL Server на основе B-деревьев. При использовании этого индекса пространство шаблонно разбивается сеткой несколько раз и в «ячейки» этой сетки сохраняются ссылки на геометрические объекты. И оказалось невозможно строить универсальное разбиение и для прямоугольной системы координат и для эллипсоидальной. В MySql, например, выбран другой алгоритм индексирования, основанный на R-деревьях, работающий на совершенно другом принципе, и используется один тип данных. Какой способ индексирования лучше, а какой хуже — не очевидно, так что пока не понятно на кого ругаться и стоит ли.

Оказалось, что LINQ to SQL не понимает этих типов данных и работать с ними, а также со встроенными геометрическими функциями, отказывается. Хотя, наверное, правильнее сказать, что их не понимает провайдер. В любом случае, уверен, что поддерживаться эти данные будут, но сейчас такой поддержки нет.

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

В этой статье будет рассмотрен один из вариантов реализации паттерна репозиторий на базе LINQ to SQL.

Сегодня LINQ to SQL – это одна из технологий Microsoft, предназначенная для решения проблемы объектно-реляционного отображения (object-relational mapping). Альтернативная технология Entity Framework является более мощным инструментом, однако у LINQ to SQL есть свои преимущества – относительная простота и низкоуровневость.

Данная статья — это попытка продемонстрировать сильные стороны LINQ to SQL. Паттерн репозиторий отлично ложится на парадигму LINQ to SQL.

Итак, перед нами Linq-to-Sql. Перед нами стоит задача узнать какие поля могут иметь значения null, а какие нет — решение данной задачи может, например, помогать в подсветки обязательных полей на форме, либо просто для валидации данных, перед их установкой в свойства объекта.

 

Совсем недавно начал использовать LINQ to SQL и при нагрузках на сайт стал замечать такого рода ошибки,
при чем появляются в стиле корейского Random-а:

вариант 1) InvalidCastException
вариант 2) DataReader is closed
вариант 3) SQL Server также генерирует ошибку связаную с MARS и рвет соединение

В первой части статьи мы изучили то, каким образом можно найти конфликт параллельного доступа и возможные способы их решения.
Вторая часть статьи посвящена решению этого конфликта, при использовании LINQ to SQL.

Во второй части статьи рассмотрено, как решать конфликты параллельного доступа в LINQ to SQL, и причины появления ChangeConflictException при попытке обновления записей, способы решения.

Уважаемые Хабровчане, решил поделиться одним не очевидным моментом использования LinqToSql, с которым столкнулся некоторое время назад. А именно, про особенности использования каскадных Linq запросов:

Работая над очередным ASP.NET MVC проектом, и проектируя уровень доступа к БД мне потребовалось проверить качество скриптов, генерируемых Framework-ом L2C.

Что имеем (упрощенный вариант модели):

class User {
  public long Id { get; set; }
  public string Name { get; set; }
  public IEnumerable<Parameter> Parameters { get; set; }
}

class Parameter {
  public long UserId { get; set; }
  public string Name { get; set; }
  public string Value { get; set; }
}

Для получения данных написан класс UserRepository:

class UserRepository: MyProjectDataContext {
  public IEnumerable GetUsers() {
    return this.Users.ToModelUsers();
  }
}

static class RepositoryHelper {
  public static IEnumerable<Model.User> ToModelUsers(this IEnumerable<DataAccess.User> users) {
    return users.Select(u => new Model.User { Id = u.Id, Name = u.Name, Parameters = u.Parameters.ToModelParameters() });
  }

  public static IEnumerable<Model.Parameter> ToModelParameters(this IEnumerable<DataAccess.Parameter> parameters) {
    return parameters.Select(u => new Model.Parameter {… });
  }
}

пишем
var users = userRepository.GetUsers().ToList();

смотрим профайлер, и с удивлением обнаруживаем что для загрузки 10 пользователей и их параметров было выполнено целых 11 запросов.

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

В статье я описал несколько примеров неочевидных моментов при использовании LINQ to SQL. Если вы гуру .NET, вам, возможно, покажется это скучным, остальным — добро пожаловать!
Начнем с такого примера. Допустим, у нас есть сущность «тип действия». У типа действия есть human-readable имя и системное имя — некий уникальный идентификатор, по которому с объектами этой сущности мы сможем работать из кода. Вот такая структура в виде объектов в коде:

class ActionType
{
	public int id;
	public string systemname;
	public string name;
}

var ActionTypes = new ActionType[] {
	new ActionType {
		id = 1,
		systemname = "Registration",
		name = "Регистрация"
	},
	new ActionType {
		id = 2,
		systemname = "LogOn",
		name = "Вход на сайт"
	},
	new ActionType {
		id = 3,
		systemname = null,
		name = "Некоторый тип действия без системного имени"
	}
};

Для такой же структуры с аналогичными данными создана таблица в БД и вспомогательные объекты для использования LINQ to SQL. Допустим, нам необходимо выяснить, существует ли у нас тип действия с системным именем NotExistingActionType. Вопрос в том, что будет выведено на экран после выполнения этих инструкций:

var resultForObjects = ActionTypes.All(actionType => actionType.systemname != "NotExistingActionType");
var context = new LinqForHabr.DataClasses1DataContext();
var resultForLTS = context.ActionTypes.All(actionType => actionType.SystemName != "NotExistingActionType");

Console.WriteLine("Result for objects: " + resultForObjects + "\nResult for Linq to sql: " + resultForLTS);
Console.ReadLine();

Миф #1

Все LINQ запросы должны начинаться с ключевого слова 'var'. По сути основная цель ключевого слова 'var' — начать LINQ запрос!

Ключевое слово var и LINQ — это самостоятельные концепции. Ключевое слово var позволяет компилятору вывести тип локальной переменной на основании начального присваивания(неявная типизация). К примеру, следующий код:

var s = "Hello"; 

точный эквивалент для:

string s = "Hello"; 

потому что компилятор выводит тип переменной s как string.

Дисклеймер: Под Linq to Database здесь и далее понимаем самые распространенные .NET библиотеки для доступа к реляционным СУБД с использованием Linq запросов. Такие как Linq2SQL, Entity Framework, NHibername, Linq2db и подобные

С момента появления IQueryable провайдеров для доступа к базам данных писать запросы стало гораздо легче. С одной стороны это хорошо, потому что приложения стало делать гораздо легче. С другой стороны качество запросов сильно упало. И дело не в том, что провайдеры генерируют плохой SQL, а в том, что люди пишут запросы, не понимая как оно работает под капотом. Для многих C# программистов IQueryable является магией, и появляется естественное желание уменьшить влияние магии на приложения, изолировать магию от остального кода. Такой подход не только не исправляет ситуацию, а усугубляет её…

Linq появился в 2007 году, тоже же появился первый IQueryable-провайдер — Linq2SQL, он работал только с MS SQL Server, довольно сильно тормозил и покрывал далеко не все сценарии. Прошло почти 7 лет, появилось несколько Linq-провайдеров, которые работают с разными СУБД, победили почти все «детские болезни» технологии и, уже пару лет как, Linq to Database (обобщенное название для популярных провайдеров) готов к промышленному применению.

Тем не менее далеко не все применяют Linq to Database и объясняют это не только тем, что проект старый и переписать на linq довольно сложно, но и приводят в качестве аргументов различные мифы. Эти мифы кочуют из одной компании в другую и часто распространяются через интернет.

В этом посте я собрал самые популярные мифы и опровержения к ним.

Прошло уже больше года с моего предыдущего поста на похожую тему. За это время мы как-то не приблизились к переходу на Entity Framework (по текущей легенде, мы перейдём, когда появится стабильная версия EF 7), ну а у меня накопилось некоторое количество опыта, которым я бы хотел поделиться. Думаю, что эта статья будет интересна тем, кто, как и мы, до сих пор пользуются этой в общем-то неплохой, но позабытой Microsoft технологией.

DbType

Указание подсказки DbType (за исключением enum'ов, об этом ниже) не является обязательным для свойств сущностей в Linq 2 Sql. И уж точно не стоит указывать неправильный DbType. Например, не стоит, если в базе колонка имеет тип nvarchar(50), указывать Linq 2 Sql, что колонка имеет тип nchar(50). И особенно не стоит так делать, если это поле является дискриминатором, как в следующем примере:

	[Table(Name = "directcrm.OperationSteps")]
	[InheritanceMapping(Code = "", Type = typeof(OperationStep), IsDefault = true)]
	// ...
	[InheritanceMapping(Code = "ApplySegment", Type = typeof(ApplySegmentOperationStep))]
	public class OperationStep : INotifyPropertyChanging, INotifyPropertyChanged, IValidatable
	{

		// Некоторое количество кода
		...

		[Column(Storage = "type", DbType = "nchar(50) NOT NULL", CanBeNull = false, IsDiscriminator = true)]
		public string Type
		{
			get
			{
				return type;
			}
			set
			{
				if ((type != value))
				{
					SendPropertyChanging();
					type = value;
					SendPropertyChanged();
				}
			}
		}
	}

С моего предыдущего поста прошёл месяц, по-моему самое время продолжить. В этот раз поговорим об Inheritance Mapping’е, ну а особо интересующихся в конце статьи ждёт сюрприз.

Итак, начнём.

Проблемы с дискриминатором

Разумеется, мы храним в нашей базе данных полиморфные сущности. Например, есть сущность CustomerOperation, которая отражает некоторую операцию, которую можно совершать над потребителем. Операции совершаются в основном через сервисы, поэтому есть наследник CustomerServiceOperation, а так же у нас есть механизм WebTracking’а, для которого есть WebTrackingOperation. Но довольно слов, лучше покажу код:

За последний год мы перенесли внушительную часть настроек DirectCRM в базу данных. Множество элементов промо-кампаний, которые мы до этого описывали исключительно кодом, теперь создаются и настраиваются менеджером через админку. При этом получилась очень сложная структура БД, насчитывающая десятки таблиц.

Однако, за перенос настроек в базу данных пришлось расплачиваться. Об архитектуре, позволяющий кэшировать редко меняющиеся Linq to SQL сущности, смотрите под катом.

Средства LINQ позволяют .Net-разработчикам единообразно работать как с коллекциями объектов в памяти, так и с объектами, хранящимися в базе данных или ином удаленном источнике. Например, для запроса десяти красных яблок из списка в памяти и из БД средствами Entity Framework мы можем использовать абсолютно идентичный код:

List<Apple> appleList; 
DbSet<Apple> appleDbSet;
var applesFromList = appleList.Where(apple => apple.Color == “red”).Take(10);
var applesFromDb = appleDbSet.Where(apple => apple.Color == “red”).Take(10);

Однако, выполняются эти запросы по-разному. В первом случае при перечислении результата с помощью foreach яблоки будут отфильтрованы с помощью заданного предиката, после чего будут взяты первые 10 из них. Во втором случае синтаксическое дерево с выражением запроса будет передано специальному LINQ-провайдеру, который транслирует его в SQL-запрос к базе данных и выполнит, после чего сформирует для 10 найденных записей объекты С# и вернет их. Обеспечить такое поведение позволяет интерфейс IQueryable<T>, предназначенный для создания LINQ-провайдеров к внешним источникам данных. Ниже мы попробуем разобраться с принципами организации и использования этого интерфейса.

На C# я пишу редко, и в основном все наши приложения и сервисы подключаются к источнику данных, используя MSSQL сервер или службы баз данных. И вот настало время написать приложение, используя не сервер, а локальную БД. Немного погуглив, я внезапно выбрал SQLite.

Предисловие

У всех наших заказчиков были требования к коду:

• установленное именование переменных;
• группировка кода (конструкторы, переменные, методы, события...);
• табы и форматирование (каралось смертной казнью);
• за самописные SQL запросы разработчик удалялся из команды.

Исходя из вышеперечисленного, для баз данных конечно же были использованы классы LINQ to SQL, связанные с реляционными объектами.

Многие считают, что 1С может обслуживать только бухгалтерию. На самом деле это не так. Значение платформы 1С: Предприятие недооценено. Цель статьи показать, что 1С: Предприятие 8.3 может с успехом применяться при построении нестандартных решений в Интернете. 1C может быть удобным инструментом для многих областей: от небольшого IT-проекта до развитой многосерверной системы. Предлагаю обсудить гибкость и применимость платформы 1С к построению веб-проектов и стартапов. Для усиления эффекта 1С рассматривается в связке с .Net framework: Asp.Net MVC.

Статья писалась на основе нескольких нестандартных веб-проектов: личных и корпоративных, успешных и не очень. Здесь вы не найдете руководства по созданию обычных интернет-магазинов, потому что это стандартная, хорошо описанная в других источниках задача. К примерам нестандартных проектов я отношу: сервис проверки начислений по дисконтной карте из нескольких 1С, сайт объявлений для газеты, внутренний сайт голосования за товары между продавцами. Сюда также можно отнести сильно нестандартные интернет-магазины: магазины с несколькими регионами, валютами и ценами; магазины с товарами из разных баз 1С; магазины уникальных товаров, завязанных на производства.

LINQ вошел в .NET как новый мощный язык манипуляции с данными. LINQ to SQL как часть его позволяет достаточно удобно общаться с СУБД с помощью например Entity Framework. Однако, достаточно часто применяя его, разработчики забывают смотреть на то, какой именно SQL-запрос будет генерировать queryable provider, в вашем случае — Entity Framework.