BLToolkit. Intro — II

Хранимые процедуры

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

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

Прогоняем процедуру, убеждаемся, что все работает как надо и переходим к написанию C# кода. Для этого в нашем абстрактном классе PersonAccessor объявляем новый метод, который будет принимать целочисленное значение возраста в качестве параметра и возвращать список людей старше указанного значения.

Всё!

После этого в основной программе можно вызвать этот метод и получить данные.

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

По умолчанию, BLToolkit формирует имена процедур из имени шаблонного класса и названия метода: %имя_шаблона%_%имя метода%. Однако такое поведение можно переопределить в классе доступа к базе.

Если бы у нас было корпоративное правило, по которому все процедуры должны называться, используя префикс “sp_”, это можно было бы легко реализовать. Для этого в классе PersonAccessor надо переопределить метод GetDefaultSpName.

Для чистоты эксперимента проверяем, что в базе не осталось исходной процедуры, а только sp_ Person_GetOlderThan. Запускаем приложение и видим что все работает отлично.

В более хардкорных случаях, когда в вашей организации процедуры принято кодировать и настоящее имя процедуры выглядит примерно так: sp_prsn_get_oldr ­– будет очень не сладко использовать такое имя в коде.

В этом случае можно использовать атрибут SprocName.

 

Несмотря на перегруженный метод GetDefaultSpName, код отработает как ожидалось, так как применение атрибутов имеет более высокий приоритет, что логично.

Параметры

BLToolkit сопоставляет параметры метода и процедуры по именам, поэтому не имеет значения в каком порядке вы объявили переменные. Допустим, процедура принимает 3 параметра

Вызов процедуры пройдет нормально, если сигнатура метода будет выглядеть как:

Если же и имена параметров никак вас не устраивают, то можно написать код вручную, который по идее генерируется на лету во время исполнения.

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

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

Linq

Согласитесь, что писать запросы перед методом не очень хорошо, тем более, когда есть еще дополнительные условия для фильтрации. Лучше всего обратиться к Linq, раз уж существует такая возможность.

Для начала работы с Linq и указанию BLT на то, какие таблицы/представления будут участвовать в запросах, надо создать новый класс и наследовать его от DbManager.

 

Далее надо создать конструктор, который либо будет указывать на строку соединения в конфигурации, либо задавать ее самостоятельно (всего конструкторов 5+), например, так:

 

После этого можно создать свойство, которое будет возвращать тип Table, который реализует интерфейс IQueryable.

После этих несложных манипуляций можно писать запросы к таблице Person. Например:

Или

Согласитесь, что это уже лучше, можно добавлять условия и изменять переменную типа IQueryable в процессе выполнения программы добавляя новые условия фильтрации, если нужно.

Сгенерированный запрос в процессе выполнения второго примера:

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

 

Связанные таблицы

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

Итак, дополним базу данных адресами наших знакомцев.

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

Далее мы хотим получить связь между классом Person и классом Address, для этого в класс Person добавляем поле типа Address, которое будет в дальнейшем выступать связью для построения linq запросов.

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

Обязательно при этом добавить поле ключа связиAddressId, иначе ничего работать не будет.

Далее в класс  BltLinq  добавляем свойство для доступа к таблице Address, по образу и подобию того как мы сделали ранее для Person.

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

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

Заключение

Это можно считать вводным курсом в BLToolkit. Фреймворк предоставляет еще множество настроек и возможностей по оптимизации запросов и получения именно того, что вам требуется. Так же поддерживается запись и обновление строк в таблицах. Но об этом как-нибудь в другой раз, когда придет необходимость в этом.

По BLToolkit много материала в сети, так как это уже не новый фреймворк с большой армией поклонников.

В целом мне понравилось работать с BLToolkit, приятное впечатление оставляет фреймворк. Буду использовать.

 

Hard’n’heavy

 

2 комментарий на “BLToolkit. Intro — II

    • Ох, это было настолько давно, что я уже и не припомню. Мне кажется документация на сайте должна об этом сказать.
      Однако я знаю, что передача таких параметров не должна вызывать проблем, так как пользовался ими с помощью стандартных средств .NET и прикрутить такое в BLToolkit не должно вызывать проблем.

Оставить комментарий