Блог

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

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

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

Новый вопрос от читателя о том, что выбрать для мобильной разработки - межплатформенный язык или заточенный под платформу:

Я как понял ты занимаешься разработкой ПО под мобилы, вопрос: мне необходимо освоить это ремесло, я умею хорошо писать на C#, мне лучше использовать xamarin и убить двух зайцев, или лучше сначала написать на java под андроид, а потом изучить и написать под IOS?

Недавно получил по e-mail вопрос, на который коротко ответил уже, но потом решил более развернуто написать уже здесь на блоге:

Привет, Михаил много ли логики пишешь на Transact-Sql? Как думаешь хорошая идея писать sql-процедуры на c#? В sql-е есть такая возможность.

В самом SQL не так уж и много возможностей, а вот в Transact-SQL действительно можно написать многое. Но я не пишу логику на Transact-SQL. Я могу написать какие-то простые вещи в самом крайнем случае, но только в крайнем. 

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

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

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

Недавно я написал заметку, в которой описал магическое выполнение запроса, которое поставило меня в ступор http://www.flenov.info/blog/show/Magicheskaya-problema-proizvoditelynosti. В этой заметке я не раскрою все тайны тормозов, потому что я так и не могу понять, почему тогда простое добавление перехода на новую строку меняло план выполнения, а реальное изменение запроса типа добавления and 1=1 или другие модификации оставляли запрос медленным. Даже OPTION (recompile) не влияла. Именно символ новой строки менял план выполнения. Скажу только, что на следующий день этот трюк не работал и запрос оставался медленным даже после добавления новой строки.

Итак, краткая история. Если просто выполнять запрос в SQL Server Management Studio, то он выполняется быстро:

Мне часто приходится решать проблемы с производительностью и последние два дня борюсь с запросом, который мне просто вынес мозг. 

Запрос большой и строится динамически, поэтому я запустил сайт, подключился к нему дебагером и выцепил из кода SQL запрос. Запускаю его в SQL Server Management Studio, и он выполняется за 4 секунды максимум. Но когда абсолютно этот же код выполняется в коде сайта, он работает более минуты.

Я потратил целый день на то, что менял запрос в разные стороны, добавлял OPTION (RECOMPILE) на случай, если проблема с планом выполнения, танцевал вокруг компьютера и ничего не помогало. 

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

Потом я решил запустил профайлер и выцепить запрос оттуда, и его там показали следующим образом:

Очень часто в книгах о хорошем тоне в программировании можно увидеть термин Decoupling в отношении кода. Смысл в том, что ваши классы не должны быть жёстко привязаны к определённой реализации другого класса (внешней зависимости). И я иногда вижу, что народ следует этой рекомендации в своём коде. 

Но почему при этом все так жёстко привязываются к определённому фреймворку в представлениях (View)?

Я ненавижу использовать различные хелперы в виде Html.BeginForm в представлениях. От того, что это превращается во время выполнения в <html> выгоды ноль. Проще же сразу написать HTML тэги и отвязаться от абсолютно ненужно помощи фреймворка. 

Я люблю Dependency Injection, я считаю этот патерн очень даже удобным, но я стал замечать, что им пренебрегают. Мне не нравится в последних версиях Symfony, что если у класса есть конструктор с параметрами, то он автоматически пытается привязывать все эти параметры. 

А я не хочу этого делать. У меня очень часто в моделях есть классы, которые получают жизненно важные данные через параметры. Symfony заставляет указать autowiring или отключить его в конфигурации. И это реально бесит. Простое использование классов с моими личными параметрами – теперь боль. Может кто знает, как просто отключить Dependency Injection на один из параметров, без необходимости лезть в service файл? 

Наверно в каждой книге написано про то, что нужно писать код без жёстких зависимостей - использовать интерфейсы и инъекцию зависимостей. Но почему-то мало, кто реально следует этому. И отчасти это проблема документации, на которую смотрят программисты. 

Вот взять для примера всеми любимые фреймворки для PHP и посмотреть на код оправки почты - вот возьмем пример отправки E-mail из Symfony. Я специально беру его, потому что фреймворк хороший и в нем можно писать код без записимостей. 

Я обожаю .NET для Web и если строить большой сайт с E-Commerce, то я на первом месте бы смотрел на .NET и только потом на LAMP. Да, LAMP хостинг будет дешевле и можно смириться с некоторыми ограничениями PHP и проблемами, но .NET реально проще и удобнее для больших проектов. 

И благодаря .NET Core я могу написать на нем сайт и запустить его на Linux. Да это же мечта. Я понимаю, зачем Microsoft делают .NET Core, он быстрее и реально лучше, в нем исправили все недостатки .NET, которые остались после перехода с 1.0 на 2.0 и живы до сих пор. 

Вторая причина - Microsoft Azure. Компания хочет, чтобы программисты могли писать для Azure код на любой платформе. Ну люблю я macOS, так почему же не позволить мне писать код под моей любимой ОС, но публиковать его в Azure? Идея логична и понятна, а если я не захочу публиковать его в Azure? С классическим .NET я вынужден был бы купить Windows сервера и хостить их самостоятельно, а теперь я буду хостить самостоятельно, но на Linux серверах.